Crash @ nsXULDocument::ResumeWalk(), possibly a regression from fix for bug 419452

VERIFIED FIXED in mozilla1.9beta4

Status

()

Core
DOM
P1
critical
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: MarcoZ, Assigned: neil@parkwaycc.co.uk)

Tracking

({crash, regression})

Trunk
mozilla1.9beta4
x86
Windows Vista
crash, regression
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
Happened to me twice while loading bugs from within Thunderbird. Crash reports:
http://crash-stats.mozilla.com/report/index/8cf47f7a-e5eb-11dc-89c2-001a4bd43ef6
and
http://crash-stats.mozilla.com/report/index/6e03efd9-e5eb-11dc-a664-001a4bd43ed6
Flags: blocking1.9?
(Assignee)

Comment 1

10 years ago
The line flagged in the stack trace,
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/xul/document/src/nsXULDocument.cpp&rev=1.815&mark=2995#2995
nsCOMPtr<nsIURI> overlayURI = mCurrentPrototype->GetURI();
is just a copy of line 3112, furthermore mCurrentPrototype has a strong URI.

So you're not going to get far without STR in a debug build...
(Reporter)

Comment 2

10 years ago
I can reproduce this 100% of the time using the currently latest nightly (2008022714). I have Firefox closed completely, no instance running.
1. In Thunderbird, open any bugmail.
2. Via the keyboard, I open the link at the top of bugmail.
3. Firefox opens, then crashes.
4. After clicking "Restart Firefox" in BreakPad, Firefox starts and opens the URL I clicked from within Thunderbird.

If I already have an instance running, there is no problem.
(Reporter)

Comment 3

10 years ago
This does not reproduce with a debug build. The startup time for a debug build may be too long for the bug to surface, or some other factor may influence it.
Seeing 62 crashes (were those all you, Marco?) so blocking b4 on this for now.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
(Reporter)

Comment 5

10 years ago
(In reply to comment #4)
> Seeing 62 crashes (were those all you, Marco?) so blocking b4 on this for now.

No, I account for five or six of them.

Comment 6

10 years ago
http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg

we're going to need a debugger to chase some things, first, is mCurrentPrototype really null? windbg can easily answer that question. Other questions can also be answered w/ creative use of bp ....
Why don't we just back out bug 419452 and deal with this after beta 4?
Neil/jst/jonas: see comment 7, and please help us resolve this by tonight?
Fix for bug 419452 backed out.
Marco: can you reproduce your crashes, or should we mark this fixed and say that the backout of 419452 did, indeed, fix this.
(Reporter)

Comment 11

10 years ago
(In reply to comment #10)
> Marco: can you reproduce your crashes, or should we mark this fixed and say
> that the backout of 419452 did, indeed, fix this.

I can no longer reproduce this crash with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008030206 Minefield/3.0b4pre. If you mark fixed, I'll mark verified.
crash-stats also showing no crashes here for the 03/01 or 03/02 builds...
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

10 years ago
Verified using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008030206 Minefield/3.0b4pre.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.