70543 - N601 Mac #8 [@ pr_FindSymbolInLib]

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[Curt Patrick (gone)]

This is the #8 crasher in the N601 release. All of the crashes so far have come 
from OS 9. There are a few comments that might be of some help:

Comment: Stdlog : PowerPC unmapped memory exception at 3D89D914 
PR_UnloadLibrary+0021C

Comment: Trying to access amy email using the envelope icon on the bottom of the 
page. After clicking the icon, the page hung and I had to restart.

Comment: clicked on 'view stored passwords' in the preferences

Stack Trace:
-----
pr_FindSymbolInLib()   [prlink.c  line 1116] 
         PR_FindSymbol()        [prlink.c  line 1212] 
         nsDll::FindSymbol()    [xcDll.cpp  line 381] 
         nsDll::GetModule()     [xcDll.cpp  line 422] 
         nsNativeComponentLoader::GetFactoryFromModule()        
[nsNativeComponentLoader.cpp  line 1167] 
         nsNativeComponentLoader::GetFactory()  [nsNativeComponentLoader.cpp  
line 136] 
         nsComponentManagerImpl::FindFactory()  [nsComponentManager.cpp  line 
1030] 
         nsComponentManagerImpl::CreateInstance()       [nsComponentManager.cpp  
line 1195]

Source File : prlink.c line : 1116

Some urls:
        URL:(26941613) www.half.com
        URL:(27030566) www.nytimes.com

Comment 1

[Curt Patrick (gone)]

Adding "crash" and "topcrash" for tracking.

Comment 2

[Wan-Teh Chang]

Assigned the bug to Steve.

Comment 3

[Steve Dagley]

Lisa, have any of the internal QA folks seen this crash?  I need help to repro 
it.

Comment 4

[lchiang]

steve, let me check around for you.

Comment 5

[lchiang]

Searching Talkback shows that this crash also occurred in 6.00 so it's now a new
incident.  Most incidents also talk about crashing on startup.

I need Curt/Shiva/Jay to generate a customized report for me detailing user's
comments plus email addresses so that I don't have to click on each incident one
by one which is very slow on cyclone.

Comment 6

[lchiang]

I've emailed one user for add'l info.

Comment 7

[Steve Dagley]

Thanks Lisa, I'll follow up with Jay about that report

Comment 8

[Steve Dagley]

Just noting that this bug is related to <http://bugzilla.mozilla.org/
show_bug.cgi?id=64978>

Comment 9

[lchiang]

Good finding, Steve.  Jay - it may be good to get a Talkback report to see if
there are incidents of this crash on the TRUNK builds.  And if so, see if they
stop getting reported.  In the other bug, jj thinks the problem may have been
fixed on the trunk builds around 2-28.  Thanks.

Comment 10

[Steve Dagley]

Unfortunately #64978 only applies to autoreg problems.  The trigger (being out of 
FCBs) is the same as this bug but the fix there doesn't help us here.

Comment 11

[Simon Fraser [no longer active]]

No, the trunk fix will probably not make this bug go away. There are still 
unresolved FCB-related issues.

Comment 12

[lchiang]

I have spoken with sdagley.  I will contact about 20 or so people on the
incident reports to ask for specific info, referencing comments from the Apple
person in bug 64978 on system specific info.  More update as I get responses and
forward them to sdagley and he finds a common thread.  Thanks.  This may take a
few days to get responses.

Comment 13

[Steve Dagley]

Lisa, One bit of info I'm specifically interested in is if they are using the 
Multiple Users feature of Mac OS 9.  If so, are they logged in as the owner or a 
restricted user?  (Multiple Users patches the file system in a manner that could 
increase the odds of running out of FCBs when opening files)

Comment 14

[Steve Dagley]

Quick summary: the trigger for this crash, in most cases, is running out of 
available FCBs (fork/file control blocks) resulting in an error when we try to 
load a library.  The OS is supposed to be able to grow the FCB table when it's 
running low but this isna't always happening so Apple has been consulted as to 
what's causing it.  So far their suggested causes haven't covered all cases where 
we've seen the problem.  The workaround is to make a SystemTask() call to 
explicitly yield time to the OS allowing it to grow the FCB table, preferably 
only when the table is almost full.  Unfortunately the FCB table is now an opaque 
data structure and the only obvious way to find out the active FCB count it to 
iterate through all mounted volumes and active FCBs for each to reach a count.  
Apple has been asked if there's a more efficient way.  Short of that we can 
simply make the SystemTask() call every time we try to load a library.  I'm doing 
timing tests now to see what impact this has on app launch time.  So far large 
grain tests on debug builds don't show any significant degradation.  Now building 
optimized for fine grain testing.

Comment 15

[Steve Dagley]

Attachment: Patch to yield time to OS before any library load

Comment 16

[Steve Dagley]

sfraser, can you sr= the patch I attached as the current solution for this bug?

Comment 17

[Simon Fraser [no longer active]]

I think it's better to just remove the stuff in nsNativeComponentLoader.cpp 
altogether.

Comment 18

[Steve Dagley]

Code is checked in.  I'm going to mark this one fixed and work with lchiang to 
see if we can get some of the external folks that have experienced this crash to 
try a nightly build with the change to verify