View Bug Activity | Format For Printing
_int_free() (malloc/malloc.c), which is called from free() with arena mutex locked, checks and eventually prints/logs error message. So if malloc_printerr() handling do some malloc()/free() on the same memory arena, deadlock can occur. vsyslog() can call free() during tz manipulation. Yes, this deadlock is triggered by buggy code. But it's all inside libc, not caused by actual memory corruption.
Created an attachment (id=424) testcase for deadlock on double-free logging Simplified testcase to trigger deadlock (originally it was detected in daemon which didn't want to exit on SIGPIPE when run on NPTL libc - it tried to do double shutdown). Deadlock occurs on NPTL libc or when it's linked with linuxthreads libpthread. When run on just linuxthreads libc it logs double-free error and aborts (as there is no real locking in single-thread code).
*** Bug 771 has been marked as a duplicate of this bug. ***
*** Bug 772 has been marked as a duplicate of this bug. ***
This happens to us once a day or so (obviously the double-free that causes the problem is periodic in some fashion). For us deadlocking is mostly worse than just allowing some potential corruption due to a double-free. We are using glibc-2.5-12 x86-64 on a CentOS 5 machine. Here are some musings from #glibc IRC where I reported that I had seen this bug. <ryanarn> hrm.. that one's been about for a while. I wonder why there's been no movement on it. <sjmunroe> the mutex it locked in free which calls _int_free(), so _int_free does not know about the lock <sjmunroe> to avoid this _int_free would have to report the error back to free so free could do the unlock before reposting the error