Closed Bug 1420947 Opened 7 years ago Closed 7 years ago

test_crash_win64cfi_ tests failing in Windows coverage builds

Categories

(Toolkit :: Crash Reporting, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: marco, Assigned: marco)

References

Details

(Keywords: leave-open)

Attachments

(2 files)

Attached file logs.zip (deleted) —
Gabriele, can you look into this? Or should we disable these tests in coverage builds? https://treeherder.mozilla.org/logviewer.html#?job_id=147592309&repo=try&lineNumber=3145
Flags: needinfo?(gsvelto)
Do ccov builds have crash reporting disabled? It looks like the test is unable to find the minidump it expects; if crash reporting is disabled then that would be the cause and the test should be disabled. I'm currently on PTO (forgot to update my status on bugzilla) but I can have a look on Friday. If this can't wait then disabled the tests and file a bug to re-enable them once I've figured out what's wrong.
Flags: needinfo?(gsvelto)
(In reply to Gabriele Svelto [:gsvelto] from comment #1) > Do ccov builds have crash reporting disabled? It looks like the test is > unable to find the minidump it expects; if crash reporting is disabled then > that would be the cause and the test should be disabled. Yes, it should be enabled (the other crash reporting tests are passing). The code coverage mozconfig is very similar to the debug one and it includes https://dxr.mozilla.org/mozilla-central/source/build/mozconfig.common, which has "ac_add_options --enable-crashreporter". > I'm currently on > PTO (forgot to update my status on bugzilla) but I can have a look on > Friday. If this can't wait then disabled the tests and file a bug to > re-enable them once I've figured out what's wrong. It can wait, I have a few other issues to fix in the meantime. To reproduce it, you would need to use a custom Clang build (5.0.0 doesn't support coverage on Windows). I could send the custom build to you if you want, or you can probably download it from one of the taskcluster tasks that builds our custom Clang.
Let's mark the tests as failing until they are fixed.
Attachment #8934159 - Flags: review?(jmaher)
Keywords: leave-open
Attachment #8934159 - Attachment description: Patch → Mark tests as failing until they are fixed
Attachment #8934159 - Flags: review?(jmaher) → review+
Pushed by mcastelluccio@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/71beb0f99752 Mark test_crash_win64cfi_* as failing on Windows coverage builds until they are fixed. r=jmaher
I should be able to take a look at this in the next few days, Marco can you point me to the clang build needed to reproduce this?
Flags: needinfo?(mcastelluccio)
(In reply to Gabriele Svelto [:gsvelto] from comment #6) > I should be able to take a look at this in the next few days, Marco can you > point me to the clang build needed to reproduce this? This one should work: https://queue.taskcluster.net/v1/task/S_SipaAYRPq3DO4NStydKw/runs/0/artifacts/public/build/clang.tar.bz2. If it doesn't, I can package my local build and share it somewhere. My mozconfig contains the following: > ac_add_options --disable-install-strip > ac_add_options --enable-optimize > ac_add_options --enable-debug > ac_add_options --enable-debug-symbols > ac_add_options --disable-sandbox > ac_add_options --enable-coverage > ac_add_options --with-libclang-path=C:/PATH/TO/CLANG/bin # maybe unneeded > ac_add_options --with-clang-path=C:/PATH/TO/CLANG/bin/clang.exe # maybe unneeded > ac_add_options --target=x86_64-pc-mingw32 > ac_add_options --host=x86_64-pc-mingw32 > export CC="clang-cl.exe" > export CXX="clang-cl.exe" > export CFLAGS="--coverage" > export CXXFLAGS="--coverage" > export LDFLAGS="C:/PATH/TO/CLANG/lib/clang/6.0.0/lib/windows/clang_rt.profile-x86_64.lib" # replace 6.0.0 with the correct version
Flags: needinfo?(mcastelluccio)
These tests fail in non-ccov clang-cl builds as well.
From looking at these filenames, I am guessing these crashes are _intended_ to happen? And the thing you're actually testing is how we deal with it? In that case my postmortem debugger is probably interfering. Sorry for the noise...
Let's ask Carl directly since he wrote those tests.
Flags: needinfo?(ccorcoran)
These are also failing on my local clang build; I will take a look Monday. I don't think postmortem debugger should affect these tests; more to come...
Flags: needinfo?(ccorcoran)
Blocks: 1447727
Depends on: 1449131
The uncommitted memory issue in comment 10 is fixed in bug 1449131, confirmed locally that it failed the test previously, and with the patch it now passes. The stack overflow in comment 9 I was not able to repro locally. But this would definitely make the test fail. The test intentionally crashes firefox, runs minidump-analyzer.exe on the generated minidump and checks the crashing stack trace to make sure we unwound the stack properly. This stack is going to fail the test. I wasn't able to repro it locally, but I'm curious how it behaves with the fix from 1449131.
With the patch for bug 1449131, these failures remain: TEST-UNEXPECTED-FAIL | toolkit/crashreporter/test/unit/test_crash_win64cfi_alloc_small.js | xpcshell return code: 0 TEST-UNEXPECTED-FAIL | toolkit/crashreporter/test/unit/test_crash_win64cfi_infinite_code_chain.js | xpcshell return code: 0 TEST-UNEXPECTED-FAIL | toolkit/crashreporter/test/unit/test_crash_win64cfi_invalid_exception_rva.js | xpcshell return code: 0 TEST-UNEXPECTED-FAIL | toolkit/crashreporter/test/unit/test_crash_win64cfi_not_a_pe.js | xpcshell return code: 0 TEST-UNEXPECTED-FAIL | toolkit/crashreporter/test/unit/test_crash_win64cfi_infinite_entry_chain.js | xpcshell return code: 0 Which I guess is all the same stack overflow as comment 9.
Depends on: 1449518
The two bugs that split off from this have fixed the issues. Thanks Carl!
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Assignee: nobody → mcastelluccio
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: