68882 - Linux opt builds compiled on RH7 crash on startup

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

DESCRIPTION:  Both tor and I are seeing a problem where our optimized builds
crash on startup (in ld-linux code, I think) while loading libgfx_gtk.so.  My
debug build is fine, and I've clobbered both builds.  We're both using RH7, so
I don't have much data on how widespread the problem is.

This seems to be caused by the changes for bug 32612 -- I've removed all traces
of XINERAMA from config-defs.h and config/autoconf.mk and clobbered and rebuild
gfx, and things were better.

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This is not a problem in the nightly, so it's probably a problem with builds
compiled on RH7.

Comment 2

[tor]

Do the nightly build machines have xinerama?

Comment 3

[Christopher Blizzard (:blizzard)]

I did all this work on RH7 and never had this problem.  It worked very well.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Did you do an optimized build?

Comment 5

[tor]

Using XFree86-4.0.2-0.1.  Stack trace looks like this:

#0  0x40009f28 in _dl_lookup_versioned_symbol (
    undef_name=0x37277a21 <Address 0x37277a21 out of bounds>, 
    undef_map=0x808d1a8, ref=0xbfffe74c, symbol_scope=0x808d2fc, 
    version=0x808d8d8, reloc_type=18, explicit=0)
    at ../sysdeps/i386/i686/dl-hash.h:76
#1  0x4000c4a4 in _dl_relocate_object () at ../sysdeps/i386/dl-machine.h:323
#2  0x4033f1f7 in dl_open_worker (a=0xbfffe9a0) at dl-open.c:312
#3  0x4000deda in _dl_catch_error (objname=0xbfffe998, errstring=0xbfffe99c, 
    operate=0x4033edb0 <dl_open_worker>, args=0xbfffe9a0) at dl-error.c:149
#4  0x4033f30e in _dl_open (
    file=0x808d0a0 "/home/tor/mopt/dist/bin/components/libgfx_gtk.so", 
    mode=-2147483647, caller=0x40193c8f) at dl-open.c:380
#5  0x401ce3d1 in dlopen_doit (a=0xbfffeb00) at dlopen.c:39
#6  0x4000deda in _dl_catch_error (objname=0x8055720, errstring=0x8055724, 
    operate=0x401ce3a0 <dlopen_doit>, args=0xbfffeb00) at dl-error.c:149
#7  0x401ce75b in _dlerror_run (operate=0x401ce3a0 <dlopen_doit>, 
    args=0xbfffeb00) at dlerror.c:130
#8  0x401ce386 in __dlopen_check (
    file=0x808d0a0 "/home/tor/mopt/dist/bin/components/libgfx_gtk.so", mode=1)
    at dlopen.c:53
#9  0x40193c8f in PR_LoadLibrary () from /home/tor/mopt/dist/bin/libnspr4.so
#10 0x40193b84 in PR_LoadLibraryWithFlags ()
   from /home/tor/mopt/dist/bin/libnspr4.so
#11 0x40193bd9 in PR_LoadLibrary () from /home/tor/mopt/dist/bin/libnspr4.so
#12 0x400b889b in nsLocalFile::Load () from /home/tor/mopt/dist/bin/libxpcom.so
#13 0x400c4c05 in nsDll::Load () from /home/tor/mopt/dist/bin/libxpcom.so
#14 0x400be1d1 in nsNativeComponentLoader::SelfRegisterDll ()
   from /home/tor/mopt/dist/bin/libxpcom.so
#15 0x400bf106 in nsNativeComponentLoader::AutoRegisterComponent ()
   from /home/tor/mopt/dist/bin/libxpcom.so
#16 0x400bdf1d in nsNativeComponentLoader::RegisterComponentsInDir ()
   from /home/tor/mopt/dist/bin/libxpcom.so
#17 0x400bddf1 in nsNativeComponentLoader::AutoRegisterComponents ()
   from /home/tor/mopt/dist/bin/libxpcom.so
#18 0x400bc3cf in nsComponentManagerImpl::AutoRegisterImpl ()
   from /home/tor/mopt/dist/bin/libxpcom.so
#19 0x400bbf38 in nsComponentManagerImpl::AutoRegister ()
   from /home/tor/mopt/dist/bin/libxpcom.so
#20 0x400c24a6 in nsComponentManager::AutoRegister ()
   from /home/tor/mopt/dist/bin/libxpcom.so
#21 0x0804dce3 in NS_AutoregisterComponents ()
#22 0x0804ddbe in NS_SetupRegistry_1 ()
#23 0x0804cde7 in main1 ()
#24 0x0804dc9b in main ()
#25 0x4024ef31 in __libc_start_main (main=0x804db4c <main>, argc=1, 
    ubp_av=0xbffff944, init=0x804a0b0 <_init>, fini=0x80520cc <_fini>, 
    rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbffff93c)
    at ../sysdeps/generic/libc-start.c:129

Comment 6

[tor]

Backing out blizzard's changes to gfx/src/gtk fixed the problem for me, too.

Comment 7

[Christopher Blizzard (:blizzard)]

I would love to know what is causing this.  Can people play with the link lines
for the gfx library to see if they can change the way that it behaves?

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Yesterday, when I tried removing -lXinerama, it failed to load gfx because of an
undefined symbol.  So I'm not sure what room for experimentation we have...

Comment 9

[Christopher Blizzard (:blizzard)]

What about adding the full patch to the .a library?

Comment 10

[Brian Ryner (not reading)]

Updating to a newer binutils version and relinking libgfx_gtk.so seemed to fix
this for me.

Comment 11

[Christopher Blizzard (:blizzard)]

Too bad that's not an option for most people.  I want to make this an --enable
flag instead of just turning it on if the libs are there.

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Yeah, upgrading binutils fixed it for me too, although I had to clobber my whole
optimized build before it started working again...

Comment 13

[Dan Rosen]

<aol>me too</aol>

Comment 14

[Christopher Blizzard (:blizzard)]

Attachment: configure patch

Comment 15

[Christopher Blizzard (:blizzard)]

I've added an explicit --enable-xinerama flag here.  cls, can you have a quick
look at this?  Would you rather that I don't set the -lXinerama until the
--enable check or unset it or something?  Leaving the flag set and checking in a
child makefile seems kind of silly.

Comment 16

[cls]

r=cls on the patch. 

Comment 17

[Christopher Blizzard (:blizzard)]

Checked in.