gcc/unwind-dw2-fde-glibc.c maintains a cache of frames via its dl_iterate_phdr callback but doesn't protect against multiple threads modifying that cache concurrently. A simple test program that starts N threads, all of which immediately throw, often, but not always (as such races are prone to behave), leads to some number of threads stuck inside their stack unwinding consuming 100% CPU. The particular failure mode will no doubt differ depending upon the particular interleaving of accesses/modifications to the cache structure but I'm seeing consistent hangs on the two systems on which I've tested this (quad core Xeon, dual core Core 2 Duo). Reproduction typically requires running the test in a loop until it doesn't exit. The usual caveats regarding races apply, i.e it may not fail on certain CPU/OS combinations or may take a long time to fail. The attached patch avoids the spinning by grabbing "object_mutex" (defined in gcc/unwind-dw2-fde.c which is included and used in gcc/unwind-dw2-fde-glibc.c) to protect against multiple threads manipulating the cache at the same time. With the patch no failure has been observed in over 200,000 invocations of the test with each invocation starting 100 threads. The issue was found on FreeBSD 7.x (aka STABLE) gcc 4.2.1 (20070719) but inspection of the VCS shows the same code exists on the trunk and branches.
Created attachment 15521 [details] test program Test program to demonstrate issue
Created attachment 15522 [details] Patch to protect against concurrent modifications to frame cache Simple fix that applies coarse-grained locking around the frame cache. If unwinding performance is a concern either a finer-grain locking strategy or even a lock-free structure should be used.
Note for repro using glibc, the test program uses the BSD err() function to report errors and quit. A quick look at glibc's manual says it has a compatible err() function but declared in error.h not err.h as in BSD.
This is a bug in your glibc. Current glibc has __dl_iterate_phdr (int (*callback) (struct dl_phdr_info *info, size_t size, void *data), void *data) { struct link_map *l; struct dl_phdr_info info; int ret = 0; /* Make sure we are alone. */ __rtld_lock_lock_recursive (GL(dl_load_lock)); __libc_cleanup_push (cancel_handler, 0); ... so it is already properly locked. Which glibc version do you use? You should probably report this as a bug to your vendor.
> Which glibc version do you use? As per description it's FreeBSD 7's (aka STABLE) libc who's ld.so implementation uses gcc's glibc-specific unwinding. > You should probably report this as a bug to your vendor. Done with patch to fix it. http://www.freebsd.org/cgi/query-pr.cgi?pr=123062 Thanks for the clarification.