Date: Wed, 17 Feb 2016 09:03:27 +0200 From: Timo Teras <timo.teras@....fi> To: Szabolcs Nagy <nsz@...t70.net> Cc: musl@...ts.openwall.com Subject: Re: dynlink.c: bug in reclaim_gaps leading to segfault in __libc_exit_fini On Tue, 16 Feb 2016 22:55:50 +0100 Szabolcs Nagy <nsz@...t70.net> wrote: > * Hugues Bruant <hugues@...ofs.com> [2016-02-16 16:30:42 -0500]: > > Affects both 1.1.12 and 1.1.13 > > > > Tracked down with valgrind in Alpine Linux 3.3. > > > > The dmg tool build from https://github.com/aerofs/libdmg-hfsplus > > links to a handful shared libs. The following message is seen > > immediately at start: > > > > ==59== Invalid free() / delete / delete / realloc() > > ==59== at 0x4C92B0E: free (vg_replace_malloc.c:530) > > ==59== by 0x4056F68: reclaim_gaps (dynlink.c:488) > > ==59== by 0x405743D: map_library (dynlink.c:708) > > ==59== by 0x4057EF3: load_library (dynlink.c:1014) > > ==59== by 0x4058CA8: load_preload (dynlink.c:1112) > > ==59== by 0x4058CA8: __dls3 (dynlink.c:1581) > > ==59== by 0x405856A: __dls2 (dynlink.c:1383) > > ==59== by 0x405655E: ??? (in /lib/ld-musl-x86_64.so.1) > > ==59== by 0x3: ??? > > ==59== by 0xFFF000E3A: ??? > > ==59== by 0xFFF000E3E: ??? > > ==59== by 0xFFF000E44: ??? > > ==59== by 0xFFF000E86: ??? > > > > Afterwards, the program proceeds with no issue, until it exists, at > > which point a segfault is triggered when cleaning up shared > > libraries: > > this is not a bug. It is compliance issue. POSIX says about free: -- The free() function shall cause the space pointed to by ptr to be deallocated; that is, made available for further allocation. If ptr is a null pointer, no action shall occur. Otherwise, if the argument does not match a pointer earlier returned by a function in POSIX.1-2008 that allocates memory as if by malloc(), or if the space has been deallocated by a call to free() or realloc(), the behavior is undefined. -- While overloading allocators are not supported, they'd break at this too. And it'll be highly annoying if someone decides to test a new memory allocator inside musl and does not know about this one exception. > valgrind is not aware of dynamic linker internals, > you have to use a musl specific suppression file > to hide this message (but i dont know if anybody > wrote such thing for valgrind). Well - musl really should introduce __donatemem or similar for this purpose, and not overload the standard free() function. This would make the valgrind warning go away. I'd rather not write a suppression for the above, since the internals are misusing/overloading a standard api call against posix. Technically valgrind is detecting a valid case for misuse of free(). While in context of standard musl allocator it's ok. Thanks, Timo
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.