mozilla-central leak test tinderboxes should have fatal assertions

RESOLVED FIXED in mozilla1.9.1b3


11 years ago
a year ago


(Reporter: dbaron, Assigned: nthomas)


(Blocks 1 bug, {verified1.9.1})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)

The leak test tinderboxes used to be configured so that assertions were fatal.  (In particular, $MozAssertBehavior in the 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".
Duplicate of this bug: 463682

Comment 2

11 years ago
We're setting XPCOM_DEBUG_BREAK=stack-and-abort in the environment already
You can see it in the logs too.

Buildbot reported "program finished with exit code 0" when running "python -- -CreateProfile default" in
so something isn't detecting the assertions and passing them on.

Comment 4

11 years ago
Also, why is forcing the value of XPCOM_DEBUG_BREAK to warn ?
Component: Release Engineering → Build Config
Product: → Core
QA Contact: release → build-config
Version: other → unspecified
Dunno, but it seems likely that bhearsum copied that from elsewhere. At least that makes this easy to fix. :)


11 years ago
Blocks: 279923
This is somewhat tangential, but this wasn't really a regression, not in the usual sense:

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).
Depends on: 459666

Comment 8

11 years ago
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.
Assignee: nobody → nthomas
Attachment #347886 - Flags: review?


11 years ago
Attachment #347886 - Flags: review? → review?(ted.mielczarek)


11 years ago
Priority: -- → P2
Version: unspecified → Trunk
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.
Attachment #347886 - Flags: review?(ted.mielczarek) → review+


11 years ago
Priority: P2 → P3
Whiteboard: waiting on blocker to land
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.)
Depends on: 459613
No longer depends on: 459666
Whiteboard: waiting on blocker to land
I landed this on mozilla-central:

We should probably land on 1.9.1 as well once bug 459613 lands.
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1

Comment 13

11 years ago
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.

Comment 15

11 years ago
(In reply to comment #12)
> I landed this on mozilla-central:
> 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 ?


10 years ago
Depends on: 459666


a year ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.