Last Comment Bug 759197 - Need minidump file from slave: talos-r3-fed-048
: Need minidump file from slave: talos-r3-fed-048
Status: RESOLVED INCOMPLETE
[symbols]
:
Product: Release Engineering
Classification: Other
Component: General Automation (show other bugs)
: other
: All Other
-- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Chris AtLee [:catlee] [PTO until Jan 29]
: Chris AtLee [:catlee] [PTO until Jan 29]
Mentors:
Depends on:
Blocks: 759194
  Show dependency treegraph
 
Reported: 2012-05-28 14:09 PDT by Mats Palmgren (:mats)
Modified: 2013-08-12 21:54 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description User image Mats Palmgren (:mats) 2012-05-28 14:09:36 PDT
To analyze the crash in bug 759194 I need the following file:
/tmp/tmpr5OXWI/minidumps/4b07127c-f0eb-02c3-24912519-5e9998fb.dmp
from slave: talos-r3-fed-048

Thanks
Comment 1 User image Nick Thomas [:nthomas] (UTC+13) 2012-05-28 14:23:16 PDT
Sorry, that file is no longer present.
Comment 2 User image Mats Palmgren (:mats) 2012-05-28 14:43:22 PDT
Uhm, that's unfortunate...  so there are two problems here:

1. why was the stack presented without symbols?  according to the log it got the
symbols from http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-linux/1338233604/firefox-13.0.en-US.linux-i686.crashreporter-symbols.zip
(and I downloaded that URL and it looks fine to me, it includes 
libxul.so/D74029798C17734A1F4ABAD0BE4819F60/libxul.so.sym)

2. minidump files needs to be kept longer to give us some time to extract them
for cases like this -- are we pressed for disk space on these boxes?
Comment 3 User image Phil Ringnalda (:philor) 2012-05-28 15:05:30 PDT
Wrong path - what you want is /home/cltbld/talos-slave/test/minidumps/4b07127c-f0eb-02c3-24912519-5e9998fb.dmp where it was saved way down at the end of the log, based on the env var MINIDUMP_SAVE_PATH, rather than the path where processing first found it.
Comment 4 User image Phil Ringnalda (:philor) 2012-05-28 15:13:04 PDT
As to why without symbols, but big offsets, I'd guess that 122 threads with strong evidence of video sprinkled through them means it was a crash in the known-busted ancient system libraries we use, and use without symbols, bug 528231.
Comment 5 User image Mats Palmgren (:mats) 2012-05-28 15:19:09 PDT
I forgot to include the link to the log:
https://tbpl.mozilla.org/php/getParsedLog.php?id=12140401&tree=Mozilla-Beta
Comment 6 User image Nick Thomas [:nthomas] (UTC+13) 2012-05-28 15:23:29 PDT
(In reply to Phil Ringnalda (:philor) from comment #3)
> Wrong path - what you want is
> /home/cltbld/talos-slave/test/minidumps/4b07127c-f0eb-02c3-24912519-5e9998fb.
> dmp where it was saved way down at the end of the log, based on the env var
> MINIDUMP_SAVE_PATH, rather than the path where processing first found it.

Unfortunately this doesn't exist either, because the test/ dir is deleted next time we do a unit test run. I'll try rerunning the job and setting up an rsync to save the minidump elsewhere.
Comment 7 User image Phil Ringnalda (:philor) 2012-05-28 16:59:44 PDT
Mmm, so bug 544062, which intended to save minidumps from unittest runs, was a total waste of time since it put them in a place that's clobbered on every unittest run?
Comment 8 User image Aki Sasaki [:aki] 2012-06-07 13:46:14 PDT
Looks like there isn't anything left to do for this specific bug.
Catlee filed bug 762237 - change MINIDUMP_SAVE_PATH for unittests to be outside of build directory.

Mats, do you need access to a linux test machine to try to debug bug 759194 in the meantime?
If so, we can morph this bug.
If not, I'm not sure there's anything left to do here.
Comment 9 User image Mats Palmgren (:mats) 2012-06-07 14:45:36 PDT
(In reply to Aki Sasaki [:aki] from comment #8)
> Mats, do you need access to a linux test machine to try to debug bug 759194
> in the meantime?

No thanks, I suspect these crashes are rare and aren't worth trying to
reproduce manually.  We need to be prepared when they do occur though.
Saving minidumps so they persist for while so we can extract them is good.

Even better would be if we can fix the code that tries to extract the stack
trace from the dump for the log.  Even if the crash occurred in a system
library that we don't have symbols for, I don't understand why there are
no symbols at all, not even for the libxul.so stack frames.  The log says
the symbols file was downloaded, so why no stack symbols at all?
Comment 10 User image Aki Sasaki [:aki] 2012-06-07 18:15:03 PDT
(In reply to Mats Palmgren [:mats] from comment #9)
> Even better would be if we can fix the code that tries to extract the stack
> trace from the dump for the log.

Where is this code?  Is it in the test harness or the build system, or ...?
Comment 11 User image Chris Cooper [:coop] 2012-06-21 13:30:05 PDT
(In reply to Mats Palmgren [:mats] from comment #9)
> Even better would be if we can fix the code that tries to extract the stack
> trace from the dump for the log.  Even if the crash occurred in a system
> library that we don't have symbols for, I don't understand why there are
> no symbols at all, not even for the libxul.so stack frames.  The log says
> the symbols file was downloaded, so why no stack symbols at all?

Bug 571443 was just fixed last week.  Has that helped at all here?

Note You need to log in before you can comment on or make changes to this bug.