crash on [@ JS_EvaluateUCInStackFrame]

VERIFIED FIXED in mozilla1.9.2a1

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: John J. Barton, Assigned: mrbkap)

Tracking

(4 keywords)

Trunk
mozilla1.9.2a1
crash, regression, testcase, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey [firebug-p1], crash signature)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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, http://getfirebug.com/releases/firebug/1.5X

Open the test case from
https://bugzilla.mozilla.org/show_bug.cgi?id=495663

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?
(Reporter)

Updated

8 years ago
Whiteboard: [firebug-p1]
(Reporter)

Comment 1

8 years ago
Sorry forgot the crash stats:
http://crash-stats.mozilla.com/report/index/9f9abaaf-a515-4189-bcbe-5386d2090609
and the stack points to frame.eval()
Does it happen with Firebug 1.4b1?
(Reporter)

Comment 3

8 years ago
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
Keywords: regressionwindow-wanted
(Reporter)

Comment 6

8 years ago
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
Shiretoko/3.5pre
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.
(Reporter)

Comment 7

8 years ago
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.

Pass: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f706df925e9f
Fail: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0ac3ca7d67a8

Check-ins: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=f706df925e9f&tochange=0ac3ca7d67a8

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:

Pass: http://hg.mozilla.org/mozilla-central/rev/9750fb0ef665
Fail: http://hg.mozilla.org/mozilla-central/rev/ae2437e9e9dd

Changesets: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9750fb0ef665&tochange=ae2437e9e9dd

Ok, we overlap with all those check-ins. That makes it harder to find the causing bug.
Created attachment 382363 [details]
gdb stack
regresses between 06-04-03 and 06-05-03 on tracemonkey.

http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=a481f4cce93a&tochange=d0060a58e57d
Mmh why we are 0x0 here when it's given that it cannot be 0x0?

http://mxr.mozilla.org/mozilla1.9.1/source/js/src/jsdbgapi.cpp#1271

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
Brendan, it was your patch on bug 494235.
Blocks: 494235
Keywords: regressionwindow-wanted → regression
good catch, whimboo. thanks!
Keywords: testcase
Summary: crash on jsdIStackFrame.eval() → crash on [@ JS_EvaluateUCInStackFrame]
Created attachment 382378 [details]
testcase

Comment 16

8 years ago
Also happens with JavaScript Debugger extension:

1. Install JavaScript Debugger: https://addons.mozilla.org/en-US/firefox/addon/216
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.
Blocking.
Flags: blocking1.9.1? → blocking1.9.1+
Blake is on this already.

/be
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
(Assignee)

Comment 20

8 years ago
Created attachment 382606 [details] [diff] [review]
patch v1
Attachment #382606 - Flags: review?(brendan)
Comment on attachment 382606 [details] [diff] [review]
patch v1

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

/be
Attachment #382606 - Flags: review?(brendan) → review+
(Assignee)

Comment 22

8 years ago
Created attachment 382655 [details] [diff] [review]
patch v1.5
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.

/be
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
(Assignee)

Comment 25

8 years ago
http://hg.mozilla.org/tracemonkey/rev/0545e4f12f4b mozilla-central is red right now.
Whiteboard: [firebug-p1] → fixed-in-tracemonkey [firebug-p1]
(Assignee)

Comment 26

8 years ago
http://hg.mozilla.org/mozilla-central/rev/551a20151798 and http://hg.mozilla.org/releases/mozilla-1.9.1/rev/30706a2c7a0f
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Target Milestone: --- → mozilla1.9.2a1
Crash Signature: [@ JS_EvaluateUCInStackFrame]
Component: JavaScript Debugging/Profiling APIs → JavaScript Engine
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.