Closed Bug 463681 Opened 12 years ago Closed 12 years ago

mozilla-central leak test tinderboxes should have fatal assertions

Categories

(Firefox Build System :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9.1b3

People

(Reporter: dbaron, Assigned: nthomas)

References

(Blocks 1 open bug)

Details

(Keywords: verified1.9.1)

Attachments

(1 file)

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
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.
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. :)
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
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?
Attachment #347886 - Flags: review? → review?(ted.mielczarek)
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+
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
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
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 ?
Depends on: 459666
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.