Closed Bug 1098258 Opened 5 years ago Closed 5 years ago

Install minidump stackwalk and define symbols path for Marionette unit tests

Categories

(Testing :: Marionette, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla36

People

(Reporter: davehunt, Assigned: ahal)

References

Details

Attachments

(2 files, 1 obsolete file)

It appears that crash dumps are not being processed for Marionette unit tests due to the symbols path not being provided and the MINIDUMP_STACKWALK environment variable not being set. See an example crash in the following log:
https://treeherder.mozilla.org/logviewer.html#?job_id=3812049&repo=mozilla-inbound
What's needed here? Is this simply a case of adding the following to the config dict in mozharness/configs/marionette/test_config.py:

"download_symbols": "ondemand",
"download_minidump_stackwalk": True,

Is there a reason these are not already set? Why do we only set the symbols path for emulator and gaiatest? Needinfo'ing chmanchester and jgriffin based on their contributions to the Marionette mozharness components.
Flags: needinfo?(jgriffin)
Flags: needinfo?(cmanchester)
Attached file MozReview Request: bz://1098258/ahal (obsolete) —
Attachment #8522226 - Flags: review?(jgriffin)
/r/585 - Bug 1098258 - Make sure symbols_path and MINIDUMP_STACKWALK are set for desktop marionette, r=jgriffin

Pull down this commit:

hg pull review -r 9b5adc0154ac26c96fa23ce76c6f721df39709ac
The answer to your question is probably "no good reason".
Assignee: nobody → ahalberstadt
Status: NEW → ASSIGNED
Flags: needinfo?(jgriffin)
Flags: needinfo?(cmanchester)
Attachment #8522226 - Flags: review?(jgriffin) → review+
https://reviewboard.mozilla.org/r/583/#review245

Yeah, the current exclusion for desktop Marionette is confusing, and probably and acccident.  Thanks for fixing.
Attachment #8522250 - Flags: review?(jgriffin) → review+
https://hg.mozilla.org/build/mozharness/rev/3a32e88478ff

It's not safe to land the gecko patch until the mozharness one is merged to production.
Oh, hmm. Does that mean if I land the gecko patch the same oranges will be exposed as were exposed by your patch? If that's the case, then I guess we need to look into getting a developer to fix it before I can land :/..

Once the mozharness patch is merged to production it should at least be trivial for them to push to try with the gecko patch and we can provide the instructions.
(In reply to Andrew Halberstadt [:ahal] from comment #9)
> Oh, hmm. Does that mean if I land the gecko patch the same oranges will be
> exposed as were exposed by your patch? If that's the case, then I guess we
> need to look into getting a developer to fix it before I can land :/..

No, we see the crash but it still doesn't cause the test to fail without my patch.
The mozharness change was merged to production.

https://hg.mozilla.org/integration/mozilla-inbound/rev/6a1a0a357f11
https://hg.mozilla.org/mozilla-central/rev/6a1a0a357f11
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Attachment #8522226 - Attachment is obsolete: true
Attachment #8618623 - Flags: review+
You need to log in before you can comment on or make changes to this bug.