Open Bug 1391511 Opened 7 years ago Updated 2 years ago

ASan reports access-violation on unknown address 0x0 in MOZ_NoReturn

Categories

(Core :: MFBT, defect)

Product:
Core
Component:
MFBT
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox57 --- affected

People

(Reporter: ting, Unassigned)

References

Details

=================================================================
==5880==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000000 (pc 0x7ff98de6b38d bp 0x126122939d28 sp 0x002b489ff6a0 T16777215)
==5880==The signal is caused by a WRITE memory access.
==5880==Hint: address points to the zero page.
=================================================================
==10748==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000000 (pc 0x7ff95b19d37c bp 0x0076eb3feed0 sp 0x0076eb3fed90 T16777215)

==10748==Hint: address points to the zero page. access.

ting@ting-pc /c/w/fx/mc
$     #0 0x7ff98de6b38c in MOZ_NoReturn c:\w\fx\mc\obj-asan\dist\include\mozilla\Assertions.h:213
    #1 0x7ff98de848ee in MOZ_CrashOOL c:\w\fx\mc\mfbt\Assertions.cpp:33
    #2 0x7ff950fa843c in nsAutoOwningThread::AssertCurrentThreadOwnsMe c:\w\fx\mc\xpcom\base\nsISupportsImpl.cpp:43
    #3 0x7ff95b15781d in mozilla::ExtensionPolicyService::Release c:\w\fx\mc\toolkit\components\extensions\ExtensionPolicyService.cpp:412
    #4 0x7ff991de8672 in o__execute_onexit_table+0xd2 (C:\WINDOWS\System32\ucrtbase.dll+0x180008672)
    #5 0x7ff991dec126 in register_onexit_function+0xe6 (C:\WINDOWS\System32\ucrtbase.dll+0x18000c126)
    #6 0x7ff991de877d in execute_onexit_table+0x3d (C:\WINDOWS\System32\ucrtbase.dll+0x18000877d)
    #7 0x7ff95ddd952d in dllmain_crt_process_detach f:\dd\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp:107
    #8 0x7ff95ddd9623 in dllmain_dispatch f:\dd\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp:207
    #9 0x7ff99501485e in RtlDeactivateActivationContextUnsafeFast+0x1ae (C:\WINDOWS\SYSTEM32\ntdll.dll+0x18002485e)
    #10 0x7ff99503d43b in LdrShutdownProcess+0x12b (C:\WINDOWS\SYSTEM32\ntdll.dll+0x18004d43b)
    #11 0x7ff99503d2f3 in RtlExitUserProcess+0xb3 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x18004d2f3)
    #12 0x7ff9921771de in CtrlRoutine+0xfe (C:\WINDOWS\System32\KERNELBASE.dll+0x1800071de)
    #13 0x7ff99217717c in CtrlRoutine+0x9c (C:\WINDOWS\System32\KERNELBASE.dll+0x18000717c)
    #14 0x7ff994d92773 in BaseThreadInitThunk+0x13 (C:\WINDOWS\System32\KERNEL32.DLL+0x180012773)
    #15 0x7ff995060d50 in RtlUserThreadStart+0x20 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x180070d50)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: access-violation c:\w\fx\mc\obj-asan\dist\include\mozilla\Assertions.h:213 in MOZ_NoReturn
