Closed Bug 418540 Opened 15 years ago Closed 15 years ago

Assertion failure: OBJ_IS_NATIVE(obj)

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9beta4

People

(Reporter: jruderman, Assigned: brendan)

References

Details

(Keywords: assertion, regression, testcase)

Attachments

(5 files)

I'm getting this a lot today:

Assertion failure: OBJ_IS_NATIVE(obj), at /Users/jruderman/trunk/mozilla/js/src/jslock.c:1222

Brendan says he understands what is wrong and that this is a regression from bug 418239.
Flags: blocking1.9?
Keywords: testcase
Attached patch fixSplinter Review
Testing welcome. I'm in the middle of a huge patch...

/be
Assignee: general → brendan
Status: NEW → ASSIGNED
Attachment #304422 - Flags: review?(shaver)
Flags: blocking1.9? → blocking1.9+
OS: Mac OS X → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.9beta4
The patch fixes the crash and makes both try..catches produce reasonable error
messages (NS_ERROR_INVALID_POINTER from nsIDOMHTMLDivElement.appendChild for
the first, "r.appendChild is not a function" for the second).
Comment on attachment 304422 [details] [diff] [review]
fix

r=shaver, can someone run this in the suites?  I'm out today and tomorrow on a little speaking gig, and Brendan is deep in other important magicks.
Attachment #304422 - Flags: review?(shaver) → review+
I can test on linux today.
Fixing, my testsuite passed and bc's more exhaustive tests are in flight (he'll report regressions, if any, later today or tomorrow -- I don't expect any, this patch is pure conservatism).

js/src/jsinterp.c 3.439
js/src/jsinterp.h 3.76

/be

Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
note there were no differences in the shell results, only browser.
Comment on attachment 304691 [details] [diff] [review]
opt test differences

This is dire. Please file a bug? I have no idea why in-browser differs from shell, but the bus errors suggest GC pain. Cc the usual suspects ;-).

/be
Also, now that I've committed, can you reproduce these in-browser-only failures with a pure trunk pull of the entire firefox source tree? Thanks,

/be
I'm rebuilding locally to check on just that. I've also repulled the 1.9.0 tree and the 1.9.0 test tree to make sure they are in sync and have reverted the patch on the test tree. I'll run another set of tests on each and compare to make sure I haven't screwed the pooch here. The seneca box I'm using is pretty fast and I should have some definite results for you when you get up.
I think my test results were bogus. I can't reproduce the crashes locally with a fresh trunk build on linux.

ecma/String/15.5.4.6-2.js, js1_5/Scope/scope-003.js still have the window.toString() differences and the bad this is still there, but are known problems and unrelated to this bug. 

This is confirmed from the test runs starting at midnight at <http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTest>

I have another check when the tests complete later this morning on the seneca box.
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-418540.js,v  <--  regress-418540.js
initial revision: 1.1
Flags: in-testsuite+
Flags: in-litmus-
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.