Crash: [@ call_enumerate ] in js/src/jsfun.cpp:754 when Javascript Debugger window opened.

RESOLVED FIXED in mozilla1.9.2a1



10 years ago
8 years ago


(Reporter: morac, Assigned: mrbkap)


({crash, fixed1.9.1})

Windows XP
crash, fixed1.9.1
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: fixed-in-tracemonkey, crash signature)


(1 attachment)



10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090408 Firefox/3.5b4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090408 Firefox/3.5b4pre

Starting with the 20090407 trunk load, when the Javascript Debugger ( window is opened, Minefield crashes.

Reproducible: Always

Steps to Reproduce:
1. Install Javascript Debugger add-on
2. Open Debugger window 

Actual Results:  
Minefield crashes.

Expected Results:  
Minefield should not crash.

Comment 1

10 years ago
bug 452598 touched this function a few days ago.

could you possibly bisect the crash? (i.e. try a build from 2 weeks ago, then a build from either 1 or 4 weeks ago ...)
Assignee: rginda → general
Component: JavaScript Debugger → JavaScript Engine
Keywords: crash, regressionwindow-wanted
Product: Other Applications → Core
QA Contact: venkman → general
Version: unspecified → Trunk

Comment 2

10 years ago
Like I mentioned in comment #0, the problem started with the 20090407 trunk load.  It was fine before then.

I have a 2nd computer that does not crash when the Javascript Debugger window opens, but on that computer the Java plugin activates when the Javascript Debugger window opens (java.exe runs).  On the computer that crashes, Java never ran when the Javascript Debugger window opened.  I don't know if that's relative or not.

Comment 3

10 years ago
Created attachment 372535 [details] [diff] [review]
Proposed fix

The comment says it all -- I don't know how to make an automated test for this that doesn't involve the dbg api.
Assignee: general → mrbkap
Ever confirmed: true
Attachment #372535 - Flags: review?(brendan)

Comment 4

10 years ago
I don't know if this is relevant or not, but on the computer that crashes, I'm not running as an administrator and the computer itself runs a hyperthreading processor.  It also has an older version of java on it which may or may not be relevant since that computer does not load java when the debugger is started.
The computer that does not crash does not have a hyperthreading processor (one core) and I run as an administrator.  This computer has an up to date java, which loads when the debugger window is opened (even in Firefox 3.0.8 for some reason).

Also sometimes the browser doesn't crash when the Javascript debugger window opens, until I click back on the opening window.

Comment 5

10 years ago
from the code fix, it isn't related to threading. fwiw, we don't need feedback from you until a nightly includes it.
Attachment #372535 - Flags: review?(brendan) → review+
Comment on attachment 372535 [details] [diff] [review]
Proposed fix


Blocks: 452498
Flags: blocking1.9.1?

Comment 7

10 years ago
I know you said you don't need feedback from me, but since the 1.9.1? blocking flag was set, I'll mention that I'm not seeing this crash in the 1.9.1 nightly loads.

Comment 8

10 years ago
Whiteboard: fixed-in-tracemonkey

Comment 9

10 years ago
Last Resolved: 10 years ago
Flags: blocking1.9.1? → blocking1.9.1+
Resolution: --- → FIXED

Comment 10

10 years ago
The nightly trunk load is no longer crashing so it looks like the fix worked.
Just adding this in for a future verifier: 

verification is dependent on javascript debugger being compatible with minfield shiretoko nightlies (or 3.5b4 release).
Not worth checking for a regression range for an already fixed bug.
Keywords: regressionwindow-wanted
Target Milestone: --- → mozilla1.9.1b4
Target Milestone: mozilla1.9.1b4 → mozilla1.9.2a1
Crash Signature: [@ call_enumerate ]
You need to log in before you can comment on or make changes to this bug.