==5880==ABORTING
    #0 0x7ff95b19d37b in MOZ_NoReturn c:\w\fx\mc\obj-asan\dist\include\mozilla\Assertions.h:213
    #1 0x7ff951e278af in mozilla::ipc::MessageChannel::AssertWorkerThread c:\w\fx\mc\obj-asan\dist\include\mozilla\ipc\MessageChannel.h:533
    #2 0x7ff951e28602 in mozilla::ipc::MessageChannel::CxxStackFrame::CxxStackFrame c:\w\fx\mc\ipc\glue\MessageChannel.cpp:246
    #3 0x7ff951e2808c in mozilla::ipc::MessageChannel::Send c:\w\fx\mc\ipc\glue\MessageChannel.cpp:888
    #4 0x7ff951ec0952 in mozilla::layers::PAPZParent::SendDestroy c:\w\fx\mc\obj-asan\ipc\ipdl\PAPZParent.cpp:254
    #5 0x7ff9533681dd in mozilla::layers::RemoteContentController::Destroy c:\w\fx\mc\gfx\layers\ipc\RemoteContentController.cpp:355
    #6 0x7ff95336f3fb in mozilla::layers::CompositorBridgeParent::LayerTreeState::~LayerTreeState c:\w\fx\mc\gfx\layers\ipc\CompositorBridgeParent.cpp:216
    #7 0x7ff95336f293 in std::_Tree<std::_Tmap_traits<unsigned long long,mozilla::layers::CompositorBridgeParent::LayerTreeState,std::less<unsigned long long>,std::allocator<std::pair<const unsigned long long,mozilla::layers::CompositorBridgeParent::LayerTreeState> >,0> >::_Erase c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xtree:2037
    #8 0x7ff95336958a in std::_Tree<std::_Tmap_traits<unsigned long long,mozilla::layers::CompositorBridgeParent::LayerTreeState,std::less<unsigned long long>,std::allocator<std::pair<const unsigned long long,mozilla::layers::CompositorBridgeParent::LayerTreeState> >,0> >::erase c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xtree:1456
    #9 0x7ff95331b6d3 in mozilla::layers::CompositorBridgeParent::LayerTreeState::LayerTreeState c:\w\fx\mc\obj-asan\gfx\layers\Unified_cpp_gfx_layers8.cpp:221
    #10 0x7ff991de8672 in o__execute_onexit_table+0xd2 (C:\WINDOWS\System32\ucrtbase.dll+0x180008672)
    #11 0x7ff991dec126 in register_onexit_function+0xe6 (C:\WINDOWS\System32\ucrtbase.dll+0x18000c126)
    #12 0x7ff991de877d in execute_onexit_table+0x3d (C:\WINDOWS\System32\ucrtbase.dll+0x18000877d)
    #13 0x7ff95ddd952d in dllmain_crt_process_detach f:\dd\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp:107
    #14 0x7ff95ddd9623 in dllmain_dispatch f:\dd\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp:207
    #15 0x7ff99501485e in RtlDeactivateActivationContextUnsafeFast+0x1ae (C:\WINDOWS\SYSTEM32\ntdll.dll+0x18002485e)
    #16 0x7ff99503d43b in LdrShutdownProcess+0x12b (C:\WINDOWS\SYSTEM32\ntdll.dll+0x18004d43b)
    #17 0x7ff99503d2f3 in RtlExitUserProcess+0xb3 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x18004d2f3)
    #18 0x7ff9921771de in CtrlRoutine+0xfe (C:\WINDOWS\System32\KERNELBASE.dll+0x1800071de)
    #19 0x7ff99217717c in CtrlRoutine+0x9c (C:\WINDOWS\System32\KERNELBASE.dll+0x18000717c)
    #20 0x7ff994d92773 in BaseThreadInitThunk+0x13 (C:\WINDOWS\System32\KERNEL32.DLL+0x180012773)
    #21 0x7ff995060d50 in RtlUserThreadStart+0x20 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x180070d50)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: access-violation c:\w\fx\mc\obj-asan\dist\include\mozilla\Assertions.h:213 in MOZ_NoReturn
==10748==ABORTING
This error seems too aggressive (and unhelpful), since we deliberately want to crash and go through the standard (not ASan's) access-violation path.

I think we should mark MOZ_NoReturn with MOZ_ASAN_BLACKLIST.
(In reply to David Major [:dmajor] from comment #1)
> This error seems too aggressive (and unhelpful), since we deliberately want
> to crash and go through the standard (not ASan's) access-violation path.
> 
> I think we should mark MOZ_NoReturn with MOZ_ASAN_BLACKLIST.

This solution seems reasonable...but will this cause problems for fuzzing?  ni? someone on the fuzzing team to ask.

Alternatively, does ASan provide functions for controlled crashing?  We could use those instead.
Flags: needinfo?(choller)
On second thought maybe I'm looking at this on the wrong level.

We've chosen to bring down the process, and if that's blocking asan testing then it's going to be a blocker anyway even if it had been a vanilla crash.

Ideally we'd fix the root cause (the asserts firing) and then the question of what specific form a null-deref takes becomes moot.
I don't entirely understand the report, but it looks like maybe we're doing an exit and then running destructors on some random thread (maybe even the main thread) via execute_onexit_table, and then hitting thread safety assertions in multiple places.
These kind of crashes should not be blacklisted. If we crash, then we need ASan then to get a proper stack in ASan fuzzing. As David pointed out in comment 3, turning this into a vanilla crash does not improve the situation for testing (it actually makes things worse because we don't have any crash information then).

Fixing the root cause is probably the correct solution here and it seems like Andrew already has an idea what's going on.
Flags: needinfo?(choller)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.