This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: malloc_set_state and heap content


On 07/06/2016 11:11 PM, Samuel Thibault wrote:
Florian Weimer, on Wed 06 Jul 2016 23:09:20 +0200, wrote:
On 07/06/2016 10:38 PM, Samuel Thibault wrote:
Florian Weimer, on Wed 06 Jul 2016 22:36:05 +0200, wrote:
On 07/06/2016 09:35 PM, Samuel Thibault wrote:
So I'd say we need the attached patch, don't we?

The patch does not address the issue because it does not alter the heap copy
in existing Emacs binaries.  It would only become effective after
recompiling Emacs.  Such recompiled Emacs binaries will no longer use the
heap dumping mechanism.

Well, glibc is not only about emacs, is it? :)

Could you be more specific, please?  Are there Hurd-specific applications
which use malloc_set_state?

I mean that there can be other applications making use of
malloc_set_state

https://codesearch.debian.net/search?q=malloc_set_state

suggests a few.

Which ones?

As far I can tell, those are either automatically generated wrappers which are unlikely to work at all (because they are for high-level languages which call malloc before the application code has a chance to call malloc_set_state), or copies of dlmalloc or ptmalloc (so they are *implementations* of malloc_set_state).

In any case, your proposed fix is incorrect because it does not address backwards compatibility issues with slightly corrupted dumped heaps in non-Linux binaries, and new binaries won't be able to use malloc_set_state reliably (even with the current state of master, and we are going to turn malloc_set_state into a compat symbol before the release).

Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]