Closed
Bug 523998
Opened 15 years ago
Closed 15 years ago
Assertion failure: OBJ_SHAPE(obj2) == vshape - test_bug366682.html, dom/tests/mochitest/ajax/offline/test_offlineMode.html
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 524743
People
(Reporter: bc, Assigned: jorendorff)
References
()
Details
(Keywords: assertion, intermittent-failure, valgrind)
Attachments
(3 files)
Running mochitest-plain on mozilla-central built with --enable-valgrind without --smc-check-all under valgrind 3.2.1. After dom/tests/mochitest/ajax/offline/test_offlineMode.html Assertion failure: OBJ_SHAPE(obj2) == vshape at js/src/jstracer.cpp:9269 with Valgrind error vex x86->IR: unhandled instruction bytes: 0xCC 0xE8 0xA9 0xF6
Flags: in-testsuite+
Updated•15 years ago
|
Comment 2•15 years ago
|
||
This assertion has sporadically failed during test_bug366682.html on a Linux debug build tinderbox run. (originally reported as bug 524138)
Summary: Assertion failure: OBJ_SHAPE(obj2) == vshape - dom/tests/mochitest/ajax/offline/test_offlineMode.html → Assertion failure: OBJ_SHAPE(obj2) == vshape - test_bug366682.html, dom/tests/mochitest/ajax/offline/test_offlineMode.html
Comment 3•15 years ago
|
||
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256315823.1256319242.11393.gz Linux mozilla-central test debug mochitests-3/5 on 2009/10/23 09:37:03 706 INFO TEST-PASS | /tests/extensions/cookie/test/test_same_base_domain_2.html | total number of cookies Assertion failure: OBJ_SHAPE(obj2) == vshape, at /builds/moz2_slave/mozilla-central-linux-debug/build/js/src/jstracer.cpp:9269
Comment 4•15 years ago
|
||
Need an owner. Also a regression window for when the sporadic failures started would be helpful. /be
![]() |
||
Comment 5•15 years ago
|
||
Not positive this is the same bug but the same assertion appeared on Linux mozilla-central test debug mochitests-3/5 on 2009/10/23 10:50:39 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256320239.1256323238.25935.gz 9731 INFO TEST-PASS | /tests/extensions/cookie/test/test_samedomain.html | total number of cookies Assertion failure: OBJ_SHAPE(obj2) == vshape, at /builds/moz2_slave/mozilla-central-linux-debug/build/js/src/jstracer.cpp:9269 TEST-UNEXPECTED-FAIL | automation.py | Exited with code -5 during test run
(In reply to comment #4) > Need an owner. Also a regression window for when the sporadic failures started > would be helpful. debug unit test tinderboxes have only been up since yesterday. More appearances: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256332883.1256336263.12380.gz Linux mozilla-central test debug mochitests-3/5 on 2009/10/23 14:21:23 9488 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug432225.html | Misspelling is what we think it is. Assertion failure: OBJ_SHAPE(obj2) == vshape, at /builds/slave/mozilla-central-linux-debug/build/js/src/jstracer.cpp:9269 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256335850.1256339183.13559.gz Linux mozilla-central test debug mochitests-3/5 on 2009/10/23 15:10:50 9706 INFO TEST-PASS | /tests/extensions/cookie/test/test_same_base_domain_2.html | total number of cookies Assertion failure: OBJ_SHAPE(obj2) == vshape, at /builds/slave/mozilla-central-linux-debug/build/js/src/jstracer.cpp:9269 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256337866.1256341155.3255.gz Linux mozilla-central test debug mochitests-3/5 on 2009/10/23 15:44:26 9696 INFO TEST-PASS | /tests/extensions/cookie/test/test_loadflags.html | total number of cookies Assertion failure: OBJ_SHAPE(obj2) == vshape, at /builds/slave/mozilla-central-linux-debug/build/js/src/jstracer.cpp:9269
Blocks: 523385
Comment 7•15 years ago
|
||
I'm also seeing it in real use - seamonkey dies within 5-30mins of starting. Made my own debug build to see why, and it's that assertion that pops up. Would output from a run be helpful?
Comment 8•15 years ago
|
||
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256551331.1256554731.8894.gz Linux mozilla-central test debug mochitests-3/5 on 2009/10/26 03:02:11
Assignee | ||
Comment 9•15 years ago
|
||
Taking. Assertions in methods like guardPropertyCacheHit that bank huge on the shape guarantees make me extra nervous. It's either "oh, silly assertion, let's fix that" or very bad indeed. Looking now.
Assignee: general → jorendorff
Flags: blocking1.9.2?
Assignee | ||
Comment 10•15 years ago
|
||
Can't tell which one. Offhand my guess would be "very bad indeed", but proving that is a matter of working backwards from the asserting method to every possible caller. I'll do it, but a stack would narrow the search space. I filed bug 524522 (with patch) to that effect.
I hit this while browsing; jorendorff and dmandelin helped drive this gdb session. I was using http://hg.mozilla.org/mozilla-central/rev/cf193e9f7eaa plus the patches in http://hg.mozilla.org/users/dbaron_mozilla.com/patches/file/c001d2df4ae9 up to and including debug-cc-smaller-scope. The firefox stdout from this gdb session will be the next attachment.
Comment 13•15 years ago
|
||
One thing we noticed while debugging is that in this assertion, (a) OBJ_SHAPE(obj2) == (1 << 24) == SHAPE_OVERFLOW_BIT (b) vshape == 0 AFAIK, both of those values are bogus. (a) may be caused by the bug that causes shapes on some objects not to be regenerated, so that the object got the overflow shape, we did a GC (and dbaron and I confirmed that that was successful in fitting all the shapes and didn't need to disable the property cache), but missed that scope, so it kept the bad value. (b) could happen if we fill the property cache with an object that has a shape of SHAPE_OVERFLOW_BIT. I believe js_FillPropertyCache doesn't guard against that condition (rather, it tests that the PC is not disabled, i.e., rt->shapeGen != SHAPE_OVERFLOW_BIT), so in that case we would pack a vcap, getting only the bottom 24 bits of 1<<24, i.e., 0. So, hopefully this is really just a dup of bug 524743. But we should add some assertions to js_FillPropertyCache to prevent us from using a vshape of SHAPE_OVERFLOW_BIT or greater.
Assignee | ||
Comment 14•15 years ago
|
||
Nice analysis! Here are the assertions you ordered.
Attachment #409425 -
Flags: review?(dmandelin)
Comment 15•15 years ago
|
||
Comment on attachment 409425 [details] [diff] [review] v1 Thanks!
Attachment #409425 -
Flags: review?(dmandelin) → review+
Comment 16•15 years ago
|
||
is there any ETA on this? We're having to run unittests both ways until this is fixed, and the extra load is hurting wait times.
Assignee | ||
Comment 17•15 years ago
|
||
(In reply to comment #16) > is there any ETA on this? > > We're having to run unittests both ways until this is fixed, and the extra load > is hurting wait times. This should already be fixed (in bug 524743). The patch here is to add a few assertions to catch the problem earlier if it happens again. Are you still seeing this? On which branches?
Updated•15 years ago
|
Flags: blocking1.9.2? → blocking1.9.2+
Assignee | ||
Comment 18•15 years ago
|
||
Just landed v1 in tracemonkey. Note that this is not the patch that fixes this bug, just some extra assertions; see comment 13 and 14. http://hg.mozilla.org/tracemonkey/rev/c4e383beacfb
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Updated•12 years ago
|
Keywords: intermittent-failure
Updated•12 years ago
|
Whiteboard: [orange]
You need to log in
before you can comment on or make changes to this bug.
Description
•