Closed Bug 97407 Opened 23 years ago Closed 23 years ago

OS X: crash upon quit [in __destroy_global_chain ()] - Trunk & M094 [@ .__ptr_glue 502c2db5 - nsImapProtocol::Run] [@ 0xffc10000 5df6c087 - nsImapProtocol::Run]

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 90093

People

(Reporter: bugzilla, Assigned: sdagley)

Details

(Keywords: crash, topcrash)

Crash Data

this is a rather tricky crasher. it doesn't happen every time i quit, but i've
encountered today using 2001.08.28.05-comm bits, as well as y'day using
2001.08.27.05-comm bits.

if anyone could help trying to find a reproducible case here, that'd be great.
i've ruled out bug 90893 and bug 85048, since the trace info differs from mine.
[also, i wasn't able to repro bug 85048. will retest the case in 90893 soon.]

the last time i encountered this, i had done the following:

1. did a search at http://google.com
2. clicked on a link there.
3. went back to the google results page.
4. quit the app [used cmd+Q, fwiw].

note: my machine sat idle for about an hour or more btwn steps 3 and 4. could
that be a factor? just wondering, since i repeated the above steps with any idle
time btwn steps 3 and 4, and didn't crash.

here's the crash report. at the very least this bug can searched for on the
basis of the stack if other encounter similar issues...

Date/Time: 2001-08-28 18:16:29 -0700

PID:       328
Command:   Netscape 6

Exception: EXC_BAD_ACCESS (0x0001)
Codes:     KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0:
 #0   0x00000000 in 0x0 ()
 #1   0x000b34b0 in __destroy_global_chain ()
 #2   0x000f0688 in exit ()

Thread 1:
 #0   0x7000424c in _syscall ()
 #1   0x706584b8 in _ProcessReadyEvent ()
 #2   0x706582b0 in _CarbonSelectThreadFunc ()
 #3   0x70014f04 in __pthread_body ()

Thread 2:
 #0   0x70059b68 in _semaphore_wait_signal_trap ()
 #1   0x70016110 in _semaphore_wait_signal ()
 #2   0x70015f78 in __pthread_cond_wait ()
 #3   0x70015d18 in _pthread_cond_wait ()
 #4   0x70653be0 in _BSD_pthread_cond_wait ()
 #5   0x70653bc0 in _CarbonConditionWait ()
 #6   0x7065557c in _CarbonOperationThreadFunc ()
 #7   0x70014f04 in __pthread_body ()

Thread 3:
 #0   0x70059b48 in _semaphore_timedwait_signal_trap ()
 #1   0x7003f7f8 in _semaphore_timedwait_signal ()
 #2   0x70015f68 in __pthread_cond_wait ()
 #3   0x7003f7c4 in _pthread_cond_timedwait_relative_np ()
 #4   0x7029b590 in _TSWaitOnConditionTimedRelative ()
 #5   0x7029cdac in _TSWaitOnSemaphoreCommon ()
 #6   0x702e5f98 in _TSWaitOnSemaphoreRelative ()
 #7   0x702e7208 in _TimerThread ()
 #8   0x70014f04 in __pthread_body ()

Thread 4:
 #0   0x70059b68 in _semaphore_wait_signal_trap ()
 #1   0x70016110 in _semaphore_wait_signal ()
 #2   0x70015f78 in __pthread_cond_wait ()
 #3   0x70015d18 in _pthread_cond_wait ()
 #4   0x7029b550 in _TSWaitOnCondition ()
 #5   0x7029cd94 in _TSWaitOnSemaphoreCommon ()
 #6   0x7029cce4 in _TSWaitOnSemaphore ()
 #7   0x7029cba8 in _AsyncFileThread ()
 #8   0x70014f04 in __pthread_body ()

Thread 5:
 #0   0x70059b68 in _semaphore_wait_signal_trap ()
 #1   0x70016110 in _semaphore_wait_signal ()
 #2   0x70015f78 in __pthread_cond_wait ()
 #3   0x70015d18 in _pthread_cond_wait ()
 #4   0x70653be0 in _BSD_pthread_cond_wait ()
 #5   0x70653bc0 in _CarbonConditionWait ()
 #6   0x70653ab4 in _CarbonInetOperThreadFunc ()
 #7   0x70014f04 in __pthread_body ()

Thread 6:
 #0   0x700007b8 in _mach_msg_overwrite_trap ()
 #1   0x700056e4 in _mach_msg_overwrite ()
 #2   0x700277b0 in _thread_suspend ()
 #3   0x70027744 in __pthread_become_available ()
 #4   0x70027468 in _pthread_exit ()
 #5   0x70014f08 in __pthread_body ()

PPC Thread State:
  srr0: 0x00000000 srr1: 0x4000d030                vrsave: 0x00000000
   xer: 0x20000010   lr: 0x000b34b0  ctr: 0x00000000   mq: 0x00000000
    r0: 0x00000000   r1: 0xbffff6f0   r2: 0x00000000   r3: 0x043d9530
    r4: 0xffffffff   r5: 0x050d8cf4   r6: 0x002ce34c   r7: 0x002cf02c
    r8: 0x00000002   r9: 0x802609d0  r10: 0x0000518c  r11: 0x80003f8c
   r12: 0x0495e194  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
   r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  r19: 0x00000000
   r20: 0x00000000  r21: 0x00000000  r22: 0x00000000  r23: 0x0043d2a7
   r24: 0xbffffc78  r25: 0x0000ec10  r26: 0x00000000  r27: 0x0000ea80
   r28: 0x00000003  r29: 0x00000000  r30: 0x002ce36c  r31: 0x0001fe88

**********
side note: wasn't able to crash using the recipe in bug 90893. but when i
attempted to quit, the browser window went away and the Netscape menu persisted;
resorted to a force quit, since selecting quit from the Netscape menu didn't work.
Keywords: crash
The 2-3 hours of idle time might be significant. Did the machine go to sleep in 
this time?

..me too. I've got a crash report with the same stack(n thread 0) as sairuh -
from a 8-24 build. My machine goes to sleep rather agressively so I'll look into
a link with that as well. Guess i'll take QA for this one.
QA Contact: doronr → claudius
yes, the machine did go to sleep during that time.
i saw a crash on quit with my personal opt build from this week, no sleeping 
involved. cmd-q to quit. the stack is different, though. my crash is in prefs 
IIRC.

Hey Guys. Talked briefly with Steve. I think I am seeing
the same problem but on MAC 9.1 I have G4, dual boot,
with 9.1 and 10.0.4

I've been using various commercial trunk/branch builds.
And like sairuh said, i wasn't sure what I did to make
it crash. I think it has been when my machine has
been sleeping, I wake it up, and then quit mozilla and
crash happens. Or I've had the browser/messenger up for a
whille so I'm idle (not necessarily sleeping) and then go
do something (quit, click a link) and boom it will crash.

My stack trace is as follows:
 Call Stack:    (Signature = 0xffc10000 5df6c087) 
     0xffc10000 
     nsImapProtocol::Run() [nsImapProtocol.cpp, line 752]
     nsThread::Main() [nsThread.cpp, line 105]
     _PR_UserRunThread() [pruthr.c, line 503]
     _PR_UserDestroyThread() [pruthr.c, line 374]

One more stack trace:
 Trigger Reason:  PowerPC unmapped memory exception 

 Call Stack:    (Signature = .__ptr_glue 502c2db5) 
     
   .__ptr_glue 
                           
   nsImapProtocol::Run() [nsImapProtocol.cpp, line 752]
   nsThread::Main() [nsThread.cpp, line 105]
   _PR_UserRunThread()  [pruthr.c, line 503] 
   _PR_UserDestroyThread()  [pruthr.c, line 374]

My crashes are consistent with same files (nsImapPrtocol and pruthr)
but stack lines vary sometimes.

Talkback ids are as follows:
 Most recent: TB35567334M,TB35571913Z, 
 Older ones: 35573938,35408597,35405531,35353354    
Mozilla 0.9.4 is showing this as somewhat of a topcrasher for MacOS so adding
topcrash keyword and M094 [@ .__ptr_glue 502c2db5 - nsImapProtocol::Run][@
0xffc10000 5df6c087 - nsImapProtocol::Run]  to summary for tracking.  

There have been at least 7 crashes for M094 with the stack signature
".__ptr_glue 502c2db5" as gchan mentioned:

This is the most recent incident:

Incident ID 35807148
Stack Signature .__ptr_glue 502c2db5
Bug ID
Trigger Time 2001-09-24 08:12:45
User Comments
Build ID 2001091311
Product ID Netscape6.20
Platform ID MacOS
Trigger Reason PowerPC unmapped memory exception
Stack Trace
.__ptr_glue
nsImapProtocol::Run() [nsImapProtocol.cpp, line 752]
nsThread::Main() [nsThread.cpp, line 105]
_PR_UserRunThread() [pruthr.c, line 503]
_PR_UserDestroyThread() [pruthr.c, line 374] 


And here are the others:

.__ptr_glue 502c2db5
	 line 
	Build: 2001091311 CrashDate: 2001-09-23 UptimeMinutes: 454  Total: 1303 
	OS: MacOS version 9.1
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=35783286
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=35783286
(35783286)
Comments: quitting

.__ptr_glue 502c2db5
	 line 
	Build: 2001091311 CrashDate: 2001-09-22 UptimeMinutes: 532  Total: 592 
	OS: MacOS version 8.6
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=35756412
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=35756412

.__ptr_glue 502c2db5
	 line 
	Build: 2001091311 CrashDate: 2001-09-22 UptimeMinutes: 808  Total: 808 
	OS: MacOS version 9.1
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=35742506
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=35742506

.__ptr_glue 502c2db5
	 line 
	Build: 2001091311 CrashDate: 2001-09-21 UptimeMinutes: 16  Total: 1768 
	OS: MacOS version 9.1
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=35695738
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=35695738

.__ptr_glue 502c2db5
	 line 
	Build: 2001091311 CrashDate: 2001-09-17 UptimeMinutes: 204  Total: 433 
	OS: MacOS version 9.2.1
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=35513875
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=35513875
(35513875)
Comments: Quitting
.__ptr_glue 502c2db5
	 line 
	Build: 2001091311 CrashDate: 2001-09-15 UptimeMinutes: 14  Total: 14 
	OS: MacOS version 9.2.1
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=35420381
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=35420381
(35420381)
Comments: i was quitting
And I found 3 crashes for M094 with the stack signature "0xffc10000 5df6c087":

The most recent incident:
Incident ID 35720169
Stack Signature 0xffc10000 5df6c087
Bug ID
Trigger Time 2001-09-21 20:31:47
User Comments Quitting Mozilla
Build ID 2001091311
Product ID Netscape6.20
Platform ID MacOS
Trigger Reason Illegal PowerPC instruction
Stack Trace
0xffc10000
nsImapProtocol::Run() [nsImapProtocol.cpp, line 752]
nsThread::Main() [nsThread.cpp, line 105]
_PR_UserRunThread() [pruthr.c, line 503]
_PR_UserDestroyThread() [pruthr.c, line 374] 

And a couple of others:

0xffc10000 5df6c087
	 line 
	Build: 2001091311 CrashDate: 2001-09-18 UptimeMinutes: 566  Total: 1007 
	OS: MacOS version 9.1
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=35541942
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=35541942
(35541942)
Comments: Quitting Mozilla
0xffc10000 5df6c087
	 line 
	Build: 2001091311 CrashDate: 2001-09-17 UptimeMinutes: 258  Total: 258 
	OS: MacOS version 9.1
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=35527235
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=35527235
(35527235)
Comments: I was quitting.  I had a browser (open to www.mozilla.org/)  and a
mail window (with an SSL IMAP connection in it) open.  I may have closed the
mail window before quitting  I don't recall.  Regardless  I hit Cmd-Q  and the
app crashed.
I haven't checked the MozillaTrunk, but from the other comments in this bug,
it's also crashing on the Trunk.
Keywords: topcrash
Summary: OS X: crash upon quit [in __destroy_global_chain ()] → OS X: crash upon quit [in __destroy_global_chain ()] - Trunk & M094 [@ .__ptr_glue 502c2db5 - nsImapProtocol::Run] [@ 0xffc10000 5df6c087 - nsImapProtocol::Run]
Sorry for corrupting this bug with so much data, but if this crash is indeed the
same as the ones I just posted, this should be marked a dup of bug 90093.  

Claudius or Steve: What do you guys think?  Should this be marked a dup or am I
just an idiot?
this is not osx only. I saw a stack like this with the 9/21 branch bits on _OS9_.

this is also the same stack of a bug i reported a long long time ago that
magically went away, so we stopped trying to fix it:

.__ptr_glue
nsImapProtocol::Run() [nsImapProtocol.cpp, line 752]
nsThread::Main() [nsThread.cpp, line 105]
_PR_UserRunThread() [pruthr.c, line 503]
_PR_UserDestroyThread() [pruthr.c, line 374] 

Are we trying to do too much with this bug? cc'ing mail guys
I believe this is a dup of bug 90093 - I've checked in some changes on the trunk
that might have indirectly fixed 90093 - anyone who can reproduce this problem
should try today's trunk build and see if they can still reproduce the problem.
nbaca or olga, have you encountered this recently?
No crashes. I tried to reproduce it now - no problem when quit.
Olga, what build are you using?
Today's Mac OSX branch build: 2001-09-26.
ah, well, none of my recent changes have gone into the branch, so if it's fixed
on the branch, we can disregard the patches in the bugs.
yes, but just like the previous bug i filed, this one obviously comes and goes.
one person not seeing it on one day means nothing.
Claudius, this does look like a dup of 90093, since it is NOT an OSX only bug. 
And I agree with Pink...crashes like this are difficult to reproduce, so just
because one person doesn't crash with today's branch build, doesn't mean we can
safely say it's fixed.  Talkback data has been showing this crash for a long
time now...most incidents start showing up after major releases/milestones as
expected.  So, if we don't get the fix for bug 90093 into the branch, we'll have
to wait until eMojo Talkback data starts coming in to see if this is still
happening.
Marking this a dup of bug 90093.

*** This bug has been marked as a duplicate of 90093 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
Crash Signature: [@ .__ptr_glue 502c2db5 - nsImapProtocol::Run] [@ 0xffc10000 5df6c087 - nsImapProtocol::Run]
You need to log in before you can comment on or make changes to this bug.