1352047 - Crash in RtlEnterCriticalSection | mozilla::detail::MutexImpl::lock

Status: RESOLVED WONTFIX

(Core :: mozglue, defect)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is 
report bp-f78c8ced-afeb-4c45-a1ff-5ebae2170329.
=============================================================

Seen while looking at nightly crash data - crashes started using 20170329071901:  http://bit.ly/2oBQDXY

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5182b2c4b963ed87d038c7d9a4021463917076cd&tochange=6ea713ccc9abea93126423fefb855d0e051c95e2

ni on Nathan to see if he has any insight since he worked in mozglue.

Comment 1

[Nathan Froyd [:froydnj]]

Near-nullptr crashes in this code indicate problems at a higher level:

0 	ntdll.dll 	RtlEnterCriticalSection 	
1 	mozglue.dll 	mozilla::detail::MutexImpl::lock() 	mozglue/misc/Mutex_windows.cpp:42
2 	xul.dll 	nsTimerImpl::Cancel() 	xpcom/threads/nsTimerImpl.cpp:315
3 	xul.dll 	nsTimer::Release() 	xpcom/threads/nsTimerImpl.cpp:128
4 	xul.dll 	nsCOMPtr_base::~nsCOMPtr_base() 	obj-firefox/dist/include/nsCOMPtr.h:294
5 	xul.dll 	nsTimerImpl::Fire(int) 	xpcom/threads/nsTimerImpl.cpp:518

I suspect that the mozglue locking changes just moved this crash to a new signature, and didn't actually change anything else.  Byron, does this nullptr timer crash look familiar to you?

Comment 2

[Byron Campen [:bwc]]

Yep. You and I are already working on the fix.

Comment 3

[Julien Cristau [:jcristau] (back April 22)]

guessing "pthread_mutex_lock | mozilla::detail::MutexImpl::lock" is the MacOS variant of the same thing

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.