Last Comment Bug 497119 - crash on [@ JS_EvaluateUCInStackFrame]
: crash on [@ JS_EvaluateUCInStackFrame]
fixed-in-tracemonkey [firebug-p1]
: crash, regression, testcase, verified1.9.1
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla1.9.2a1
Assigned To: Blake Kaplan (:mrbkap)
: jsd
: Jason Orendorff [:jorendorff]
: 497212 (view as bug list)
Depends on:
Blocks: 494235 497028
  Show dependency treegraph
Reported: 2009-06-09 08:50 PDT by John J. Barton
Modified: 2011-07-08 00:24 PDT (History)
15 users (show)
benjamin: blocking1.9.1+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

gdb stack (15.90 KB, text/plain)
2009-06-09 13:26 PDT, Henrik Skupin (:whimboo)
no flags Details
testcase (285 bytes, text/html)
2009-06-09 14:14 PDT, Henrik Skupin (:whimboo)
no flags Details
patch v1 (1.68 KB, patch)
2009-06-10 16:23 PDT, Blake Kaplan (:mrbkap)
brendan: review+
Details | Diff | Splinter Review
patch v1.5 (2.01 KB, patch)
2009-06-10 21:16 PDT, Blake Kaplan (:mrbkap)
brendan: review+
Details | Diff | Splinter Review

Description John J. Barton 2009-06-09 08:50:37 PDT
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.
Comment 1 John J. Barton 2009-06-09 08:52:42 PDT
Sorry forgot the crash stats:
and the stack points to frame.eval()
Comment 2 Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-06-09 10:23:04 PDT
Does it happen with Firebug 1.4b1?
Comment 3 John J. Barton 2009-06-09 10:23:59 PDT
probably. 1.5a3 is the same as 1.4b2
Comment 4 Rob Campbell [:rc] (:robcee) 2009-06-09 10:34:51 PDT
does this crash on mozilla central? This could be related to bug 483847. Same crash signature as bug 496981.
Comment 5 Rob Campbell [:rc] (:robcee) 2009-06-09 10:38:19 PDT
crashes on mozilla-central (minefield nightly, 060809) as well
Comment 6 John J. Barton 2009-06-09 11:47:25 PDT
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.
Comment 7 John J. Barton 2009-06-09 12:08:17 PDT
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
Comment 8 Henrik Skupin (:whimboo) 2009-06-09 12:47:55 PDT
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.
Comment 9 Henrik Skupin (:whimboo) 2009-06-09 13:03:10 PDT
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.
Comment 10 Henrik Skupin (:whimboo) 2009-06-09 13:26:43 PDT
Created attachment 382363 [details]
gdb stack
Comment 11 Rob Campbell [:rc] (:robcee) 2009-06-09 13:27:54 PDT
regresses between 06-04-03 and 06-05-03 on tracemonkey.
Comment 12 Henrik Skupin (:whimboo) 2009-06-09 13:35:04 PDT
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
Comment 13 Henrik Skupin (:whimboo) 2009-06-09 13:42:40 PDT
Brendan, it was your patch on bug 494235.
Comment 14 Rob Campbell [:rc] (:robcee) 2009-06-09 13:44:54 PDT
good catch, whimboo. thanks!
Comment 15 Henrik Skupin (:whimboo) 2009-06-09 14:14:05 PDT
Created attachment 382378 [details]
Comment 16 IU 2009-06-09 15:16:56 PDT
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.
Comment 17 Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-06-09 18:16:12 PDT
Comment 18 Brendan Eich [:brendan] 2009-06-09 20:42:08 PDT
Blake is on this already.

Comment 19 Rob Campbell [:rc] (:robcee) 2009-06-10 06:12:50 PDT
*** Bug 497212 has been marked as a duplicate of this bug. ***
Comment 20 Blake Kaplan (:mrbkap) 2009-06-10 16:23:08 PDT
Created attachment 382606 [details] [diff] [review]
patch v1
Comment 21 Brendan Eich [:brendan] 2009-06-10 16:35:04 PDT
Comment on attachment 382606 [details] [diff] [review]
patch v1

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

Comment 22 Blake Kaplan (:mrbkap) 2009-06-10 21:16:30 PDT
Created attachment 382655 [details] [diff] [review]
patch v1.5
Comment 23 Brendan Eich [:brendan] 2009-06-10 22:16:07 PDT
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.

Comment 24 Rob Campbell [:rc] (:robcee) 2009-06-11 10:26:23 PDT
yep. patch v1.5 fixes the problem for me in 3.5.
Comment 25 Blake Kaplan (:mrbkap) 2009-06-11 14:18:16 PDT mozilla-central is red right now.
Comment 27 Henrik Skupin (:whimboo) 2009-06-14 13:40:53 PDT
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

Note You need to log in before you can comment on or make changes to this bug.