Closed Bug 355097 Opened 18 years ago Closed 17 years ago

Crash with alert and setTimeout(goQuitApplication, 1000)

Categories

(Core :: DOM: Core & HTML, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: crash, fixed1.8.1.8, testcase, Whiteboard: [sg:moderate] unreliable critical)

Attachments

(2 files)

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.
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.
This stack shows Firefox dereferencing a random address.  Sometimes it jumps to a random address instead.
This reminds me of bug 339683.
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"....
(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.
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+
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
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10+
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.
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).
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: joshmoz → mats.palmgren
-> FIXED (by bug 355273)
Status: NEW → RESOLVED
Closed: 17 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.

Attachment

General

Creator:
Created:
Updated:
Size: