mozilla-central leak test tinderboxes should have fatal assertions

RESOLVED FIXED in mozilla1.9.1b3

Status

defect
P3
critical
RESOLVED FIXED
11 years ago
a year ago

People

(Reporter: dbaron, Assigned: nthomas)

Tracking

(Blocks 1 bug, {verified1.9.1})

Trunk
mozilla1.9.1b3
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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".
Duplicate of this bug: 463682
Assignee

Comment 2

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

Comment 4

11 years ago
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
Component: Release Engineering → Build Config
Product: mozilla.org → 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. :)

Updated

11 years ago
Blocks: 279923
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).
Depends on: 459666
Assignee

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
Status: NEW → ASSIGNED
Attachment #347886 - Flags: review?
Assignee

Updated

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

Updated

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+
Assignee

Updated

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:
http://hg.mozilla.org/mozilla-central/rev/3a0da92f1ea2

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

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.
Assignee

Comment 15

11 years ago
(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 ?

Updated

10 years ago
Depends on: 459666

Updated

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