Bob Clary [:bc] (inactive) Reporter
	Description • 15 years ago

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

	Daniel Holbert [:dholbert]
	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)

	(not currently active) Ted Mielczarek
	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

	Brendan Eich [:brendan]
	Comment 4 • 15 years ago

Need an owner. Also a regression window for when the sporadic failures started would be helpful.

/be

	Robert Strong (they/them - no direct email)
	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

	David Baron :dbaron:
	Comment 6 • 15 years ago

(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

	Sune Mølgaard
	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?

	Phil Ringnalda (:philor)
	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

	Jason Orendorff [:jorendorff] 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.

	Jason Orendorff [:jorendorff] 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.

	David Baron :dbaron:
	Comment 11 • 15 years ago

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.

	David Mandelin [:dmandelin]
	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.

	Jason Orendorff [:jorendorff] Assignee
	Comment 14 • 15 years ago

Nice analysis! Here are the assertions you ordered.

	David Mandelin [:dmandelin]
	Comment 15 • 15 years ago

Comment on attachment 409425 [details] [diff] [review]
v1

Thanks!

	John O'Duinn [:joduinn] (please use "needinfo?" flag)
	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.

	Jason Orendorff [:jorendorff] 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?

	Jason Orendorff [:jorendorff] 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

	Robert Sayre
	Comment 19 • 15 years ago

http://hg.mozilla.org/mozilla-central/rev/c4e383beacfb