[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: Paul Pluzhnikov
Subject: Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?
Date: Mon, 21 Mar 2011 12:04:25 -0700

On Mon, Mar 21, 2011 at 10:46 AM, Lassi Tuura <address@hidden> wrote:

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

There are two problems with this approach (that I know of):

1. On many distributions, _dl_debug_state compiles to a single 'ret'. This
   is fine for an external debugger to place a breakpoint on, but is pretty
   useless for in-process debugging, as there is just not enough space to
   do anything ;-(

   Glibc developers were not receptive to our troubles:
   See John Reiser comment on Fri Jul 29, 2005 7:26 pm, mentioning r_brk.

   I am pretty sure John opened a glibc bug for this (which I can't find),
   which got closed as INVALID.

   There are ways to work around this, but they are exceedingly unpleasant.

2. For prelinked libraries, the _r_debug.r_map list does not give you
   access to the info you need: l_map->l_addr becomes 0 for all images
   that are loaded at their desired address!

   What you need then is access to l_map->l_phdr, but glibc considers that
   member private, and the offset to it changes with different glibc
   versions. You lose.

Paul Pluzhnikov

reply via email to

[Prev in Thread] Current Thread [Next in Thread]