Bug 1541603 Comment 10 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

My patch moved the creation of the minidumps directory out of start-up. Instead we can create it lazily (in the content process). This change caused many test failures and I have attempted to fix these failures over the last several weeks. The test infrastructure heavily relies on the minidumps directory to be available at start-up.

While fixing this problem, I ran into several issues. I fixed a subset of tests to correctly find the minidump file, while there are other tests that will fail due to this fix. Some tests want to find the dump file in the "profile/minidumps" folder, while other tests want to find the dump file in "temp" directory. 

All the failing tests have a similar theme. The problem is that it cannot find the dump file in the directory it wants to find it. The directory where the dump file is created is inconsistent across different test suites. 

I've fixed most of the test failures by adding a few of things including:
- I've added creating it lazily in the parent and plugin process to fix test failures.
- I've added an externallySetMinidumpPath boolean to keep track of whether to or not the crashReporter.minidumpPath has been set externally by a test. If it has, then let's use the externally set path for the test. 

I've pushed my most recent patch on phabricator: https://phabricator.services.mozilla.com/D36370
My most recent push to TRY: https://treeherder.mozilla.org/#/jobs?repo=try&revision=def246ee2a53c5adbd9dd3a2563a728179517150

This is the version with the least test failures (from few hundred down to less than 10 test failures): 

There are still 4 failing tests I'm aware of: 
- Windows 2012 build is failing because the test was not able to log "PROCESS CRASH". 
- There is another set of XPCshell X2 test failures: 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js and 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js
- An android Xpcshell test: externallySetMinidumpPath boolean

These are my findings as of August 28, 2019. My internship ends on August 30, 2019. I plan to continue working on this after I receive volunteer contributor access. I'll be around in IRC and slack.
My patch moved the creation of the minidumps directory out of start-up. Instead we can create it lazily (in the content process). This change caused many test failures and I have attempted to fix these failures over the last several weeks. The test infrastructure heavily relies on the minidumps directory to be available at start-up.

While fixing this problem, I ran into several issues. I fixed a subset of tests to correctly find the minidump file, while there are other tests that will fail due to this fix. Some tests want to find the dump file in the "profile/minidumps" folder, while other tests want to find the dump file in "temp" directory. 

All the failing tests have a similar theme. The problem is that it cannot find the dump file in the directory it wants to find it. The directory where the dump file is created is inconsistent across different test suites. 

I've fixed most of the test failures by adding a few of thing:
- I've added creating it lazily in the parent and plugin process to fix test failures.
- I've added an externallySetMinidumpPath boolean to keep track of whether to or not the crashReporter.minidumpPath has been set externally by a test. If it has, then let's use the externally set path for the test. 

I've pushed my most recent patch on phabricator: https://phabricator.services.mozilla.com/D36370
My most recent push to TRY: https://treeherder.mozilla.org/#/jobs?repo=try&revision=def246ee2a53c5adbd9dd3a2563a728179517150

This is the version with the least test failures (from few hundred down to less than 10 test failures): 

There are still 4 failing tests I'm aware of: 
- Windows 2012 build is failing because the test was not able to log "PROCESS CRASH". 
- There is another set of XPCshell X2 test failures: 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js and 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js
- An android Xpcshell test: externallySetMinidumpPath boolean

These are my findings as of August 28, 2019. My internship ends on August 30, 2019. I plan to continue working on this after I receive volunteer contributor access. I'll be around in IRC and slack.
My patch moved the creation of the minidumps directory out of start-up. Instead we can create it lazily (in the content process). This change caused many test failures and I have attempted to fix these failures over the last several weeks. The test infrastructure heavily relies on the minidumps directory to be available at start-up.

While fixing this problem, I ran into several issues. I fixed a subset of tests to correctly find the minidump file, while there are other tests that will fail due to this fix. Some tests want to find the dump file in the "profile/minidumps" folder, while other tests want to find the dump file in "temp" directory. 

All the failing tests have a similar theme. The problem is that it cannot find the dump file in the directory it wants to find it. The directory where the dump file is created is inconsistent across different test suites. 

I've fixed most of the test failures by adding a few things:
- I've added creating it lazily in the parent and plugin process to fix test failures.
- I've added an externallySetMinidumpPath boolean to keep track of whether to or not the crashReporter.minidumpPath has been set externally by a test. If it has, then let's use the externally set path for the test. 

