97675 - OSX: Crash on quit [0x700007b8 in _mach_msg_overwrite_trap]

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Adam Masri]

Platform: PowerBook G3/300/192Mb/25Gb, MacOS X 10.0.4
Fizzilla build: 2001082905

I've been getting more than my fair share of crashes on quit with this new
build. Compared to my old favorite build (7/30), I've also noticed that this new
build hangs pretty often when trying to read various pages- The M logo will be
moving, but none of the page loads as if the server is down. Quit and restart
Moz, and all is well again. So, here's a stack trace from my latest crash.

Date/Time: 2001-08-30 14:49:58 -0700

PID:       342
Command:   Mozilla

Exception: EXC_BAD_ACCESS (0x0001)
Codes:     KERN_INVALID_ADDRESS (0x0001) at 0xffff8114

Thread 0:
 #0   0x700007b8 in _mach_msg_overwrite_trap ()
 #1   0x70006c44 in _mach_msg ()
 #2   0x7017ab20 in ___CFRunLoopRun ()
 #3   0x7017a56c in _CFRunLoopRunInMode ()
 #4   0x737dc470 in _RunEventLoopInModeUntilEventArrives ()
 #5   0x7383afd4 in _RunEventLoopUntilEventArrives ()
 #6   0x7383aecc in _GetNextEventMatchingMask ()
 #7   0x7383aacc in _WNEInternal ()
 #8   0x7383a988 in _WaitNextEvent ()
 #9   0x000da664 in 0xda664 ()
 #10  0x000d4350 in 0xd4350 ()
 #11  0x000d5d90 in 0xd5d90 ()
 #12  0x000d5cd8 in 0xd5cd8 ()

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   0x002022e4 in 0x2022e4 ()
 #1   0x7029cc08 in _AsyncFileThread ()
 #2   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   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   0x702b26b4 in _DeferredTaskThread ()
 #8   0x70014f04 in __pthread_body ()

Thread 7:
 #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   0x7029b59c in _TSWaitOnConditionTimedRelative ()
 #6   0x7029b6a4 in _MPWaitOnQueue ()
 #7   0x708de050 in _SyncTaskProc__13TNodeSyncTaskPv ()
 #8   0x70291434 in _PrivateMPEntryPoint ()
 #9   0x70014f04 in __pthread_body ()

Thread 8:
 #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: 0x002022e4 srr1: 0x0000d030                vrsave: 0x00000000
   xer: 0x00000000   lr: 0x001d26f8  ctr: 0x70059b30   mq: 0x00000000
    r0: 0x24000096   r1: 0x0123ae60   r2: 0x00000000   r3: 0x6c0001c3
    r4: 0x00000000   r5: 0x00000000   r6: 0x0005e800   r7: 0x00000000
    r8: 0x0005e800   r9: 0x80260608  r10: 0x0005e600  r11: 0x8000415c
   r12: 0x001d269c  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
   r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  r19: 0x00000000
   r20: 0x00000000  r21: 0x00000000  r22: 0x00000000  r23: 0x00000000
   r24: 0x00000000  r25: 0x00000000  r26: 0x00000000  r27: 0x80260640
   r28: 0x00000000  r29: 0x80260640  r30: 0xbffff00c  r31: 0x7029cb94

**********

Comment 1

[Chase Tingley]

see also bug 97620

Comment 2

[Chase Tingley]

walk84 was seeing this on windows as well.

Comment 3

[Matthias Versen [:Matti]]

Reporter: Is this a problem with a more recent build and/or new profile ?

Comment 4

[Matthias Versen [:Matti]]

marking worksforme (no response)

Comment 5

[Adam Masri]

How can a crash with a stack trace be marked WFM? Either this bug was explicitly
fixed, or it is not. How would I know if it was fixed? How would you? Someone
who is knowledgeable must look over this stack trace and see if this bug is fixed.

- Adam

Comment 6

[Matthias Versen [:Matti]]

A bug with a stack trace is marked worksforme if you can't reproduce that bug
with a more recent build. I (or a developer) can/will mark this bug fixed if
here is a patch attached that is checked in into the tree.
Or i dupe this bug to another bug with a patch if i know that this bug is a dupe.
None will look at this bug if you can't reproduce this bug because this bug is
possible fixed by another bug fix. This project is too big that the developers
can look into every bug and there are too incoming new bugs.
BTW: Browser general will never fix any bugs including Asa (the assigned person) 


Can you reproduce this crash with a more recent build and/or a new profile ?
if not -> worksforme (or if you don't answer in 7 days - that are the rules)!

/MV
BTW: What do you expect if you don't answer any questions ?

Comment 7

[Adam Masri]

I still occasionally get crashes on quit. Sometimes OS X decides not to yield a
stack trace, even tho I told it to. Does that mean this specific bug is fixed?
Who knows?

I was under the impression that the coders could look over a stack trace to get
a general idea of where the problem is in the source. If that's not the case,
then Mozilla will remain a buggy, crashy app. Is that really what you want? It
certainly isn't what I want.

I know you want to help make Moz a great app by helping out in Bugzilla. But I
think in this case your effort is misguided. Marking crashers WFM because they
can't be reproduced doesn't fix anything, it simply makes everyone feel like
progress is being made. Unfortunately, we're only progressing towards an app
that randomly crashes and leaves users feeling like Moz (and Netscape, and
anything based on Moz) is buggy and not to be trusted with critical data.

If this policy you describe is actually from Mozilla.org, then it should be
changed. Please post a link in this bug to a specific web page on Mozilla.org
that states that this is true. If this policy is one you came up with, then who
knows how many legitimate bugs you've marked WFM and now will never be fixed.
Eventually, a policy like this sends the message that Mozilla.org doesn't want
to hear about bugs that are "hard." Then people stop reporting bugs (since
they're just going to get marked WFM anyway), and we're all left with a lower
quality app.

- Adam

Comment 8

[R.K.Aa.]

Thanks for your feedback and persistance.

I think the other "on exit" topcrasher in the same build you originally reported
this bug against, may have confused the matter, causing it to be modified to OS:
All. 

That bug is now fixed (bug 97620). Talkbacks seem to bave submitted only with
Windows builds however.

Adding original stack from here to summary.
Changing Platform/OS back to Macintosh/MacOS X

Note that there are several other open "crash on quit" bugs affecting MacOSX:
bug 85048, bug 90093, bug 90893, bug 97297.

Can you reproduce the original stack from this bug with a fresh build?

Comment 9

[R.K.Aa.]

CC pinkerton, in case he knows this stack

Comment 10

[Asa Dotzler [:asa]]

I'm not seeing any crashes on exit with the latest (12/26 and 12/27) builds. 

Comment 11

[Adam Masri]

I simply have no clue if this is fixed or not. In the build I'm using now
(Fizzilla 2002012403) I'm not getting crash on quits. And I have quit and
relaunched this build many times.

Ideally, Talkback would be integrated into nightlies. Then we wouldn't have to
manually report crashers, and we'd all know what crashers were current.

- Adam

Comment 12

[Asa Dotzler [:asa]]

worksforme with current branch and trunk OS X builds