geckodriver doens't find minidump files for content process crashes
Categories
(Testing :: geckodriver, defect, P3)
Tracking
(Not tracked)
People
(Reporter: whimboo, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webdriver:m15])
While working on tests for bug 1880257 I noticed that for the wdspec test for content crashes the minidump files are not copied to the folder as specified with the MINIDUMP_SAVE_PATH
environment. When having a look at our implementation I noticed that we are actually trying to copy the minidump files before waiting for the browser process to have shutdown:
We need to switch the order to actually check for minidump files when the Firefox process is gone.
Comment 1•1 month ago
•
|
||
I've tried to test with about:crashcontent
and for me, it looks like that we don't see on the geckodriver side that connection is closed, so the close method where we copy the files doesn't get executed. If I try to send another command after, then the whole chain is executed and the minidump files are copied.
Also, just coping the files after the browser shutdown doesn't seem to work, because the profile is gone by then. If we want to do it, we have to delay the removal of profile or do the copying of minidump files at a different codepoint.
Reporter | ||
Comment 2•1 month ago
|
||
So there is a race condition between sending the next command and the shutdown duration of Firefox in case of a content crash. Sending the next command immediately will cause a invalid session id
error and also by then the minidump files are not copied. Only waiting at least until the browser process is gone will result in a unknown error
with the minidump files copied.
Maybe we should check for the minidump files before removing the profile, but it could still be that we need something else. The exit code of Firefox in case of a content crash is 245.
Reporter | ||
Updated•27 days ago
|
Description
•