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)
Core
XPCOM
Tracking
()
NEW
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)
Comment 1•2 years ago
|
||
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?
Comment 2•2 years ago
|
||
Given the line number, maybe BlockingResourceBase::CheckAcquire() needs a null check on sDeadlockDetector?
Reporter | ||
Comment 3•2 years ago
|
||
A Pernosco session is available here: https://pernos.co/debug/RefHc9rGpmjp0GCHqTWcwg/index.html
You need to log in
before you can comment on or make changes to this bug.
Description
•