function f(x) { [1].some(x) } for each(let b in this) { try { f(b) } catch (e) {} } asserts js debug shell (tested with a threadsafe deterministic 32-bit debug build) on m-i changeset 4dceda951fba without any CLI arguments at Assertion failure: isTenured(), at gc/Heap.h My configure options are: LD=ld CROSS_COMPILE=1 CXX="clang++ -Qunused-arguments -arch i386" RANLIB=ranlib CC="clang -Qunused-arguments -arch i386" AS=$CC AR=ar STRIP="strip -x -S" HOST_CC="clang -Qunused-arguments" HOST_CXX="clang++ -Qunused-arguments" sh ./configure --target=i386-apple-darwin9.2.0 --enable-macos-target=10.5 --enable-optimize --enable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --enable-methodjit --enable-type-inference --disable-tests --enable-more-deterministic --enable-exact-rooting --enable-gcgenerational --with-ccache --enable-threadsafe <other NSPR options>

(In reply to Gary Kwong [:gkw] [:nth10sd] (PTO Sep 24 - 27) from comment #0) This test case is kind of evil! Let's hope none of our global functions do anything destructive when you call them.

Patch to take account of things in the nursery, which are shown with the letter 'N'.

Comment on attachment 809981 [details] [diff] [review] fix-dump-heap Review of attachment 809981 [details] [diff] [review]: ----------------------------------------------------------------- Ooh, I like!

DumpHeapComplete doesn't deal with nursery stuff correctly anyway because there's no way to iterate over all the objects in the nursery. We will occasionally hit some nursery things from MarkRuntime though, which I think is why the assert happens. I think we have the choice of two behaviors: 1. Do a nursery collection at the top of DumpHeapComplete. Then you'll at least see all the live objects. The downside is that the heap is modified, which people probably don't expect. 2. Ignore the nursery entirely and don't modify the heap. I can imagine people wanting both of these. Why don't we force them to pass an enum in with two clear values? CollectNurseryBeforeDump IgnoreNurseryObjects I think that existing calls to DumpHeapComplete probably want to pass in CollectNurseryBeforeDump. IgnoreNurseryObjects would mostly be useful while debugging leaks and stuff. Additionally, we should change DumpHeapVisitRoot to ignore nursery objects. Does that sound reasonable? CCing Andrew since he uses DumpHeapComplete more than anyone.

That sounds good. Here's an updated patch that works as described. Also, this doesn't fclose(stdout) in the dumpHeapComplete() shell function.

Comment on attachment 810578 [details] [diff] [review] fix-dump-heap v2 Review of attachment 810578 [details] [diff] [review]: ----------------------------------------------------------------- Thanks.

Backed out for compilation errors: https://tbpl.mozilla.org/php/getParsedLog.php?id=28457268&tree=Mozilla-Inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/06f9ccafcf8b

I forgot to update the call to js::DumpHeapComplete().

Backed out for crashes on Android 4.0: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=3e20fa222424&jobname=Android remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/90585002d95a

Bah, was reading the wrong log, this is infra afaict, will reland

Relanded, sorry for the noise: https://hg.mozilla.org/integration/mozilla-inbound/rev/10107fefbfe0