Crash with alert and setTimeout(goQuitApplication, 1000)

RESOLVED FIXED

Status

()

--
critical
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: jruderman, Assigned: mats)

Tracking

({crash, fixed1.8.1.8, testcase})

unspecified
PowerPC
Mac OS X
crash, fixed1.8.1.8, testcase
Points:
---
Bug Flags:
wanted1.8.1.x +
wanted1.8.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate] unreliable critical)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
This testcase sometimes (~30% of the time) triggers a sg:critical crash.

This might be related to bug 52209 and/or bug 355069.

Don't pay too much attention to the string concatenation in the testcase, that might just be a distraction.
(Reporter)

Comment 1

12 years ago
Created attachment 240889 [details]
testcase (requires chrome privs)

This testcase requires chrome privileges in order to call goQuitApplication.  If you view it locally there's probably some way to grant it the privileges it needs.
(Reporter)

Comment 2

12 years ago
Created attachment 240891 [details]
stack trace from a mac nightly

This stack shows Firefox dereferencing a random address.  Sometimes it jumps to a random address instead.
(Reporter)

Comment 3

12 years ago
This reminds me of bug 339683.
(Reporter)

Comment 4

12 years ago
Cmd+Q (in the same window or in another window) does not cause similar problems, so maybe goQuitApplication is special and this bug is invalid.
Whiteboard: [sg:critical?] unreliable
The real issue here, imho, is that that timeout runs while the alert is up.  That said, if we really care we could try to figure out how shutdown is messing up here...

Does doing the quit in window A while an alert is up for window B crash?  I'd bet not.
> we could try to figure out

Which I guess is a roundabout way of saying "not I"....
(Reporter)

Comment 7

12 years ago
(In reply to comment #5)
> Does doing the quit in window A while an alert is up for window B crash?  I'd
> bet not.

Yes.  It didn't crash on the first two tries, but on the third try I got:

Thread 0 Crashed:
0    0 + -2080374784
1    DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
OK, I see.  So I guess hiding any sheet after its window is dead is generally crashy...  Might want to get Mac widget folks to look into it.
(Reporter)

Comment 9

12 years ago
I think this is the same as bug 355273.
Yeah, for sure.
Depends on: 355273
Assignee: general → joshmoz
Flags: blocking1.8.1.1+
Flags: blocking1.8.0.9+

Updated

12 years ago
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.1+
Flags: blocking1.8.0.9+
Flags: blocking1.8.1.2?
Flags: blocking1.8.0.10?
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10?
Flags: blocking1.8.0.10+
Whiteboard: [sg:critical?] unreliable → [sg:moderate] unreliable critical

Updated

12 years ago
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10+
(Reporter)

Comment 11

12 years ago
The testcase no longer causes a crash for me on trunk.  It seems like the quit doesn't go through until the JavaScript finishes.
JS timers no longer fire while modal dialogs are open (see bug 52209). This may still be triggerable using more than one top-level window though, as I believe timeouts can still fire in a window while an alert is open in another window.
(Reporter)

Comment 13

12 years ago
I tried that and it didn't crash.  Maybe I didn't try it enough times, though (comment 0 says it's only 30% reproducible).
(Assignee)

Comment 14

11 years ago
If I open two windows and load the testcase locally then I can reproduce
the crash in a recent 1.8 branch debug build (== 2.0.0.5 RC2 or so).
The patch in bug 355273 fixes it for me.
(Assignee)

Updated

11 years ago
Assignee: joshmoz → mats.palmgren
(Assignee)

Comment 15

11 years ago
-> FIXED (by bug 355273)
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Fix for bug 355273 landed in 1.8.1.8
Group: security
Keywords: fixed1.8.1.8
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.