9292 - Linux/RH5.2: Crash in dlopen()

Status: VERIFIED FIXED

(Core Graveyard :: Tracking, defect, P1)

Description

[tlewis]

I had this problem with M7 and with:

ftp://ftp.mozilla.org/pub/mozilla/nightly/1999-07-05-08-M8/mozilla-i686-pc-linux-gnu.tar.gz

When I try to run apprunner, it just exist on me, like this:

reflections% /opt/mozilla/mozilla-apprunner.sh
MOZILLA_FIVE_HOME=/opt/mozilla
  LD_LIBRARY_PATH=/opt/mozilla
      MOZ_PROGRAM=./apprunner
        moz_debug=0
     moz_debugger=
Registered Ok
*** Registering html library
reflections%

This is a very unfortunate exit; I have no idea why it is gone!  Running it
manually under gdb reveals the following:

reflections% export MOZILLA_FIVE_HOME=/opt/mozilla
reflections% apprunner
Registered Ok
*** Registering html library
reflections% gdb apprunner
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)...
(gdb) b exit
Breakpoint 1 at 0x80512b4
(gdb) r
Starting program: /opt/mozilla/apprunner
Linux thread target has modified Unknown signal handling
Breakpoint 1 at 0x404fb532: file exit.c, line 40.
Cannot access memory at address 0x7a6f6d2f.
(gdb) backtrace
#0  _dl_debug_state () at dl-debug.c:56
#1  0x4000a12b in _dl_catch_error (errstring=0xbffff3b8, operate=0x405b37a0
<dl_open_worker>,
    args=0xbffff3bc) at dl-error.c:141
#2  0x405b39fd in _dl_open (file=0x811b7b0
"/opt/mozilla/components/libuconv.so", mode=2) at dl-open.c:176
#3  0x403b2730 in dlopen_doit (a=0xbffff4c4) at dlopenold.c:43
#4  0x4000a12b in _dl_catch_error (errstring=0x8116c64, operate=0x403b2708
<dlopen_doit>, args=0xbffff4c4)
    at dl-error.c:141
#5  0x403b2608 in _dlerror_run (operate=0x403b2708 <dlopen_doit>,
args=0xbffff4c4) at dlerror.c:122
#6  0x403b26f5 in __dlopen_nocheck (file=0x811b7b0
"/opt/mozilla/components/libuconv.so", mode=2)
    at dlopenold.c:58
#7  0x4038ba0d in PR_LoadLibrary ()
#8  0x40173794 in nsDll::Load ()
#9  0x4017017d in nsComponentManagerImpl::SelfRegisterDll ()
#10 0x4017006f in nsComponentManagerImpl::AutoRegisterComponent ()
#11 0x4016fb31 in nsComponentManagerImpl::SyncComponentsInDir ()
#12 0x4016f982 in nsComponentManagerImpl::AutoRegister ()
#13 0x401726ac in nsComponentManager::AutoRegister ()
#14 0x805250b in main ()
#15 0x8052a32 in main ()
#16 0x80517c5 in main ()
(gdb)

This is a fairly normal redhat-5.2, Pentium-II machine.

Feel free to contact me if I can be of more assistance.

Comment 1

[don]

Resolved as WORKSFORME.  I just don't see this problem.  Today's Linux build
works better than the Windows build.  Perhaps this has been fixed?

Comment 2

[leger]

More info per tlewis via mail:
I downloaded  yesterday's build; today's directory only has IRIX:
ftp://ftp.mozilla.org/pub/mozilla/nightly/1999-07-06-08-M8/mozilla-i686-pc-linux
-gnu.tar.gz

apprunner still exits without displaying anything:

(gdb) b exit
(gdb) r
(...)
(gdb) backtrace
#0  _dl_debug_state () at dl-debug.c:56
#1  0x4000a12b in _dl_catch_error (errstring=0xbffff3d8,
    operate=0x405b27a0 <dl_open_worker>, args=0xbffff3dc) at
