Re: [imagemagick] Strange bug in one of my packages need help (maybe glibc bug?)
On Mon, May 30, 2011 at 3:06 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> 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.
I think it is this case, at break at exit and backtrace show me this.
Message about missing symbol was already printed.
>
>
> 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.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk3jlkwACgkQVcFcaSW/uEgCmACdGhpAcZJa3Z9mO4NAyqnQ3MwQ
> g5oAn1yvyTcLHN1slm3jbuGm1nPIfFJ0
> =O9CN
> -----END PGP SIGNATURE-----
>
>
Reply to: