Closed
Bug 1003085
Opened 11 years ago
Closed 11 years ago
Update in-tree dump_syms binaries
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
RESOLVED
FIXED
mozilla32
People
(Reporter: ted, Assigned: m_kato)
References
Details
Attachments
(4 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
ted
:
review+
bc
:
feedback+
|
Details | Diff | Splinter Review |
Upstream Breakpad made some changes that can make dump_syms much faster: https://code.google.com/p/google-breakpad/source/detail?r=1316 dmajor tested in bug 669384 and it looks like this makes buildsymbols actually usable for our Win64 builds, so we should update our in-tree dump_syms binaries: http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/tools/win32/ We've got binaries built with VC2010, 2012 and 2013 in there, we should really update all three.
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → m_kato
Assignee | ||
Comment 1•11 years ago
|
||
Assignee | ||
Comment 2•11 years ago
|
||
Assignee | ||
Comment 3•11 years ago
|
||
Comment on attachment 8416327 [details] [diff] [review] Part 1. Import r1316 into tree Just importing r1316 into tree. result of win64 debug... adding: xul.pdb/122499929D5C490CBFF757B36E309C581/xul.sym (140 bytes security) (deflated 74%) program finished with exit code 0 elapsedTime=340.011000 ========= Finished 'python c:/builds/moz2_slave/try-w64-d-00000000000000000000/build/build/pymake/make.py ...' (results: 0, elapsed: 5 mins, 40 secs) (at 2014-05-01 21:42:31.392773) =========
Attachment #8416327 -
Flags: review?(ted)
Assignee | ||
Comment 4•11 years ago
|
||
Comment on attachment 8416328 [details] [diff] [review] Part 2. Update dump_syms.exe build by 2010 sp1, 2012 update 4 and 2013 update 1.
Attachment #8416328 -
Flags: review?(ted)
Reporter | ||
Comment 5•11 years ago
|
||
Comment on attachment 8416327 [details] [diff] [review] Part 1. Import r1316 into tree Review of attachment 8416327 [details] [diff] [review]: ----------------------------------------------------------------- Since we're not building from source I don't think this is strictly necessary. (Also since this patch is already upstream it's not that big of a deal, we'll pick it up next time we sync anyway.)
Attachment #8416327 -
Flags: review?(ted)
Reporter | ||
Comment 6•11 years ago
|
||
Comment on attachment 8416328 [details] [diff] [review] Part 2. Update dump_syms.exe Review of attachment 8416328 [details] [diff] [review]: ----------------------------------------------------------------- Thanks! We should probably let the CrashKill team know to keep an eye on nightly crash reports for any weirdness that's fallout from this.
Attachment #8416328 -
Flags: review?(ted) → review+
Assignee | ||
Comment 7•11 years ago
|
||
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #5) > Comment on attachment 8416327 [details] [diff] [review] > Part 1. Import r1316 into tree > > Review of attachment 8416327 [details] [diff] [review]: > ----------------------------------------------------------------- > > Since we're not building from source I don't think this is strictly > necessary. (Also since this patch is already upstream it's not that big of a > deal, we'll pick it up next time we sync anyway.) OK. FYI, upstream cannot build on 2010 or 2012 due to https://code.google.com/p/google-breakpad/issues/detail?id=584. 2010 or 2012 needs #undef max after #include <set>.
Assignee | ||
Comment 8•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/46b2a27092f5 I also watch crash reporter data.
Comment 9•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/46b2a27092f5
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Reporter | ||
Comment 10•11 years ago
|
||
We need to back this out. RyanVM pointed me at a crash on TBPL that displayed no symbols: https://tbpl.mozilla.org/php/getParsedLog.php?id=39285462&tree=Mozilla-Inbound It turns out that the one change the upstream patch did make (outputting PUBLIC lines along with FUNC lines) is harmful because it outputs numerous PUBLIC lines at the same address, which BasicSourceLineResolver records as errors. When it hits 100 errors it fails parsing and gives up loading the symbol file.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 11•11 years ago
|
||
It actually looks like this was fixed upstream in rev 1319: https://code.google.com/p/google-breakpad/source/detail?r=1319 This ought to work okay if we rebuild the binaries at that rev (or newer).
Assignee | ||
Comment 12•11 years ago
|
||
built by r1319 with #undef max
Attachment #8419868 -
Flags: review?(ted)
Reporter | ||
Updated•11 years ago
|
Attachment #8419868 -
Flags: review?(ted) → review+
Assignee | ||
Comment 13•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/d6a0c7c471e2
Comment 14•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/d6a0c7c471e2
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Comment 15•11 years ago
|
||
I have vs 2010 and 2012 installed. I'm getting oodles of CoCreateInstance CLSID_DiaSource {3BFCEA48-620F-4B6B-81F7-B9AF75454C7D} failed (msdia*.dll unregistered?) errors on win7 64bit vs 2012 update 4 on building nightly but not beta or aurora. What compiler was used to build these? PS. Can we set the executable permission when checking executables like these into the tree?
Flags: needinfo?(m_kato)
Comment 16•11 years ago
|
||
Looks like 3BFCEA48-620F-4B6B-81F7-B9AF75454C7D is msdia120.dll distributed with vs 2013. Shouldn't dump_syms_vc1700.exe be built with vs 2012?
Assignee | ||
Comment 17•11 years ago
|
||
(In reply to Bob Clary [:bc:] from comment #16) > Looks like 3BFCEA48-620F-4B6B-81F7-B9AF75454C7D is msdia120.dll distributed > with vs 2013. Shouldn't dump_syms_vc1700.exe be built with vs 2012? I will rebuild this. VS2013 installation seems to overwrites 2012's SDK.
Flags: needinfo?(m_kato)
Assignee | ||
Updated•11 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 18•11 years ago
|
||
Also, I check 20140514 buiild, crash reporter appears file path of source code.
Comment 19•11 years ago
|
||
m_kato: do you have an estimated time for the new dump_syms? I am unable to test windows 64bit nightly builds until this is fixed.
Assignee | ||
Comment 20•11 years ago
|
||
(In reply to Bob Clary [:bc:] from comment #19) > m_kato: do you have an estimated time for the new dump_syms? I am unable to > test windows 64bit nightly builds until this is fixed. I will bulild this today, then send a review.
Assignee | ||
Comment 21•11 years ago
|
||
Assignee | ||
Comment 22•11 years ago
|
||
Comment on attachment 8424646 [details] [diff] [review] Rebuild dump_syms.exe for VS11 I setup VS11 only desktop, then it work fine.
Attachment #8424646 -
Flags: review?(ted)
Attachment #8424646 -
Flags: feedback?(bclary)
Reporter | ||
Updated•11 years ago
|
Attachment #8424646 -
Flags: review?(ted) → review+
Updated•11 years ago
|
Attachment #8424646 -
Flags: feedback?(bclary) → feedback+
Assignee | ||
Comment 24•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/4ce72b03591e
Comment 25•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4ce72b03591e
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•