dl-error.c:141
#2  0x405b29fd in _dl_open (
    file=0x811b798 "/opt/mozilla/components/libuconv.so", mode=2)
    at dl-open.c:176
#3  0x403b1730 in dlopen_doit (a=0xbffff4e4) at dlopenold.c:43
#4  0x4000a12b in _dl_catch_error (errstring=0x8116c4c,
    operate=0x403b1708 <dlopen_doit>, args=0xbffff4e4) at
dl-error.c:141
#5  0x403b1608 in _dlerror_run (operate=0x403b1708 <dlopen_doit>,
    args=0xbffff4e4) at dlerror.c:122
#6  0x403b16f5 in __dlopen_nocheck (
    file=0x811b798 "/opt/mozilla/components/libuconv.so", mode=2)
    at dlopenold.c:58
#7  0x4038aa0d in PR_LoadLibrary ()
#8  0x40172794 in nsDll::Load ()
#9  0x4016f17d in nsComponentManagerImpl::SelfRegisterDll ()
#10 0x4016f06f in nsComponentManagerImpl::AutoRegisterComponent ()
#11 0x4016eb31 in nsComponentManagerImpl::SyncComponentsInDir ()
#12 0x4016e982 in nsComponentManagerImpl::AutoRegister ()
#13 0x401716ac in nsComponentManager::AutoRegister ()
#14 0x8052513 in main ()
#15 0x8052a3a in main ()
#16 0x80517c5 in main ()
(gdb)

viewer fails a little more spectacularly:

reflections% gdb ./viewer
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
(gdb) r
Starting program: /opt/mozilla/./viewer
Linux thread target has modified Unknown signal handling
Warning: MOZILLA_FIVE_HOME not set.
Cannot access memory at address 0x7a6f6d2f.
(gdb) backtrace
#0  _dl_debug_state () at dl-debug.c:56
#1  0x4000a12b in _dl_catch_error (errstring=0xbffff4a4,
    operate=0x405997a0 <dl_open_worker>, args=0xbffff4a8) at
dl-error.c:141
#2  0x405999fd in _dl_open (
    file=0x8131470 "/opt/mozilla/components/libuconv.so", mode=2)
    at dl-open.c:176
#3  0x40397730 in dlopen_doit (a=0xbffff5b0) at dlopenold.c:43
#4  0x4000a12b in _dl_catch_error (errstring=0x812cb64,
    operate=0x40397708 <dlopen_doit>, args=0xbffff5b0) at
dl-error.c:141
#5  0x40397608 in _dlerror_run (operate=0x40397708 <dlopen_doit>,
    args=0xbffff5b0) at dlerror.c:122
#6  0x403976f5 in __dlopen_nocheck (
    file=0x8131470 "/opt/mozilla/components/libuconv.so", mode=2)
    at dlopenold.c:58
#7  0x40370a0d in PR_LoadLibrary ()
#8  0x40338794 in nsDll::Load ()
#9  0x4033517d in nsComponentManagerImpl::SelfRegisterDll ()
#10 0x4033506f in nsComponentManagerImpl::AutoRegisterComponent ()
#11 0x40334b31 in nsComponentManagerImpl::SyncComponentsInDir ()
#12 0x40334982 in nsComponentManagerImpl::AutoRegister ()
#13 0x403376ac in nsComponentManager::AutoRegister ()
#14 0x805c8f5 in nsBrowserWindow::PromptPassword ()
#15 0x805c918 in nsBrowserWindow::PromptPassword ()
#16 0x805c984 in nsBrowserWindow::PromptPassword ()
#17 0x805439f in main ()
(gdb)

reflections% file /opt/mozilla/components/libuconv.so
/opt/mozilla/components/libuconv.so: ELF 32-bit LSB shared object,
Intel 80386, version 1, stripped

Unfortunately, libIDL-devel conflicts with my CORBA ORB, ORBit,
which
I need for my main development project, and so I can not do a source
build on this machine easily.  I may do that soon, however, if you
guys
can't figure this out, and then add some debugging code.

