Re: caveat: GNOME 2.6 severly broken on Debian/unstable?
>>>>> On Thu, 3 Jun 2004 16:26:52 +1000, Ian Wienand <ianw@gelato.unsw.edu.au> said:
Ian> On Wed, Jun 02, 2004 at 12:34:52PM -0700, David Mosberger wrote:
Ian> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=252401
Ian> bit me when I wanted to use ethereal on a newly installed box ...
Ian> Basically, missing libraries on link of libpango
Ian> As for why it hangs and doesn't crash ... well if you disassemble it
Ian> you get (excuse the long lines)
Ian> 0x2000000001f82590 <pango_xft_get_font_map+176>: [MIB] nop.m 0x0
Ian> 0x2000000001f82591 <pango_xft_get_font_map+177>: nop.i 0x0
Ian> 0x2000000001f82592 <pango_xft_get_font_map+178>: br.call.sptk.many b0=0x2000000001f82590 <pango_xft_get_font_map+176>;;
Ian> so it branches back to the start of it's bundle. It should actually
Ian> be a call to g_object_new() I think, but as that's not defined at link
Ian> I guess the relocation never gets fixed up or something.
The branch is IP-relative and the offset field is zero by default so
if the label never got resolved, you'd definitely get an infinite
loop.
However, I don't understand why the unresolved symbol didn't result in
an error message from ld.so. AFAIK, the only way this could
legitimately happen is if g_object_new() were defined as a weak
reference but that seems implausible (if it were weak, the code would
have to check explicitly for its value being NULL).
HJ, do you know of another scenario where a call to an undefined
symbol would silently be ignored by ld.so? (If you need more context,
see the above bugreport URL).
--davida
Reply to: