Closed Bug 204804 Opened 23 years ago Closed 23 years ago

SIGSEGV, in PR_UnloadLibrary and on exit

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
HP
HP-UX
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.4final

People

(Reporter: kishan.thomas, Assigned: kishan.thomas)

Details

(Keywords: crash)

Attachments

(1 file, 4 obsolete files)

patch
3.57 KB, patch
blizzard
: review+
netscape
: superreview-
sspitzer
: approval1.4+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.4b) Gecko/20030506 Build Identifier: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.4b) Gecko/20030506 Mozilla 1.4b trunk build on HP-UX 11.0 PARISC with aCC compilers. Mozilla comes up fine first time when the compreg.dat is not present, But gets a SIGSEGV on exiting. Subsequent runs of mozilla fails with a SIGSEGV during initilisation. On deleting mozilla/components/compreg.dat, mozilla comes up but gets the SIGSEGV on exiting and creates a new compreg.dat, and fails on subsequent runs. See traces from the failures below. Reproducible: Always Steps to Reproduce: During the build we had to patch the following compiler error, while compiling mozilla/xpcom/ds/nsTHashtable.cpp Error 172: "/tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-java05-Tue-May--6-230659-PDT-2003-nopatch/mozilla/xpcom/ds/nsTHashta ble.h", line 234 # Undeclared variable 'PL_DHashStubEnumRemove'. PL_DHashTableEnumerate(&mTable, PL_DHashStubEnumRemove, nsnull); ^^^^^^^^^^^^^^^^^^^^^^ Moving the PL_DHashStubEnumRemove definition to the top of file before nsTHashtable class fixed this compile error. 1. The SIGSEGV during exit of first run Program received signal SIGSEGV, Segmentation fault. nsHashtable::~nsHashtable (this=0x0, #free=1073814712) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/xpcom/ds/nsHashtable.cpp: 167 (gdb) bt #0 nsHashtable::~nsHashtable (this=0x0, #free=1073814712) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/xpcom/ds/nsHashtable.cpp: 167 #1 0x6f577f74 in _shlInit () from /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/obj/dist/bin/libxpcom.sl #2 0x6fd9b978 in __shlInit () from /usr/lib/libCsup.2 #3 0x6b3575b8 in _shlInit () from /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/obj/dist/bin/components/ libaddrbook.sl #4 0x6fd9b3b0 in __shlinit () from /usr/lib/libCsup.2 #5 0x6fd9b688 in __callInitFuncFromHandle () from /usr/lib/libCsup.2 #6 0x6fd9d548 in __niamHelper () from /usr/lib/libCsup.2 #7 0x6fd9d6c4 in _niam_body () from /usr/lib/libCsup.2 #8 0x6fd9d7c8 in _niam () from /usr/lib/libCsup.2 #9 0x6ff24cf8 in exit () from /usr/lib/libc.2 (gdb) l 162 } 163 } 164 } 165 166 167 nsHashtable::~nsHashtable() { 168 MOZ_COUNT_DTOR(nsHashtable); 169 if (mHashtable.ops) 170 PL_DHashTableFinish(&mHashtable); 171 if (mLock) PR_DestroyLock(mLock); (gdb) 2. The SIGSEGV during bring up after the the first run, with compreg.dat present Program received signal SIGSEGV, Segmentation fault. 0x6f808330 in PR_UnloadLibrary (lib=0x401230b8) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/nsprpub/pr/src/linking/prlink.c:1356 1356 result = shl_unload(lib->dlh); Current language: auto; currently c (gdb) bt #0 0x6f808330 in PR_UnloadLibrary (lib=0x401230b8) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/nsprpub/pr/src/linking/prlink.c:1356 #1 0x6f615b24 in nsDll::Load (this=0x40122ef8) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/xpcom/components/xcDll.cpp:239 #2 0x6f60fe0c in nsNativeComponentLoader::GetFactory (this=0x4002e4b0, aCID=@0x401034a8, aLocation=0x401034c8 "gre:libembedcomponents.sl", aType=0x4002e4e0 "application/x-mozilla-native", _retval=0x6fff1554) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/xpcom/components/nsNativeComponentLoader.cpp:110 #3 0x6f695d44 in nsFactoryEntry::GetFactory (this=0x401034a8, aFactory=0x6fff1554, mgr=0x40033070) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/xpcom/components/nsComponentManager.h:327 #4 0x6f604288 in nsComponentManagerImpl::CreateInstanceByContractID (this=0x40033070, aContractID=0x51180 "@mozilla.org/embedcomp/appstartup-notifier;1", aDelegate=0x0, aIID=@0x40001cb0, aResult=0x6fff1458) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/xpcom/components/nsComponentManager.cpp:1993 #5 0x47e8c in nsCreateInstanceByContractID::operator() (this=0x6fff13a0, aIID=@0x40001cb0, aInstancePtr=0x6fff1458) at nsComponentManagerUtils.cpp:75 #6 0x47398 in nsCOMPtr_base::assign_from_helper (this=0x6fff1294, helper=@0x6fff13a0, iid=@0x40001cb0) at nsCOMPtr.cpp:81 #7 0x1da00 in nsCOMPtr<nsIObserver>::nsCOMPtr () #8 0x1ccb4 in main1 (argc=1, argv=0x6fff0f9c, nativeApp=0x400fe498) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1102 #9 0x1eef4 in main (argc=1, argv=0x6fff0f9c) at /tmp_mnt/proj/client_java/mozilla/NIGHTLY/BUILD/PA-kabuto-Tue-May--6-230836-PDT-2003-patch/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1647 (gdb) l 1351 #ifdef XP_UNIX 1352 #ifdef HAVE_DLL 1353 #ifdef USE_DLFCN 1354 result = dlclose(lib->dlh); 1355 #elif defined(USE_HPSHL) 1356 result = shl_unload(lib->dlh); 1357 #elif defined(USE_MACH_DYLD) 1358 result = NSUnLinkModule(lib->dlh, NSUNLINKMODULE_OPTION_NONE) ? 0 : -1; 1359 #else 1360 #error Configuration error (gdb)
Filed bug 204808 for the compile error.
Summary: SIGSEGV, Segmentation fault. SIGSEGV at nsHashtable::~nsHashtable (this=0x0, #free=1073814712) → SIGSEGV, in PR_UnloadLibrary and on exit SIGSEGV at nsHashtable::~nsHashtable (this=0x0, #free=1073814712)
Keywords: crash
looks like in the first run al lcomponenets are shl_load() ed, but nothing gets shl_unload() ed so we dont hit the error. In the later runs with compreg.dat present there are shl_load() and shl_unload() of the shared libraries using information from compreg.dat/xpti.dat and this is when we hit the SIGSEGV in shl_unload. I think this new shared library loading/unloading was added as part of the new GRE support as explained in Bug 193442, and the cheges in xcDll.cpp ( 1. callss to shl_load and shl_unlaod first run without any compreg.dat shl_load ./libxpcom.sl (1) handle = 6ffee500 shl_load /tmp/mozilla/components/libxpcom_compat_c.sl (1) handle = 6ffee89c shl_load /tmp/mozilla/components/libxpconnect.sl (1) handle = 6ffeeb04 shl_load /tmp/mozilla/components/libuconv.sl (1) handle = 6feab004 shl_load /tmp/mozilla/components/libucvmath.sl (1) handle = 6feab138 shl_load /tmp/mozilla/components/libi18n.sl (1) handle = 6feab26c shl_load /tmp/mozilla/components/libjar50.sl (1) handle = 6feab3a0 shl_load /tmp/mozilla/components/liboji.sl (1) handle = 6feab608 shl_load /tmp/mozilla/components/libjsd.sl (1) handle = 6feab870 shl_load /tmp/mozilla/components/libtransmngr_client.sl (1) handle = 6feab9a4 shl_load /tmp/mozilla/components/libipcdc.sl (1) handle = 6feabad8 shl_load /tmp/mozilla/components/libnecko.sl (1) handle = 6feabc0c shl_load /tmp/mozilla/components/libnecko2.sl (1) handle = 6feabd40 shl_load /tmp/mozilla/components/libpref.sl (1) handle = 6feabe74 shl_load /tmp/mozilla/components/libcaps.sl (1) handle = 6fd6193c shl_load /tmp/mozilla/components/libchrome.sl (1) handle = 6fd61a70 shl_load /tmp/mozilla/components/librdf.sl (1) handle = 6fd61ba4 shl_load /tmp/mozilla/components/libhtmlpars.sl (1) handle = 6fd61cd8 shl_load /tmp/mozilla/components/libgfxps.sl (1) handle = 6fd61e0c shl_load /tmp/mozilla/components/libgfx_gtk.sl (1) handle = 6fd62074 shl_load /tmp/mozilla/components/libimgmng.sl (1) handle = 6fd622dc shl_load /tmp/mozilla/components/libimglib2.sl (1) handle = 6fd62410 shl_load /tmp/mozilla/components/libgkplugin.sl (1) handle = 6fd62544 shl_load /tmp/mozilla/components/libjsdom.sl (1) handle = 6fab126c shl_load /tmp/mozilla/components/libwidget_gtk.sl (1) handle = 6fab13a0 shl_load /tmp/mozilla/components/libxremote_client.sl (1) handle = 6fab14d4 shl_load /tmp/mozilla/components/libgklayout.sl (1) handle = 6fab1608 shl_load /tmp/mozilla/components/libmork.sl (1) handle = 6fab173c shl_load /tmp/mozilla/components/libdocshell.sl (1) handle = 6fab1870 shl_load /tmp/mozilla/components/libprofile.sl (1) handle = 6fab19a4 shl_load /tmp/mozilla/components/libnsprefm.sl (1) handle = 6fab1ad8 shl_load /tmp/mozilla/components/libembedcomponents.sl (1) handle = 6fab1c0c shl_load /tmp/mozilla/components/libwebbrwsr.sl (1) handle = 6fab1d40 shl_load /tmp/mozilla/components/libeditor.sl (1) handle = 6fab1e74 shl_load /tmp/mozilla/components/libtxmgr.sl (1) handle = 6f8c9f04 shl_load /tmp/mozilla/components/libcomposer.sl (1) handle = 6f8ca038 shl_load /tmp/mozilla/components/libaccessibility.sl (1) handle = 6f8ca16c shl_load /tmp/mozilla/components/libmozldap.sl (1) handle = 6f8ca2a0 shl_load /tmp/mozilla/components/libnsappshell.sl (1) handle = 6f8ca63c shl_load /tmp/mozilla/components/libfileview.sl (1) handle = 6f8ca770 shl_load /tmp/mozilla/components/libmozfind.sl (1) handle = 6f8ca8a4 shl_load /tmp/mozilla/components/libxremoteservice.sl (1) handle = 6f8ca9d8 shl_load /tmp/mozilla/components/libappcomps.sl (1) handle = 6f8cab0c shl_load /tmp/mozilla/components/libxpinstall.sl (1) handle = 6f8cac40 shl_load /tmp/mozilla/components/libcookie.sl (1) handle = 6f8cad74 shl_load /tmp/mozilla/components/libwallet.sl (1) handle = 6f820004 shl_load /tmp/mozilla/components/libwalletviewers.sl (1) handle = 6f820138 shl_load /tmp/mozilla/components/libxmlextras.sl (1) handle = 6f82026c shl_load /tmp/mozilla/components/libp3p.sl (1) handle = 6f8203a0 shl_load /tmp/mozilla/components/libautoconfig.sl (1) handle = 6f8204d4 shl_load /tmp/mozilla/components/libtransformiix.sl (1) handle = 6f820608 shl_load /tmp/mozilla/components/libinspector.sl (1) handle = 6f82073c shl_load /tmp/mozilla/components/libuniversalchardet.sl (1) handle = 6f820870 shl_load /tmp/mozilla/components/libtypeaheadfind.sl (1) handle = 6f8209a4 shl_load /tmp/mozilla/components/libwebsrvcs.sl (1) handle = 6f820ad8 shl_load /tmp/mozilla/components/libpipboot.sl (1) handle = 6f820c0c shl_load /tmp/mozilla/components/libpipnss.sl (1) handle = 6f820d40 shl_load /tmp/mozilla/components/libpippki.sl (1) handle = 6f78e084 shl_load /tmp/mozilla/components/libmailnews.sl (1) handle = 6f78e1b8 shl_load /tmp/mozilla/components/libmsgdb.sl (1) handle = 6f78e420 shl_load /tmp/mozilla/components/libmsgnews.sl (1) handle = 6f78e554 shl_load /tmp/mozilla/components/liblocalmail.sl (1) handle = 6f78e688 shl_load /tmp/mozilla/components/libmimeemitter.sl (1) handle = 6f78e7bc shl_load /tmp/mozilla/components/libvcard.sl (1) handle = 6f78e8f0 shl_load /tmp/mozilla/components/libmime.sl (1) handle = 6f78ea24 shl_load /tmp/mozilla/components/libmsgcompose.sl (1) handle = 6f78eb58 shl_load /tmp/mozilla/components/libmsgimap.sl (1) handle = 6f6a3004 shl_load /tmp/mozilla/components/libaddrbook.sl (1) handle = 6f6a3138 shl_load /tmp/mozilla/components/libimport.sl (1) handle = 6f6a326c shl_load /tmp/mozilla/components/libimpText.sl (1) handle = 6f6a33a0 shl_load /tmp/mozilla/components/libimpComm4xMail.sl (1) handle = 6f6a34d4 shl_load /tmp/mozilla/components/libmsgmdn.sl (1) handle = 6f6a3608 shl_load /tmp/mozilla/components/libmailview.sl (1) handle = 6f6a373c shl_load /tmp/mozilla/components/libbayesflt.sl (1) handle = 6f6a3870 shl_load /tmp/mozilla/components/libmsgsmime.sl (1) handle = 6f6a39a4 shl_unload ./libxpcom.sl handle = 6ffee500 result = 0 2. calls to shl_load ans shl_unload in runs using datat from compreg.dat shl_load ./libxpcom.sl (1) handle = 6ffee500 shl_load ./libgkgfx.sl (1) handle = 6ffee634 shl_load ./libplds4.sl (1) handle = 6ffee164 shl_load ./libplc4.sl (1) handle = 6ffee030 shl_load ./libnspr4.sl (1) handle = 6ffeddc8 shl_load ./libpthread.sl (1) handle = 0 shl_load ./libmozjs.sl (1) handle = 6ffee298 shl_load ./components/libembedcomponents.sl (1) handle = 6ffee768 shl_unload ./libgkgfx.sl handle = 6ffee634 result = 0 shl_unload ./libplds4.sl handle = 6ffee164 result = 0 shl_unload ./libplc4.sl handle = 6ffee030 result = 0 shl_unload ./libnspr4.sl handle = 6ffeddc8 <-- SIGSEGV at shl_unload If I dont unload any libraries, in PR_UnloadLibrary everything seems to work. Also checked Mozilla 14a which works on HP-UX and there are no PR_UnloadLibrary() calls there.
> shl_unload ./libnspr4.sl handle = 6ffeddc8 <-- SIGSEGV at shl_unload PR_UnloadLibrary() is defined in libnspr4.sl, and this is the same library we are trying to PR_UnloadLibrary(). shl_unload() is called from libnspr4.sl on itself, on HP-UX PA32 doing so leads to undefined behaviour.
The following change at xcDLL.cpp nsDll::Load() does the unloading of the dependent libraries, which is leading to the SIGSEGV at shl_unload. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/xpcom/components&command=DIFF&root=/cvsroot&file=xcDll.cpp&rev1=1.60&rev2=1.61#12 As the comment says: "should we unload later - or even at all?" Without this unloading, everything seems to work fine on HP-UX 232 #if defined(XP_UNIX) 233 // Unload any of library dependencies we loaded earlier. The assumption 234 // here is that the component will have a "internal" reference count to 235 // the dependency library we just loaded. 236 // XXX should we unload later - or even at all? 237 238 if (extraData != nsnull) 239 { 240 PRInt32 arrayCount = dependentLibArray.Count(); 241 for (PRInt32 index = 0; index < arrayCount; index++) 242 PR_UnloadLibrary((PRLibrary*)dependentLibArray.ElementAt(index)); 243 } 244 #endif
This issue may not show up on other platforms, since PA32 shl_unlod behaviour may be diffrent from dlclose() man shl_unload On PA32, shl_unload unloads the shared library regardless of whether there are other references to it through other load invocations or through implicit references from other shared libraries. No reference count is kept. On PA64, a reference counter is kept for each loaded shared library, like the behavior of dlopen(3c) and dlclose(3c). shl_unload does not remove the shared library from the address space until all references to that shared library have been removed.
Added notes to 193442
unloading is a bad thing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: SIGSEGV, in PR_UnloadLibrary and on exit SIGSEGV at nsHashtable::~nsHashtable (this=0x0, #free=1073814712) → SIGSEGV, in PR_UnloadLibrary and on exit
.
Assignee: dougt → kishan.thomas
Adding the patch to xcDll.cpp, to remove the dependent library unloading in nsDll::Load()
Comment on attachment 123219 [details] [diff] [review] Removed dependent library unloading from nsDll::Load() There is not reason to keep the dependentLibArray is there.
Attachment #123219 - Flags: review-
resubmitting patch, removed dependentLibArray which is no longer used.
Attachment #123219 - Attachment is obsolete: true
Please make that #ifdef HPUX. Most other modern unix platforms support unloading without problems.
Submitting the same patch with #ifdef HPUX as suggested. But if they are "dependent" libs, other UNIX platforms will also not unload them from the addressspace untill all references are removed, so are these unloads really required ? Not obsoleting the earlier patch attachment 123232 [details] [diff] [review]. Please choose the right patch.
The dependent libraries in question can be mozilla libs as well. In order to do proper leak detection we need to unload the libraries in question.
Attachment #123232 - Attachment is obsolete: true
Attachment #123245 - Attachment is obsolete: true
dougt/blizzard can you please review the patch
Comment on attachment 123351 [details] [diff] [review] obsoleting old patches,new patch with if !defined(HPUX) should we just disable dependent lib loading on HPUX in its entirety?
The dependent librray loading part seems to work fine with the patch. The only place the patch might have affect is during the unloading of a component. HP-UX shl_unload will unload the component but the dependent libs will stay in memory till we exit.
Attached patch patch — — Splinter Review
Attachment #123351 - Attachment is obsolete: true
Attachment #123432 - Flags: review?(blizzard)
Attachment #123432 - Flags: approval1.4?
Comment on attachment 123432 [details] [diff] [review] patch r=blizzard
Attachment #123432 - Flags: review?(blizzard) → review+
Comment on attachment 123432 [details] [diff] [review] patch maybe this should be something that can be done inside using configure, or in rules.mk, instead of here, using #ifdef HPUX?
why polute configure with something so isolated?
is it something that another platform / compiler might need? ok, not configure, but maybe rules.mk? (or do you feel that's over kill, since you only need this one file) so if not rules.mk, what about in mozilla\xpcom\components\Makefile.in also what about all these: http://lxr.mozilla.org/mozilla/search?string=PR_UnloadLibrary making this block 1.4, to convince doug / kishan that something will land for 1.4. I'm sure we're like one or two more comments before a=.
Flags: blocking1.4+
Comment on attachment 123432 [details] [diff] [review] patch new idea: a=sspitzer, and I'll leave the review (my apologies, doug) to bliz and cls. he's not around, but maybe cls can look at this after-the-fact, and comment.
Attachment #123432 - Flags: superreview?(seawood)
Attachment #123432 - Flags: approval1.4?
Attachment #123432 - Flags: approval1.4+
should land in 1.4, as I'm sure HP hopes to ship that.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.4final
Yes, would like to have this in for 1.4, since its a crash for HPUX > http://lxr.mozilla.org/mozilla/search?string=PR_UnloadLibrary I did put a breakpoint at PR_UnloadLibrary, and checked to see any other possible unloading failure. So far no other failures, doing more testing to make sure of all codepaths.
Checking in xcDll.cpp; /cvsroot/mozilla/xpcom/components/xcDll.cpp,v <-- xcDll.cpp new revision: 1.71; previous revision: 1.70 done
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment on attachment 123432 [details] [diff] [review] patch Ooops. Didn't realize this was hanging out there. I don't like the solution of only disabling this for HPUX. It's not clear to me that unloading libnspr using a libnspr function call is a valid thing to do, even if it does happen to work everywhere else for now. Since xpcom ultimately controls the loading and unloading functionality and everything depends upon xpcom, I don't think xpcom or any of its dependent libs should be on the list of libraries to explicitly load or unload. Just my 2cents.
Attachment #123432 - Flags: superreview?(seawood) → superreview-
cls, this patch is fine. we are loading depend libraries -- not components. The reason we do this is to ensure that external symbols are defined before the component is loaded. On some platforms, calling unload on a library that you still are referencing is illegal. For example, suppose a dependent library list libc. On an OS that doesn't reference count dl_open's, calling dl_close on a library you actively are using would be deadly.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: