At the moment it appears we are only getting ASan logs from content process crashes and not parent process crashes on Windows.

The simplest way I've found to reproduce this is using FFPuppet (automatically setup the env and profile). This method works (we get ASan logs as expected) on Linux and MacOS.

This can obviously be done without using FFPuppet but I can't get Firefox to dump logs to the file system consistently otherwise :(

STR:

1. Install FFPuppet and get an ASan build
2. Launch the browser python -m ffpuppet -d <path_to_firefox>
3. Navigate to about:crashparent

Expected results:

• An ASan log should be present in the output

Actual results:

• Windows 10 1909: No ASan logs are present.
• Linux & MacOS: ASan logs are present.

Bonus points:
To make this even more exciting opening about:crashcontent on Windows only provides output after navigating to a page.
to summarize...

• about:crashcontent in newtab -> no output
• about:crashcontent after navigating to page -> asan log
• about:crashparent -> no output ever!

Hey Bob, do you have any thoughts on this?

(In reply to Tyson Smith [:tsmith] from comment #1)

Hey Bob, do you have any thoughts on this?

I don't I'm afraid, particularly odd it's the parent.
The only thing I can think of, is could the launcher process be affecting it somehow, I think you can disable it.
But that wouldn't really explain why content works in some circumstances.

Could you elaborate on what the repro would look like without FFPuppet? And what "An ASan log should be present in the output" looks like?

(In reply to :dmajor from comment #3)

Could you elaborate on what the repro would look like without FFPuppet? And what "An ASan log should be present in the output" looks like?

Of course. To repro launch the browser from the command line and with default ASAN_OPTIONS[1] (log_path=stderr) the output should appear in the console window. The output should be an ASan stack trace.

Here is an example of what I see on Linux when I visit about:crashparent

$ ~/workspace/browsers/m-c-20191202115917-fuzzing-asan-opt/firefox
AddressSanitizer:DEADLYSIGNAL
=================================================================
==8349==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7fc0757bf4e5 bp 0x7fff0a2da630 sp 0x7fff0a2da520 T0)
==8349==The signal is caused by a WRITE memory access.
==8349==Hint: address points to the zero page.
    #0 0x7fc0757bf4e4 in CrashChannel::OpenContentStream(bool, nsIInputStream**, nsIChannel**) /builds/worker/workspace/build/src/docshell/base/nsAboutRedirector.cpp:39:7
    #1 0x7fc0696c26f7 in nsBaseChannel::BeginPumpingData() /builds/worker/workspace/build/src/netwerk/base/nsBaseChannel.cpp:230:8
...

[1] https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

Ok, I think I have an idea of what's going on. The code that produces the log is implemented with a SetUnhandledExceptionFilter on Windows. Since there is JIT code on the stack during CrashChannel::OpenContentStream, this is bug 844196 all over again: the Windows unwinder can't reach the exception filter. Except in this case, our workaround from bug 844196 never got installed, because these ASan builds have --disable-crashreporter.

Later this week I'll try and see if we can at least plumb through some minimal JitExceptionHandler initialization into nsDummyExceptionHandler.

This turned out to be not as straightforward as I thought. (If I had a nickel for every time...) Even with the JitExceptionHandler in place, NT still isn't calling ASan's SEHHandler. I'll need to debug more deeply but it's going to take some time.

Is this still an issue?

This appears to be working correctly now.