The leak test tinderboxes used to be configured so that assertions were fatal. (In particular, $MozAssertBehavior in the tinder-config.pl should be "stack-and-abort" rather than its default of "warn".) However, this seems to have changed somehow or been dropped in the conversion to mozilla-central. We're noticing now because there's an assertion in the logs now (regressed sometime recently, I think) and that assertion isn't causing the tree to be orange. It should be. However, in order to fix tinderbox we'll need to figure out a fix for that assertion as well. That said, it might be good to test the fix temporarily while there is an assertion to make sure that the fix actually makes assertions turn the tree orange. See the multiple occurrences of this in the log: ###!!! ASSERTION: GetPrimaryFrameFor() called while nsFrameManager is being destroyed!: 'Error', file /builds/moz2_slave/mozilla-central-linux-debug/build/layout/base/nsFrameManager.cpp, line 340 on "Linux mozilla-central leak test build".

We're setting XPCOM_DEBUG_BREAK=stack-and-abort in the environment already http://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla2/config.py You can see it in the logs too. Buildbot reported "program finished with exit code 0" when running "python leaktest.py -- -CreateProfile default" in http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1226088356.1226089361.29239.gz&fulltext=1 so something isn't detecting the assertions and passing them on.

I meant to point to http://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla2/config.py#l176 also line 185 and 190.

Also, why is leaktest.py forcing the value of XPCOM_DEBUG_BREAK to warn ? http://mxr.mozilla.org/mozilla-central/source/build/leaktest.py.in#78

Dunno, but it seems likely that bhearsum copied that from elsewhere. At least that makes this easy to fix. :)

This is somewhat tangential, but this wasn't really a regression, not in the usual sense: http://hg.mozilla.org/mozilla-central/rev/e3e0fa5cb6fe Indeed, the printf deleted there was regularly spewing in builds when I was trying to fight the assertion count down to zero permanently.

Roughly as I said in bug 279923 comment 13, the assertion mentioned in comment 0 is bug 459666, (the fix for which is in bug 458453 which is waiting on bug 455314).

Use the value out of the environment if it's set (like our buildbots do), and dbaron says that stack is a more useful default value.

Comment on attachment 347886 [details] [diff] [review] Use an environment variable if there is one Seems reasonable. We should commit this as soon as we fix that remaining assertion.

I think bug 459613 fixed the remaining assertion so we can land this now.

(Note that there were multiple bugs on different causes of that assertion, but bug 459613 was the one that occurred in common use due to form controls.)

I landed this on mozilla-central: http://hg.mozilla.org/mozilla-central/rev/3a0da92f1ea2 We should probably land on 1.9.1 as well once bug 459613 lands.

FWIW, I was scanning logs for any further ASSERTIONs and found /builds/moz2_slave/mozilla-1.9.1-linux-debug/build/xpcom/base/nsDebugImpl.cpp:333: warning: enumeration value ‘NS_ASSERT_UNINITIALIZED’ not handled in switch

That's just a compiler warning, should be harmless.

(In reply to comment #12) > I landed this on mozilla-central: > http://hg.mozilla.org/mozilla-central/rev/3a0da92f1ea2 > > We should probably land on 1.9.1 as well once bug 459613 lands. Now that 459613 is hidden I won't know when that's fixed on 1.9.1. dbaron, could you please track that bug and land this when you can ?

(In reply to comment #16) > http://hg.mozilla.org/releases/mozilla-1.9.1/rev/343648da0bce verified.