Closed Bug 497119 Opened 12 years ago Closed 12 years ago

crash on [@ JS_EvaluateUCInStackFrame]


(Core :: JavaScript Engine, defect)

Not set





(Reporter: johnjbarton, Assigned: mrbkap)



(4 keywords, Whiteboard: fixed-in-tracemonkey [firebug-p1])

Crash Data


(3 files, 1 obsolete file)

Using FF 3.5 nightly build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090609 Shiretoko/3.5pre

Install Firebug 1.5Xa03,

Open the test case from

When the debugger keyword breaks into Firebug, move your mouse over Firebug's script panel.

I did not apply the exact procedure above, I'm using Firebug directly from SVN, but I'm fairly certain you can get the same result.
Flags: blocking1.9.1?
Whiteboard: [firebug-p1]
Sorry forgot the crash stats:
and the stack points to frame.eval()
Does it happen with Firebug 1.4b1?
probably. 1.5a3 is the same as 1.4b2
does this crash on mozilla central? This could be related to bug 483847. Same crash signature as bug 496981.
crashes on mozilla-central (minefield nightly, 060809) as well
Just to point out the obvious here, the problem did not occur for sure on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090527
since I used that to test bug 495663.

I did not see this problem until last night and I've been using 3.5 nightly builds.
I recheck 0527, it does not crash.

Does not crash:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090605 Shiretoko/3.5pre

Does crash:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090608 Shiretoko/3.5pre

I will recommend Firebug users pick 0605
Regressed between the builds 09060503 and 09060603.



Andreas or Brendan, do you have an idea what could have been caused this?

I will check Minefield now so I can correlate.
Ok, on trunk it regressed between the builds 09060403 and 09060503:



Ok, we overlap with all those check-ins. That makes it harder to find the causing bug.
Mmh why we are 0x0 here when it's given that it cannot be 0x0?

gdb) frame 0
#0  0x002acb41 in JS_EvaluateUCInStackFrame (cx=0x16efa00, fp=0xbfffcb98, chars=0x1b187ef0, length=4, filename=0x898310 "", lineno=1, rval=0xbfff6ec0) at /data/build/shiretoko/js/src/jsdbgapi.cpp:1273
1273	            if (fp2->displaySave) {
Current language:  auto; currently c++
(gdb) p fp2
$2 = (JSStackFrame *) 0x0
(gdb) p cx->fp
$3 = (JSStackFrame *) 0x0
good catch, whimboo. thanks!
Keywords: testcase
Summary: crash on jsdIStackFrame.eval() → crash on [@ JS_EvaluateUCInStackFrame]
Also happens with JavaScript Debugger extension:

1. Install JavaScript Debugger:
2. Restart
3. Disable Java
4. Launch Tools --> JavaScript Debugger
5. Wait a couple seconds then press F4
6. If the browser does not immediately crash, wait about 10 sec then press F4 again.
Flags: blocking1.9.1? → blocking1.9.1+
Blake is on this already.

Assignee: nobody → mrbkap
Target Milestone: --- → mozilla1.9.1
Duplicate of this bug: 497212
Flags: blocking1.9.1+ → blocking1.9.1?
Keywords: crash
Target Milestone: mozilla1.9.1 → ---
Flags: blocking1.9.1? → blocking1.9.1+
Severity: normal → critical
OS: Windows XP → All
Hardware: x86 → All
Version: 1.9.1 Branch → Trunk
Blocks: 497028
Attached patch patch v1 (obsolete) — Splinter Review
Attachment #382606 - Flags: review?(brendan)
Comment on attachment 382606 [details] [diff] [review]
patch v1

Comment on in-place chain reversal? r=me anyway.

Attachment #382606 - Flags: review?(brendan) → review+
Attached patch patch v1.5Splinter Review
Attachment #382606 - Attachment is obsolete: true
Attachment #382655 - Flags: review?(brendan)
Comment on attachment 382655 [details] [diff] [review]
patch v1.5

>+         * NB: We have to fill cx->display backwards (callee is overwritten by
>+         * caller) so we do an in-place linked list reversal to avoid the
>+         * obvious recursive algorithm.

Isn't this trying to say what would happen (cx->display would be filled in backwards) if we didn't reverse?

How about "To reconstruct cx->display for fp, we have to follow the frame chain from oldest to youngest, in the opposite direction to its single linkge. To avoid the obvious recursive reversal algorithm, which might use too much stack, we reverse in place and reverse again as we reconstruct the display."

>+...        This is safe because cx is * thread-

Stray * crept in there, looks like.

r=me with these nits addressed.

Attachment #382655 - Flags: review?(brendan) → review+
yep. patch v1.5 fixes the problem for me in 3.5.
Depends on: 497177
No longer depends on: 497177 mozilla-central is red right now.
Whiteboard: [firebug-p1] → fixed-in-tracemonkey [firebug-p1]
Verified fixed on trunk and 1.9.1 with builds like:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090614 Minefield/3.6a1pre ID:20090614030825

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090614 Shiretoko/3.5pre ID:20090614030748
Target Milestone: --- → mozilla1.9.2a1
Crash Signature: [@ JS_EvaluateUCInStackFrame]
Component: JavaScript Debugging/Profiling APIs → JavaScript Engine
You need to log in before you can comment on or make changes to this bug.