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)
Release Engineering
General
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.
Reporter | ||
Comment 1•17 years ago
|
||
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.
(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.)
Comment 4•16 years ago
|
||
1) how much time does this add to the build cycle? 2) is this oh_crap handler documented somewhere?
Reporter | ||
Updated•16 years ago
|
Severity: normal → enhancement
Reporter | ||
Updated•16 years ago
|
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Version: unspecified → other
Comment 5•16 years ago
|
||
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.
Reporter | ||
Comment 6•16 years ago
|
||
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.
Comment 8•16 years ago
|
||
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
Comment 9•15 years ago
|
||
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.
Comment 11•15 years ago
|
||
Example issue that fixing this would help: bug 473013
Reporter | ||
Comment 12•15 years ago
|
||
(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.
Reporter | ||
Comment 13•15 years ago
|
||
bsmedberg fixed this in bug 481732.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Comment 14•14 years ago
|
||
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•