We recently ran into an issue on where a signal handler was calling unw_step() and deadlocked because the thread it interrupted was inside of dl_iterate_phdr (holding its lock) and unw_step ended up calling dl_iterate_phdr too, causing a deadlock. We found a few threads mentioning this in the past:
https://lists.nongnu.org/archive/html/libunwind-devel/2009-09/msg00020.html https://lists.nongnu.org/archive/html/libunwind-devel/2011-03/msg00059.html We can't tell from those threads whether this was ever resolved or not, because the documentation still clearly states that unw_step is signal safe when that appears to not be the case. Environment: libunwind-1.1 g++ (4.6.3) ubuntu 12.04 3.13.0-32-generic #57~precise1-Ubuntu SMP Tue Jul 15 03:50:54 UTC 2014 i686 i686 i386 GNU/Linux Is there any workaround at all that has been used elsewhere? Perhaps a way to know if the interrupted thread has the lock? An alternate caching scheme? Intercept the dl_iterate_phdr call to know if the interrupted thread might have the lock? Some other hack to workaround this problem? Any help is appreciated. Thanks! Jared
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
