Need minidump file from slave: talos-r3-fed-048

RESOLVED INCOMPLETE

Status

Release Engineering
General Automation
--
major
RESOLVED INCOMPLETE
6 years ago
4 years ago

People

(Reporter: mats, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [symbols])

(Reporter)

Description

6 years ago
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
(Reporter)

Updated

6 years ago
Blocks: 759194
Sorry, that file is no longer present.
(Reporter)

Comment 2

6 years ago
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?
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.
Assignee: server-ops-releng → nobody
Component: Server Operations: RelEng → Release Engineering
QA Contact: arich → release
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.
(Reporter)

Comment 5

6 years ago
I forgot to include the link to the log:
https://tbpl.mozilla.org/php/getParsedLog.php?id=12140401&tree=Mozilla-Beta
(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.
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

6 years ago
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.
(Reporter)

Comment 9

6 years ago
(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

6 years ago
(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 ...?
(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?
Component: Release Engineering → Release Engineering: Automation (General)
QA Contact: release → catlee
Whiteboard: [symbols]

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.