I've pushed my most recent patch on phabricator: https://phabricator.services.mozilla.com/D36370
My most recent push to TRY: https://treeherder.mozilla.org/#/jobs?repo=try&revision=def246ee2a53c5adbd9dd3a2563a728179517150

This is the version with the least test failures (from few hundred down to less than 10 test failures): 

There are still 4 failing tests I'm aware of: 
- Windows 2012 build is failing because the test was not able to log "PROCESS CRASH". 
- There is another set of XPCshell X2 test failures: 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js and 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js
- An android Xpcshell test: externallySetMinidumpPath boolean

These are my findings as of August 28, 2019. My internship ends on August 30, 2019. I plan to continue working on this after I receive volunteer contributor access. I'll be around in IRC and slack.
My patch moved the creation of the minidumps directory out of start-up. Instead we can create it lazily (in the content process). This change caused many test failures and I have attempted to fix these failures over the last several weeks. The test infrastructure heavily relies on the minidumps directory to be available at start-up.

While fixing this problem, I ran into several issues. I fixed a subset of tests to correctly find the minidump file, while there are other tests that will fail due to this fix. Some tests want to find the dump file in the "profile/minidumps" folder, while other tests want to find the dump file in "temp" directory. 

All the failing tests have a similar theme. The problem is that it cannot find the dump file in the directory it wants to find it. The directory where the dump file is created is inconsistent across different test suites. 

I've fixed most of the test failures by adding a few things:
- I've added creating it lazily in the parent and plugin process to fix test failures.
- I've added an externallySetMinidumpPath boolean to keep track of whether to or not the crashReporter.minidumpPath has been set externally by a test. If it has, then let's use the externally set path for the test. 

I've pushed my most recent patch on phabricator: https://phabricator.services.mozilla.com/D36370
My most recent push to TRY: https://treeherder.mozilla.org/#/jobs?repo=try&revision=def246ee2a53c5adbd9dd3a2563a728179517150

This is the version with the least test failures (from few hundred down to less than 10 test failures): 

There are still 4 failing tests I'm aware of: 
- Windows 2012 build is failing because the test was not able to log "PROCESS CRASH". 
- There is another set of XPCshell X2 test failures: 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js and 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js
- An android Xpcshell test failure: toolkit/components/extensions/test/xpcshell/test_ext_webRequest_cached.js

These are my findings as of August 28, 2019. My internship ends on August 30, 2019. I plan to continue working on this after I receive volunteer contributor access. I'll be around in IRC and slack.
My patch moved the creation of the minidumps directory out of start-up. Instead we can create it lazily (in the content process). This change caused many test failures and I have attempted to fix these failures over the last several weeks. The test infrastructure heavily relies on the minidumps directory to be available at start-up.

While fixing this problem, I ran into several issues. I fixed a subset of tests to correctly find the minidump file, while there are other tests that will fail due to this fix. Some tests want to find the dump file in the "profile/minidumps" folder, while other tests want to find the dump file in "temp" directory. 

All the failing tests have a similar theme. The problem is that it cannot find the dump file in the directory it wants to find it. The directory where the dump file is created is inconsistent across different test suites. 

I've fixed most of the test failures by adding a few things:
- I've added creating it lazily in the parent and plugin process to fix test failures.
- I've added an externallySetMinidumpPath boolean to keep track of whether to or not the crashReporter.minidumpPath has been set externally by a test. If it has, then let's use the externally set path for the test. 

I've pushed my most recent patch on phabricator: https://phabricator.services.mozilla.com/D36370
My most recent push to TRY: https://treeherder.mozilla.org/#/jobs?repo=try&revision=def246ee2a53c5adbd9dd3a2563a728179517150

This is the version with the least test failures (from few hundred down to less than 10 test failures): 

There are 4 remaining test failures I'm aware of: 
- Windows 2012 build is failing because the test was not able to log "PROCESS CRASH". 
- There is another set of XPCshell X2 test failures: 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js and 
  - toolkit/crashreporter/test/unit/test_crash_with_memory_report.js
- An android Xpcshell test failure: toolkit/components/extensions/test/xpcshell/test_ext_webRequest_cached.js

These are my findings as of August 28, 2019. My internship ends on August 30, 2019. I plan to continue working on this after I receive volunteer contributor access. I'll be around in IRC and slack.

Back to Bug 1541603 Comment 10