1396365 - Crash in RacyThreadInfo::`scalar deleting destructor''

Status: RESOLVED WONTFIX

(Core :: Gecko Profiler, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-daa41fde-bbc1-4e8e-a579-f9a970170902.
=============================================================
Crashing Thread (6), Name: Socket Thread
Frame 	Module 	Signature 	Source
0 	xul.dll 	RacyThreadInfo::`scalar deleting destructor'(unsigned int) 	
1 	xul.dll 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp:543
2 	nss3.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:397
3 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:95
4 	ucrtbase.dll 	thread_start<unsigned int (__stdcall*)(void*)> 	
5 	kernel32.dll 	BaseThreadInitThunk 	
6 	mozglue.dll 	patched_BaseThreadInitThunk 	mozglue/build/WindowsDllBlocklist.cpp:815
7 	ntdll.dll 	__RtlUserThreadStart 	
8 	ntdll.dll 	_RtlUserThreadStart

crash reports with this signature are showing up since firefox 55 and to a greater extend during the 56.0b cycle. they are coming from windows users and all have MOZ_RELEASE_ASSERT(stackPointer == 0) that got added in bug 1366650.

Comment 1

[Nicholas Nethercote [inactive]]

> crash reports with this signature are showing up since firefox 55 and to a
> greater extend during the 56.0b cycle. they are coming from windows users
> and all have MOZ_RELEASE_ASSERT(stackPointer == 0) that got added in bug
> 1366650.

Bug 1366650 just moved this assertion and slightly changed it; it was MOZ_RELEASE_ASSERT(mStackPointer == 0) before that. So that bug isn't relevant.

Here's a crash I found with the old version:

https://crash-stats.mozilla.com/report/index/6fd71a1c-2ba5-440e-9047-560410170828

I see them going back to Firefox 54, but not before that.

The assertion is here: http://searchfox.org/mozilla-central/rev/67f38de2443e6b613d874fcf4d2cd1f2fc3d5e97/js/public/ProfilingStack.h#215-217. The comment suggests we might have a problem with a profiler label.

Comment 2

[Nicholas Nethercote [inactive]]

mstange, I wonder if this could be related to some of the prep work you've done for bug 785440?

Comment 3

[Markus Stange [:mstange]]

None of that work has landed.

It's worrying that we seem to have leftover pseudo stack frames on the thread when it's destroyed.
The name of the crashing thread is "Socket Thread" according to many of the crash reports. It gets created here: http://searchfox.org/mozilla-central/rev/67f38de2443e6b613d874fcf4d2cd1f2fc3d5e97/netwerk/base/nsSocketTransportService2.cpp#560

It's a regular nsThread which just runs Runnables; it doesn't have a custom thread func or anything, and as far as I know, it also doesn't run any JavaScript. So I'm a bit stumped how it could end up with unbalanced profiler labels.

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.