[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31946: 27.0.50; The NSM should warn about more TLS problems

From: Andy Moreton
Subject: bug#31946: 27.0.50; The NSM should warn about more TLS problems
Date: Mon, 26 Aug 2019 19:19:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt)

On Mon 26 Aug 2019, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> Date: Mon, 26 Aug 2019 18:45:14 +0100
>> > That's because any memory allocated by GnuTLS cannot be freed by Emacs
>> > via 'free' or 'xfree', it needs to be freed by calling 'gnutls_free'
>> > (the GnuTLS manual clearly says that, btw).  That crashes, because on
>> > Windows we use our own implementation of 'free', which uses a
>> > different heap.
>> Agreed, but master built from commit 1071a4f still crashes in the same
>> way:
> Can you show a recipe?

1) Delete ~/.emacs.d/network-security.data (to ensure NSM will query the user).
2) Run "emacs -Q"
3) "M-x list-packages", and at the NSM prompt, answer 'a' or 's' or 'd'.

>> In Fgnutls_format_certificate, should out_buf be freed after calling
>> build_string ?
> I see no problem with that, since build_string copies the data.
>> Removing both xfree(out.data) and xfree(out_buf) from the end of
>> that function does give me a running emacs.
> It may run, but it leaks memory.

Agreed - it is a data point to explore the problem rather than a


reply via email to

[Prev in Thread] Current Thread [Next in Thread]