Closed Bug 506042 Opened 10 years ago Closed 10 years ago

dump out xpcshell crash stacks

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(status1.9.2 beta1-fixed, status1.9.1 wontfix)

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed
status1.9.1 --- wontfix

People

(Reporter: sdwilsh, Assigned: ted)

References

Details

Attachments

(1 file)

In a recent landing, we had xpcshell unit tests crashing, and they reported that the minidump was found, but nothing was printed out into the log.  It sure would be nice to see that information.
Do you have a link to the log?
I don't think someone is going to grab this soon..
Component: Release Engineering → Release Engineering: Future
Blocks: 507199
Blocks: 508767
there is a certain number of crashes in xpcshell boxes lately, it's hard to fix them without having any idea of what is crashing and where.
This could be really really useful to reduce orangeness.
I had a brief look at this and the log reports a minidump found, but never reports the stack, implying some sort of bug in the harness. It also helpfully deletes the dump so that we can't figure it out after the fact. I suggest temporarily showing the errors when calling the stack walker in
 http://mxr.mozilla.org/mozilla-central/source/build/automationutils.py#23
ted was explaining to someone on irc the other day that if you don't have an environment variable set, the test harness just deletes the minidumps.  This might be as easy as defining the right environment variables here in the harness.
It uses the same environment variables (via the same code, even) as the Mochitest/Reftest harnesses. I thought those were set globally in buildbot?

It's also possible this code got broken somewhere along the way, although I heavily tested it.

Code in question:
http://mxr.mozilla.org/mozilla-central/source/build/automationutils.py#23
(Just noticed that Nick linked the same thing, oops.) We could definitely add a simple else block there that explains why it isn't dumping a stack, like "no symbol path found" or "no minidump_stackwalk env var found".
Blocks: 510592
The problem is that symbolsPath is not defined. Someone wanna figure out why that's set in the build system for reftest but not xpcshell ?
Component: Release Engineering: Future → General
Product: mozilla.org → Testing
QA Contact: release → general
Version: other → unspecified
Oh. Mochitest/reftest use automation.py, which has the symbol path preprocessed into it. xpcshell tests don't use that, so we'd have to specify --symbol-path here:
http://mxr.mozilla.org/mozilla-central/source/testing/testsuite-targets.mk#99
There's a partial solution in attachment 396185 [details] [diff] [review] but I doubt that works for packaged builds.
Blocks: 511965
Simple fix.
Assignee: nobody → ted.mielczarek
Status: NEW → ASSIGNED
Attachment #396327 - Flags: review?(sayrer)
Attachment #396327 - Flags: review?(sayrer) → review+
We should land this on 1.9.2 as well.
We'll have to patch the buildbot code for packaged xpcshell-tests as well
 http://hg.mozilla.org/build/buildbotcustom/file/9a587b917756/steps/unittest.py#l455
http://hg.mozilla.org/mozilla-central/rev/50f276e59ea6
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Bug 512571 filed for the packaged unit test case.

(In reply to comment #13)
> We should land this on 1.9.2 as well.

And 1.9.1 ? Or are we missing other infra there already.
The patches to get stacks for xpcshell tests never landed on 1.9.1.
Component: General → Build Config
Product: Testing → Core
QA Contact: general → build-config
what about tryservers? i just got a crash on a tryserver, but no stack trace. is that expected?
That would be bug 483111.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.