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
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