Open Bug 1788965 Opened 2 years ago Updated 2 years ago

src/xpcom/threads/BlockingResourceBase.cpp:221:26: runtime error: member call on null pointer of type 'mozilla::DeadlockDetector<mozilla::BlockingResourceBase>'

Categories

(Core :: XPCOM, defect)

defect

Tracking

()

People

(Reporter: tsmith, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: csectype-nullptr)

This was found by enabling the null check in UBSan. This issue is triggered on startup.

To enable this check add the following to your mozconfig:

ac_add_options --enable-undefined-sanitizer="null"
ac_add_options --enable-debug
src/xpcom/threads/BlockingResourceBase.cpp:221:26: runtime error: member call on null pointer of type 'mozilla::DeadlockDetector<mozilla::BlockingResourceBase>'
    #0 0x7fc360067e59 in mozilla::BlockingResourceBase::CheckAcquire() src/xpcom/threads/BlockingResourceBase.cpp:221:26
    #1 0x7fc360068daa in mozilla::OffTheBooksMutex::Lock() src/xpcom/threads/BlockingResourceBase.cpp:310:3
    #2 0x7fc35fb50aed in mozilla::StaticMutex::Lock() src/objdir-ff-ubsan/dist/include/mozilla/StaticMutex.h:38:51
    #3 0x7fc35fb50904 in mozilla::detail::BaseAutoLock<mozilla::StaticMutex&>::BaseAutoLock(mozilla::StaticMutex&) src/objdir-ff-ubsan/dist/include/mozilla/Mutex.h:236:11
    #4 0x7fc360dbef5a in mozilla::net::DumpLeakedURLs::~DumpLeakedURLs() src/netwerk/base/nsStandardURL.cpp:323:23
    #5 0x7fc3c0495030 in __run_exit_handlers /build/glibc-CVJwZb/glibc-2.27/stdlib/exit.c:108
    #6 0x7fc3c0495129 in exit /build/glibc-CVJwZb/glibc-2.27/stdlib/exit.c:139
    #7 0x7fc3c0473c8d in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:344
    #8 0x55e3af0ac538 in _start (src/objdir-ff-ubsan/dist/bin/firefox+0x393538) (BuildId: 2eadb9510f3d0ef4c13a864ece6bee99d46c35f2)

It looks like this is the DumpLeakedURLs checker. Kind of odd that you say this is on startup, because there's exit in the stacks. Maybe it is trying to acquire gAllURLsMutex after the mutex has been destroyed?

Given the line number, maybe BlockingResourceBase::CheckAcquire() needs a null check on sDeadlockDetector?

A Pernosco session is available here: https://pernos.co/debug/RefHc9rGpmjp0GCHqTWcwg/index.html

debug-only failure, so won't impact release users.

Severity: -- → S4
You need to log in before you can comment on or make changes to this bug.