Closed GoogleCodeExporter closed 9 years ago
compiled on x86_64
Original comment by florin.p...@gmail.com
on 22 Jan 2014 at 3:08
while(!dlclose(lib)) doesn't look like good idea anyways.
I don't think standard promises you anything if you try to dlclose already
closed library.
Original comment by alkondratenko
on 22 Jan 2014 at 7:57
I agree with you. The behavior is undefined, but it works well without
tcmalloc_debug (with tcmalloc or default glibc). while(!dlclose(lib)) it can be
useful in some unloading scenarios.
Using tcmalloc_debug doesn't work even if it seems that the module become
unloaded after the first dlclose (so there are no references from
tcmalloc_debug to the dynamic library).
Original comment by florin.p...@gmail.com
on 22 Jan 2014 at 9:09
Perhaps I misunderstand your point. But I see no reason at all why somebody
would do dlclose in an a while loop. You should expect this to crash.
Therefore I conclude that tcmalloc not hanging or crashing is a mere luck. And
therefore lack of this lack with tcmalloc_debug is not a bug.
Original comment by alkondratenko
on 22 Jan 2014 at 10:31
Agree, but I have some inherited code which I cannot modify (bad architecture).
Can you explain if there is some direct interaction between tcmalloc_debug and
dlclose ?
Original comment by florin.p...@gmail.com
on 23 Jan 2014 at 11:15
No. tcmalloc_debug does not directly interact with dlclose.
I think what likely happens is lib points to dynamically allocated memory. And
last dlclose free-s that memory. Which in case of tcmalloc_debug fills freed
memory with with "garbage". Exactly to make use-after-free problems like that
more visible.
Closing as not a bug. I suggest you to find a way to fix your code.
Original comment by alkondratenko
on 24 Jan 2014 at 4:25
Original issue reported on code.google.com by
florin.p...@gmail.com
on 22 Jan 2014 at 2:48