Closed Bug 497998 Opened 12 years ago Closed 12 years ago

Firebug crashes Firefox with "Assertion failure: cx->fp, .../jsdbgapi.cpp:1246"

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
blocking1.9.1 --- -

People

(Reporter: cbartley, Assigned: mrbkap)

References

Details

(Keywords: fixed1.9.1.1, Whiteboard: fixed-in-tracemonkey [3.5RC2?] [tb3needs])

Attachments

(2 files)

Attached file testcase
After Firebug stops at a breakpoint, clicking inside the Firebug UI causes the following assertion failure:

Assertion failure: cx->fp, at /Users/cbartley/Dev/mozilla-c/src/js/src/jsdbgapi.cpp:1246

This is related to bug 497119.
Attached patch FixSplinter Review
Forgot to remove this when I removed the assumption that fp is active (as opposed to dormant).
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #383020 - Flags: review?(brendan)
Attachment #383020 - Flags: review?(brendan) → review+
http://hg.mozilla.org/tracemonkey/rev/9b0e68c238eb and http://hg.mozilla.org/mozilla-central/rev/ecbd68d83cfa
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-tracemonkey
Verified fixed on trunk 29163:ecbd68d83cfa.
Status: RESOLVED → VERIFIED
Duplicate of this bug: 498232
Comment on attachment 383020 [details] [diff] [review]
Fix

Since bug 496824 was checked in on the 1.9.1 branch, we need this there too.
Attachment #383020 - Flags: approval1.9.1?
Flags: wanted1.9.1?
Whiteboard: fixed-in-tracemonkey → fixed-in-tracemonkey [3.5RC2?]
Blocks: 496824
Duplicate of this bug: 499021
Whiteboard: fixed-in-tracemonkey [3.5RC2?] → fixed-in-tracemonkey [3.5RC2?] [tb3needs]
Flags: blocking1.9.1.1?
Attachment #383020 - Flags: approval1.9.1? → approval1.9.1.1?
Comment on attachment 383020 [details] [diff] [review]
Fix

Moving request to 1.9.1.1. This fixes debugging using Venkman or Firebug something which at least Thunderbird will need for a while.
blocking1.9.1: --- → -
Flags: wanted1.9.1?
Flags: wanted1.9.1.x+
Flags: blocking1.9.1.1?
Flags: blocking1.9.1.1-
Attachment #383020 - Flags: approval1.9.1.1? → approval1.9.1.1+
I see a hang on OSX using the testcase attached to this bug for build:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090715 Shiretoko/3.5.1pre ID:20090715031842 with firebug 1.4.0b7



...but is verified FIXED on 1.9.1 nightly on WinXP: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090715 Shiretoko/3.5.1pre (.NET CLR 3.5.30729) ID:20090715044728 with firebug 1.4.0b7
aakash: can you file a new bug and get a stack trace from a shark enabled build?
why would I file a new bug timeless?
Two notes:

This bug only ever appeared in debug builds, so it will be necessary to verify it on a debug build.

Right now it's blocked by bug 497028 which has not yet landed on branch (hopefully it will land in 1.9.1.2; it's too late for 1.9.1.1).

The easiest course of action is to wait for 497028's patch to land on branch before trying to verify this bug on branch.
Depends on: 497028
Curtis or Blake: can you verify that this is fixed in latest-mozilla1.9.1 nightly or better yet the 3.5.1 release candidate: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.5.1-candidates/build1/
(In reply to comment #13)
> Curtis or Blake: can you verify that this is fixed in latest-mozilla1.9.1
> nightly or better yet the 3.5.1 release candidate:
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.5.1-candidates/build1/

I don't think we *can* verify in a nightly or the release candidate.  My understanding is that this bug was an erroneous assertion that only triggered in debug builds.  So the bad news is that we can only verify it in a debug build.  The good news is that it was never in non-debug builds anyway. (Unless we have nightlies with assertions enabled that I don't know about.)

Then there is the whole issue with bug 497028 blocking the reproduction of this bug (on OS X) anyway.  The repro steps are essentially the same, and that bug hangs the browser.
Yesterday I created a debug build on OS X, on which I tried the steps to reproduce the problem. I did not see the assertion in the bug summary, and the application did not hang right away. I tried a few more times, and eventually the build hung.

Curtis, can you confirm that this is sufficient to verify the bug, and that the hang is an independent issue from this?
(In reply to comment #15)
> Yesterday I created a debug build on OS X, on which I tried the steps to
> reproduce the problem. I did not see the assertion in the bug summary, and the
> application did not hang right away. I tried a few more times, and eventually
> the build hung.
> 
> Curtis, can you confirm that this is sufficient to verify the bug, and that the
> hang is an independent issue from this?

I think that it does verify the bug, but I can't be 100% certain that it does.  It seems like we should be able to just look at the source code and verify that the assertion statement is no longer there...
Component: JavaScript Debugging/Profiling APIs → JavaScript Engine
You need to log in before you can comment on or make changes to this bug.