[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release
From: |
Lassi Tuura |
Subject: |
Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"? |
Date: |
Mon, 21 Mar 2011 18:46:43 +0100 |
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] Bug fixes in libunwind git = make another "release"?, Evan Jones, 2011/03/18
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Arun Sharma, 2011/03/18
- [Libunwind-devel] Re: Bug fixes in libunwind git = make another "release"?, Ken Werner, 2011/03/20
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?,
Lassi Tuura <=
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Paul Pluzhnikov, 2011/03/21
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Paul Pluzhnikov, 2011/03/21
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Lassi Tuura, 2011/03/21
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Paul Pluzhnikov, 2011/03/21
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Lassi Tuura, 2011/03/21
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Paul Pluzhnikov, 2011/03/21
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Lassi Tuura, 2011/03/22
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Joe Damato, 2011/03/23
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Arun Sharma, 2011/03/23
- Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?, Joe Damato, 2011/03/23