1103038 - Use latest minidump_stackwalk to generate mochitest crash stacks

Status: RESOLVED INCOMPLETE

(Release Engineering :: General, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

Ted Mielczarek tells me that mochitest crash dumps are the unaltered output of minidump_stackwalk.  But the mochitest harness doesn't use the latest minidump_stackwalk.

Instead (as Ted tells me), it uses a "static copy in the build/tools repo", here:

http://hg.mozilla.org/build/tools/file/tip/breakpad/

The latest version is here:

https://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/minidump_stackwalk.cc

One reason this is significant (and the reason I've opened this bug) is that only the latest minidump_stackwalk shows the full thread state (the values of all user-level registers) for each thread as of a crash.

https://breakpad.appspot.com/7654002/

This information is needed to work around the design flaw in Intel processors described in bug 1018360 comment #0.  To summarize, crashes at addresses > 0x7fffffffffff often get misreported (by the kernel) as crashes at 0xffffffffffffffff (on Windows) or 0 (on Mac OS X or Linux).  The only workaround (that I'm aware of) is to be able to see the value at-crash of all user-level registers.

This problem has already been fixed for Socorro by bug 1018360.  But it also needs to be fixed for mochitest crash dumps.  I suspect the easiest way is to get the mochitest harness to use the current minidump_stackwalk.

One example of the need for this fix is at bug 1102898.

Comment 1

[(not currently active) Ted Mielczarek]

I wonder if it'd be useful to move these to tooltool nowadays? Can our test machines use tooltool or is that build machines only?

Comment 2

[Rail Aliiev [:rail]]

I see /tools/tooltool.py installed on test machines. Also http://hg.mozilla.org/build/puppet/file/07af46d74a08/modules/toplevel/manifests/slave/releng.pp#l14