Closed Bug 9292 Opened 25 years ago Closed 25 years ago

Linux/RH5.2: Crash in dlopen()

Categories

(Core Graveyard :: Tracking, defect, P1)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: tlewis, Assigned: blizzard)

Details

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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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?
Status: RESOLVED → REOPENED
OS: Linux → IRIX
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!
Resolution: WORKSFORME → ---
Priority: P3 → P1
Target Milestone: M9
I'm gonna have to find someone to own this bug ...
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.
Assignee: don → chofmann
Status: REOPENED → NEW
Component: Browser-General → other
Target Milestone: M9
Chris, does anybody on IRIX anymore? Who can check this one out. I haven't a clue ...
Assignee: chofmann → jasonh
lets try jasonh to see if he sees this or has some ideas
OS: IRIX → Linux
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.
Assignee: jasonh → blizzard
Summary: mozilla won't start! → Crash in dlopen()
CC-ing jason, assigning to blizzard to see if this is a dup of 8849.
Summary: Crash in dlopen() → Linux/RH5.2: Crash in dlopen()
resummarizing
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → DUPLICATE
Looks pretty similar to me. *** This bug has been marked as a duplicate of 8849 ***
Status: RESOLVED → VERIFIED
verified dup
Please ignore the spam. Changing address.
Assignee: blizzard → blizzard
Status: VERIFIED → NEW
busted when I reassigned
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: DUPLICATE → FIXED
busted when I reassigned
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.