Re: [imagemagick] Strange bug in one of my packages need help (maybe glibc bug?)
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 ?
>
> If you have multiple copies of libstdc++ loaded, that could cause
> some issues. For this reason, it may be that all the C++ parts
> need rebuilding against the current version if some parts are using
> an old one. Normally this would be enforced by the package
> dependencies, but dlopen means this is avoided (which can result
> in breakage). Normally it's not good practice to dlopen random
> libraries for just this reason--it's normally restricted to
> modules within a package, which means the dlopened bits are then
> compatible.
>
>
> 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)
>
> iEYEARECAAYFAk3jhV8ACgkQVcFcaSW/uEj2HwCgxfO9Ppf4EYsbtsGwQpzKYIEN
> QpEAniwFaVW8z81OwwvKIeWPxQMUsi9K
> =bVA/
> -----END PGP SIGNATURE-----
>
>
Reply to: