Closed Bug 204804 Opened 21 years ago Closed 21 years ago

SIGSEGV, in PR_UnloadLibrary and on exit

Categories

(Core :: XPCOM, defect)

HP
HP-UX
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.4final

People

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

Details

(Keywords: crash)

Attachments

(1 file, 4 obsolete files)

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 patchSplinter 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: 21 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: