279181 - SIGSEGV on exit mozilla , on HPUX

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Gowri Kandasamy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: mozilla/5.0 (X11; U; HP-UX 9000/800; en-US; rv:1.7.3)

Mozilla on HP-UX dumps core when exiting mozilla for the first time.
This is caused by referencing nsACString() after unloading the
libxpcom.sl library  from XPCOMGlueShutdown() from main().

#0  nsACString::~nsACString (this=0x79cbc500, #free=2) at nsTAString.cpp:55
#1  0x7adedf50 in __niamHelper+0xb0 () from /usr/lib/libCsup.2
#2  0x7adee0a8 in _niam_body+0x78 () from /usr/lib/libCsup.2
#3  0x7adee1c4 in _niam+0x1c () from /usr/lib/libCsup.2
#4  0x7af886d4 in exit+0x74 () from /usr/lib/libc.2
(gdb) print *this
$5 = {mVTable = 0x7a42ca48, mData = 0x79f590dd "secure", mLength = 6, mFlags = 1}


This issue may not show up on other platforms, since PA32
shl_unload behavior may be different from dlclose()
In other platforms, the library is not unloded by shl_unload, 
as there is a reference to the shlib.

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 dl
close(3c).  shl_unload does not remove the shared library from the address space
until all references to that
shared library have been removed.


 This is similar to the bug 204804 .  

libxpcom.sl should not be unloaded on HP-UX.


This works fine until 1.6. This problem started after adding the file
nsTAString.h . nsACString object reference is not getting deleted
before unloading xpcom.

Reproducible: Always

Steps to Reproduce:
1. compres.dat & xpti.dat should not be present in /opt/mozilla/componets directory.
2. Start mozilla 
3. Choose Exit from the browser.
 
Actual Results:  
Gets a SIGSEGV  on Exit and dumps core.

Expected Results:  
Exited normally

Comment 1

[Olaf Flebbe]

Attachment: Implemented patch es described by original reporter

I tested this patch and it seems too work for us.

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Olaf Flebbe]

Comment on attachment 174655 [details] [diff] [review]
Implemented patch es described by original reporter

This one is very nasty on HP-UX

Comment 4

[Josh Aas]

XPCOM only needs one review, requesting review from module owner.

Comment 5

[Doug Turner (:dougt)]

Comment on attachment 174655 [details] [diff] [review]
Implemented patch es described by original reporter

in the patch, can you comment why this is a problem for hpux and cite this bug number.

Comment 6

[timeless]

are all instances of xpcom being loaded via nspr? if so, can't we fix nspr to do the reference counting for us? if not, is there any way for nspr to find out that someone else has already loaded the library so that it can decide not to do something useful when PR_UnloadLibrary is called?

Comment 7

[Wan-Teh Chang]

NSPR already has a reference count for the PRLibrary structure.
PR_UnloadLibrary only calls the HP-UX shl_unload function when
the reference count becomes 0.

Comment 8

[Olaf Flebbe]

Platform ist not relevant any more. Closing as wontfix.