[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [imagemagick] Strange bug in one of my packages need help (maybe glibc bug?)



On Mon, May 30, 2011 at 02:27:28PM +0200, roucaries bastien wrote:
> On Mon, May 30, 2011 at 1:54 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> > On Mon, May 30, 2011 at 01:21:07PM +0200, roucaries bastien wrote:
> >> On Wed, May 25, 2011 at 7:34 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> >> > On Wed, May 25, 2011 at 12:20:09PM +0200, Bastien ROUCARIES wrote:
> >> >> Hi,
> >> >>
> >> >> I have two strange bug in my package imagemagick. I am really clueless about these.upstream have no idea also. Any help welcome
> >> >> see #625250
> >> >
> >> > % c++filt  _ZNSt14error_categoryD2Ev
> >> > std::error_category::~error_category()
> >> >
> >> > % nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev
> >> > 0000003380272800 T _ZNSt14error_categoryD2Ev
> >> >
> >> > % nm -C -D /usr/lib/libstdc++.so.6 | grep error_category
> >> > 0000003380272800 T std::error_category::~error_category()
> >> >
> >> > This is on a sid system.
> >> >
> >> > On squeeze:
> >> > $ nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev
> >> > $ echo $?
> >> > 1
> >> >
> >> > If imagemagick was built against the current libstdc++ and run
> >> > using an older libstdc++ without the symbol, you will get this
> >> > error.
> >> >
> >> > I don't see any direct libstdc++ dependency in either the
> >> > imagemagick package, or its library needed sections.  What's using
> >> > libdjvulibre?  Is it being dlopened.
> >>
> >> Yes it is dlopened
> >>
> >> > If this is the case,
> >> > libdjvulibre is using an old version of libstdc++, and that's an
> >> > issue with its dependencies (and/or the libstdc++ symbol
> >> > versioning).
> >>
> >> Seems so, more strangely using LD_PRELOAD=/usr/lib64/libdjvulibre.so
> >> or LD_BIND_NOW=1 fix this issue. Will reassign to libdvu
> >
> > This library may just require a rebuild.  You could request a
> > binNMU to get it rebuilt if this is the case.
> >
> >> > You'll need a full stack trace to work out what's using this
> >> > library if you haven't done so already.
> >>
> >> It does not coredump. How can I get a backtrace ? using LD_DEBUG=all
> >> option point to libdjvu
> >
> > Well, you can get a backtrace at any point, not just on coredump.
> > You could 'break dlopen' to stop and get a backtrace at all dlopen
> > calls.  Or on any function call you like.  This will let you find
> > out what's responsible for the dlopen in the first place.
> 
> It break in __libc_start_main
> _start
> 
> Any idea ?

No. You'll need to look at the backtrace at that point.  It may
be irrelevant; just continue and look at all the break points,
inspecting the backtrace each time.

Note that ELF contructors (.init section) run early before main()
is called.  They can do arbitrary stuff.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature


Reply to: