Nigel Hadfield Reporter
	Description • 19 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

Click "Next" on the page above. Then close the browser or tab. I get a Zone
Alarm "dangerous behaviour" warning for \Windows\System32\DWWIN.EXE, and click
"Allow". Firefox crashes.

Reproducible: Always

Steps to Reproduce:
1.Above.
2.
3.

Actual Results:  
Windws crash dialog - sent details to MS!

Expected Results:  
Closd tab cleanly without crashing.

	u63580
	Comment 1 • 19 years ago

The "dangerous behaviour" business is because FF is crashing, and DrWatson (the
Windows fault report program) is starting up.

That said, I also get a crash at the site with Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.9a1) Gecko/20050903 Firefox/1.6a1.  My steps:

1. From here, go to the example URL
2. Go forward with the "Next" button
3. Try to use back to get back here - I get back to the example, then FF dies.

Will post TalkBack IDs shortly

	timeless
	Comment 2 • 19 years ago

Incident ID: 9079484
Stack Signature	0x011f4ec0 b9f8c15d
Product ID	FirefoxTrunk
Build ID	2005090306
Trigger Time	2005-09-06 02:08:30.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	
User Comments	
Since Last Crash	5851 sec
Total Uptime	5851 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x011f4ec0
XPCWrappedNativeProto::JSProtoObjectFinalized 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativeproto.cpp,
line 137]
js_GC  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c,
line 1839]
js_ForceGC 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1510]

	u63580
	Comment 3 • 19 years ago

TB numbers (sorry for delay):

TB9085214W
TB9085213Y

	Martijn Wargers (dead)
	Comment 4 • 19 years ago

This testcase crashes for me after the 3rd reload.
Talkback ID's: TB9093080G TB9093136G

	Martijn Wargers (dead)
	Comment 5 • 19 years ago

Also crashes Mozilla1.7, so not a (recent) regression

	Scott MacGregor
	Comment 6 • 19 years ago

this crash was present in 1.7 so we've shipped before with it. It's too late for
the b4 train, no patch in hand either. 

	HJ
	Comment 7 • 19 years ago

Crash occurred when closing FF1.5b1 (OS X, 10.3.9). Talkback extension isn't
working on my FF install, so I am attaching the OS X crashlog above. I'm not a
coder, but if I read it correctly it looks like the same tag
(XPCWrappedNativeProto::JSProtoObjectFinalized) as listed in the original
report of this bug.

	Jo Hermans
	Comment 8 • 19 years ago

related to bug 307289 (which happens a few lines later, at line 141) ?

	u63580
	Comment 9 • 19 years ago

*** Bug 308015 has been marked as a duplicate of this bug. ***

	Jerry Baker
	Comment 10 • 19 years ago

The crashes began with 20050902 builds and there have been 119 crash reports
with XPCWrappedNativeProto::JSProtoObjectFinalized since yesterday. --> TOPCRASH

	Asa Dotzler [:asa]
	Comment 11 • 19 years ago

This is the number 2 crash in the 1.5 beta1 release. We need to get on top of
this one.

	Peter van der Woude [:Peter6]
	Comment 12 • 19 years ago

first incident on trunk  2005090205
first incident on branch 2005090406

comment checkin: 

Bug 271567 - Add back onload XPInstall [All]
bug 304423 - (window instanceof Object) returns false [All]

Bonsai comments: 

checkin bug 304423 part 1
Make window instanceof Object and Window etc be true again. This regressed with
the split window landing. The fix here is to make the inner and outer windows
share the outer's XPConnect prototype (but only that, everything below that on
the proto chain comes from the inner window). To make this work with fastback we
also needed a way to tell XPConnect to restore an old prototype for the window
object when going back/forward.

checkin bug 304423 part 2
XPCWrappedNative::GetWrappedNativeOfJSObject() deal with the case where the
prototype found through the funobj is not the current prototype for the given
class (i.e. it's a prototype for the right class and scope, but one from before
prototypes were refreshed).

304023 (jst) looks to be the guilty bug

	Peter van der Woude [:Peter6]
	Comment 13 • 19 years ago

comment checkin = common checkins

	Johnny Stenback (:jst) Assignee
	Comment 14 • 19 years ago

Taking bug.

	Johnny Stenback (:jst) Assignee
	Comment 15 • 19 years ago

I'm guessing that this will be fixed by the fix for bug 307289, which was
checked in on the trunk on 9/7/2005, but only just now got checked in on the
branch. This is really odd tho, this bug talks about a crash in
XPCWrappedNativeProto::JSProtoObjectFinalized(), and so does bug 307289, but the
talkback reports in this bug have completely different stacks, seeminly
unrelated to JS code, even... Still investigating...

	Martijn Wargers (dead)
	Comment 16 • 19 years ago

I still crash with a 2005-09-13 windows trunk build on the testcase, so I don't
think it is fixed by bug 307289.

	Johnny Stenback (:jst) Assignee
	Comment 17 • 19 years ago

(In reply to comment #16)
> I still crash with a 2005-09-13 windows trunk build on the testcase, so I don't
> think it is fixed by bug 307289.

Yeah, seems like there's more than one issue at play here. Do you by any chance
have stalkback IDs or stack traces for your crashes?

	Johnny Stenback (:jst) Assignee
	Comment 18 • 19 years ago

This crash doesn't have anything to do with
XPCWrappedNativeProto::JSProtoObjectFinalized() (at least not any more since bug
307289 was fixed). This is a crash caused by ConvertBreaks() in
nsLineBreakConverter() writing past the buffer it allocates. More once I have
more time to investigate...

	timeless
	Comment 19 • 19 years ago

*** This bug has been marked as a duplicate of 234624 ***