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] |
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] |