1494799 - missing crash stacks for web platform tests

Status: NEW

(Testing :: web-platform-tests, defect)

Description

[Karl Tomlinson (back July 26 :karlt)]

See for example https://treeherder.mozilla.org/logviewer.html#?job_id=201397905&repo=mozilla-central

xpcshell ccov tests have stacks, and so this doesn't seem to be a problem for ccov in general.
e.g.
https://treeherder.mozilla.org/logviewer.html#?job_id=201397970&repo=mozilla-central&lineNumber=2169

Comment 1

[Karl Tomlinson (back July 26 :karlt)]

https://treeherder.mozilla.org/logviewer.html#?job_id=201391164&repo=mozilla-central&lineNumber=5137
is not ccov and demonstrates this bug.

Comment 2

[Andreas Pehrson [:pehrsons] (back in Aug 2021)]

Seeing that this has had no triage or other input for 5 months, James, can you comment on what is to be expected here?

Comment 3

[James Graham [:jgraham]]

So, looking at an example, it seems like we are getting an IOError from marionette [1], which we interpret as a crash. We later call into mozcrash ([2], [3]) which is responsible for logging the stack but we aren't finding anything. So either we are misinterpreting the original IOError as a crash or we aren't getting a dump file for some reason. I wonder if the content process is crashing, but not the Chrome process? I thought we were setting MOZ_CRASHREPORTER_SHUTDOWN=1 to handle that case but right now I only see that set for fennec, so maybe that's the problem?

[1] https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=232469294&repo=autoland&lineNumber=21225
[2] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/tools/wptrunner/wptrunner/testrunner.py#585
[3] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/tools/wptrunner/wptrunner/browsers/firefox.py#429

Comment 4

[James Graham [:jgraham]]

No, I lie that gets set at https://searchfox.org/mozilla-central/source/testing/mozbase/mozrunner/mozrunner/utils.py#125 and running the code verifies that it is indeed set. Seems like this really needs a reproducable test case to figure out what's happening.

Comment 5

[Andreas Pehrson [:pehrsons] (back in Aug 2021)]

I've seen this some more -- it seems to happen after a test, or the entire test suite, times out and we kill the process from the harness.

For mochitests this gets us stacks of all threads for the parent process, though the best would be to have them for the child process too. Especially if we're hitting a rare deadlock of some sort, getting the stacks of all threads is crucial.