Closed Bug 387555 Opened 17 years ago Closed 15 years ago

should get automatic breakpad stacks from test crashes on unit test machines

Categories

(Release Engineering :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 481732

People

(Reporter: ted, Unassigned)

References

Details

robcee did some work on this previously, but he says it's still a manual process.  At this point, we should be able to get stacks locally from crashes on the unit test boxes.  We will need:
1) The boxes to build with debug info, see the mozconfigs from the nightly boxes
2) A local copy of the breakpad minidump_stackwalk tool (this can be built once per platform and just copied over)
3) Set MOZ_CRASHREPORTER_NO_REPORT in the environment

Then when a crash occurs, we should be able to:
1) Locate the minidump file in $PROFILE/minidumps
2) Run |make buildsymbols| in the objdir, which will produce a $objdir/dist/crashreporter-symbols/$BUILD_ID directory containing symbols
3) Run |minidump_stackwalk $minidump $objdir/dist/crashreporter-symbols/$BUILD_ID|, which will produce a stack trace.
From a short conversation, I think we'll either need to build with MOZILLA_OFFICIAL=1, or set MOZ_CRASHREPORTER=1 in the environment, otherwise breakpad crash reporting will not be active.
Depends on: 393415
(For the Linux case, we can get there quick-and-dirty by re-enabling the oh_crap handler and building with symbols.  Might be a worthwhile interim measure, especially given the periodic mochicrashes on qm-centos5-01.)
1) how much time does this add to the build cycle?

2) is this oh_crap handler documented somewhere?
Severity: normal → enhancement
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Version: unspecified → other
roc was asking for something similar on IRC recently, and I agree this sounds like a useful thing to do. 

One issue to solve is that we compile, run make check, and then remove all profiles before running reftest, crashtest and so on; so it's likely that any minidumps would be deleted in the case of an intermittent crash, just from the delay between a failure and a request to get a stack. We could rsync them somewhere else before hand.

On Windows I think we can configure the Visual Studio debugger to dump a stack straight into the log, which has obvious advantages. Anyone got any tricks for doing that on Linux & Mac too ? If that can be done without intruding on other builds (on the same box) then it might be a more automatic way to go.
We could pretty easily add some functionality to Mochitest to check for a minidump in the profile folder if the app exits with an error, and have an environment variable set to the path of minidump_stackwalk, which we could run on it. Once bug 468913 is fixed, we could probably do the same for reftest/crashtest. TUnit is a bit tougher, because the Breakpad handler doesn't get set in xpcshell.
I don't know where this falls on the overall priority list but we're certainly not getting to it this year.
Component: Release Engineering → Release Engineering: Future

I get two or three requests for this a week now.  Seems like we should bump this up in priority.
We have more disk on the socorro machine now too, so keeping the symbols for 48 hours or whatever shouldn't be a problem.
Example issue that fixing this would help:  bug 473013
(In reply to comment #10)
> We have more disk on the socorro machine now too, so keeping the symbols for 48
> hours or whatever shouldn't be a problem.

That's not relevant to getting stacks from the unit test machines, as they currently do their own builds. It is relevant to getting stacks from Talos, which is a separate bug.
bsmedberg fixed this in bug 481732.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.