Hi, > Yes - it's been a while since the last release. We should try and get > something out this summer for the distros. > > After 0.99 comes 1.0! I'm interested in hearing feedback about issues, > irritants, bugs people want to get fixed before the next release. > > Also, if there are features you'd like to vote for (or contribute!), > please speak up in the next few days. Fast unwinding + slow fallback > on x86 seems to be a popular feature. Anything else?
One of the things that continues to affect us is the introduction of mincore() call vs. msync() for address validation: mincore() gives an incorrect answer for MAP_PRIVATE mappings for linux kernels prior to 2.6.21. Can we make libunwind auto-detect whether mincore() works and fall back on msync(), or at least integrate the patch to make it configure-time option? Another issue continuing to bite us from time to time is the deadlock in dl_iterate_phdr() if you attempt to get a stack trace right in the middle of dynamic linker holding - or even taking - that lock. Previously it was suggested app might trap into _dl_debug_state() to grab the list then tell libunwind to use the list not dl_iterate_phdr(). I am willing to see if this can fly, but thoughts would be welcome. We build our libunwind with --disable-block-signals, which turns off sigprocmask() calls with mutexes as they cost a bit and aren't needed in our case. How would we recommend a distro build libunwind? Should we advise distros that libunwind is dangerous in security sensitive code / user apps unless the entire userland has been compiled with GCC 4.5+? The invalid unwind info is a large attack vector... Earlier we enabled full address validation at least on x86-64 - but the fast trace code runs with validation off. Even with validation I am somewhat concerned this gets used to attack apps, bring down servers, or such. Apart for finishing the work on the fast trace, for which I have been working recently and hope to submit patches later this week, the msync is quite important to us. The deadlock is awkward but we can live with it. The configure option doesn't really matter to us as we build our own libunwind anyway, but it may matter more one day. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