Hope this helps!

Comment 3

[don]

I'm gonna have to find someone to own this bug ...

Comment 4

[tlewis]

Tried again with build:

ftp://ftp.mozilla.org/pub/mozilla/nightly/1999-07-14-08-M8/mozilla-i686-pc-linux-gnu.tar.gz

now viewer segfaults on me:

reflections% gdb ./viewer                                          /opt/mozilla
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
(gdb) r
Starting program: /opt/mozilla/./viewer
Linux thread target has modified Unknown signal handling
Warning: MOZILLA_FIVE_HOME not set.
Registered Ok
*** Registering html library
register filter service
Going to create the event queue

Program received signal SIGSEGV, Segmentation fault.
0x4005d73f in nsWidget::SetFont ()
(gdb) backtrace
#0  0x4005d73f in nsWidget::SetFont ()
#1  0x40051e88 in NS_CreateButton ()
#2  0x80594cd in nsBrowserWindow::QueryInterface ()
#3  0x8059095 in nsBrowserWindow::QueryInterface ()
#4  0x805d47b in nsBrowserWindow::PromptPassword ()
#5  0x805426c in _start ()
#6  0x80543ed in main ()

I'd like to help fix this problem, but I'm not sure how, so I am
reporting it for now.

It's been several weeks since I could run the nightly builds on my system.
Redhat 5.2, standard so far as I know, pentium machine.  I can include the
output of rpm -qa if anyone thinks it'd help.  I have upgraded some of my
GNOME packages, including, I imaging, gtk+ and glib, so that might have
something to do with it.

Someone please let me know what I can do to help resolve this problem.

Comment 5

[don]

Chris, does anybody on IRIX anymore?  Who can check this one out.  I haven't a
clue ...

Comment 6

[chris hofmann]

lets try jasonh to see if he sees this or has some ideas

Comment 7

[Kenneth Herron]

I've been experiencing the _dl_debug_state problem consistently with both
viewer and apprunner on RH 6.0, and I have a partial explanation.

_dl_debug_state() is an empty function in libdl; it's called every time libdl
makes a change to the internal list of shared libraries loaded, so that any
debugger controlling the process can slap a breakpoint on this
function to be notified that shared libs are being loaded or unloaded.
Libdl also maintains some other structures for the debugger's benefit.

When the process halts in _dl_debug_state() and gdb reports "Cannot access
memory at...", gdb has just encountered a wild pointer while reading through
some data maintained by libdl.  In my experience this confuses gdb enough that
it halts the process and you can't examine variables or continue the process
after this point.  But the process didn't access this pointer, gdb did, so the
hit only occurs when running under the debugger.

I'm not sure exactly what symbols libdl maintains for the debugger, but
it appears to be a struct called _r_debug; this contains a head pointer to
a linked list of shared libraries and some other things.  I haven't located
the exact memory that's making gdb blow up, but it was allocated through
malloc/realloc and never initialized.  I suspect it's a latent bug in libdl or
some subtle multithreading issue.

Workaround is not to start the apps from the debugger :-(  You can run gdb
separately and attach to the app once it has had a chance to run for a while.

I'll also observe that bug 9113 appears to be the same (linux) problem.  I'm
not clear why this is tagged as an IRIX bug; I'm going to risk peoples' wrath
by re-tagging it linux.

Comment 8

[Chris McAfee]

CC-ing jason, assigning to blizzard to see if this is a dup of 8849.

Comment 9

[Chris McAfee]

resummarizing

Comment 10

[Christopher Blizzard (:blizzard)]

Looks pretty similar to me.

*** This bug has been marked as a duplicate of 8849 ***

Comment 11

[chris hofmann]

verified dup

Comment 12

[Christopher Blizzard (:blizzard)]

Please ignore the spam.  Changing address.

Comment 13

[Christopher Blizzard (:blizzard)]

busted when I reassigned

Comment 14

[Christopher Blizzard (:blizzard)]

busted when I reassigned