763723 - Exception in TableTicker::doBacktrace

Status: RESOLVED DUPLICATE of bug 767488

(Core :: Gecko Profiler, defect)

Description

[Vladan Djeric (:vladan)]

Note: The caller of NS_StackWalk had the thread ID set to = 1348, which does not correspond to any of the threads.

-----
Stack:
 	ntdll.dll!_ZwRaiseException@12()  + 0x12 bytes	
 	ntdll.dll!_ZwRaiseException@12()  + 0x12 bytes	
 	ntdll.dll!_NtClose@4()  + 0x12 bytes	
 	kernel32.dll!_CloseHandleImplementation@4()  + 0x28 bytes	
>	xul.dll!TableTicker::doBacktrace(ThreadProfile & aProfile={...}, TickSample * aSample=0x1737f804)  Line 498 + 0x17 bytes	C++
 	xul.dll!TableTicker::Tick(TickSample * sample=0x1737f804)  Line 624	C++
 	xul.dll!SamplerThread::SampleContext(Sampler * sampler=0x0a313240)  Line 106	C++
 	xul.dll!SamplerThread::Run()  Line 69	C++
 	xul.dll!ThreadEntry(void * arg=0x0a3132b0)  Line 152	C++
 	msvcr90d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
 	msvcr90d.dll!_threadstartex(void * ptd=0x0a313aa0)  Line 331	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	

-----
Threads:

0	 	1208	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	1636	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	1644	Main Thread	Main Thread	_LongCompareString@4	Normal	1
0	 	2996	Worker Thread	_threadstartex	mozilla::TimeDuration::ToSeconds	Normal	0
0	 	3700	Worker Thread	CDeviceEnumerator::PnpNotificationThreadWrapper	_ZwWaitForMultipleObjects@20	Normal	0
0	 	5452	Worker Thread	_SockAsyncThread@4	_ZwRemoveIoCompletion@20	Above Normal	0
0	 	6416	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	6696	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	6796	Worker Thread	_EtwpNotificationThread@4	_ZwTraceControl@24	Normal	0
0	 	7032	Worker Thread	_threadstartex	_PR_MD_PR_POLL	Normal	0
0	 	7352	Worker Thread	_threadstartex	nsNotifyAddrListener::Run	Normal	0
0	 	7472	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	>	7476	Worker Thread	_threadstartex	TableTicker::doBacktrace	Normal	0
0	 	7864	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Below Normal	0
0	 	8076	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	8280	Worker Thread	_TppWorkerThread@4	_NtWaitForWorkViaWorkerFactory@8	Normal	0
0	 	8500	Worker Thread	_threadstartex	WalkStackThread	Normal	0
0	 	8900	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	9040	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	9272	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	9528	Worker Thread	_threadstartex	nsDownloadScannerWatchdog::WatchdogThread	Normal	0
0	 	9840	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	10584	Worker Thread	Gecko_IOThread	base::MessagePumpForIO::WaitForIOCompletion	Normal	0
0	 	10724	Worker Thread	_TppWaiterpThread@4	_ZwWaitForMultipleObjects@20	Normal	0
0	 	10756	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	10780	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	10828	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	10876	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0
0	 	11104	Worker Thread	_TppWorkerThread@4	_NtWaitForWorkViaWorkerFactory@8	Normal	0
0	 	11120	Worker Thread	_threadstartex	_PR_MD_WAIT_CV	Normal	0

Comment 1

[(no longer active)]

Attachment: Patch (v1)

So turns out that NS_StackWalk unconditionally closes its thread handle, and if we pass in the thread handle from outside via aThread, the handle will be closed after the first call to NS_StackWalk.  I guess Windows manages to handle the case where we use this closed handle some of the time, but this should be fixed regardless.

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 635938 [details] [diff] [review]
Patch (v1)

I don't understand.  myThread is the result of a DuplicateHandle() call.

Comment 3

[(no longer active)]

Hmm, Vladan, did you get this crash with my patch in bug 767488 applied?

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to Ehsan Akhgari [:ehsan] from comment #3)
> Hmm, Vladan, did you get this crash with my patch in bug 767488 applied?

Comment 5

[Vladan Djeric (:vladan)]

I don't have the crashing profile anymore so I don't know which build this was happening in, but I think I might have discussed this crash with Ehsan in-person.. Maybe Ehsan remembers the details better?

Comment 6

[(no longer active)]

(In reply to comment #5)
> I don't have the crashing profile anymore so I don't know which build this was
> happening in, but I think I might have discussed this crash with Ehsan
> in-person.. Maybe Ehsan remembers the details better?

Sorry, my memory should not be trusted past a day or two.  ;-)

Comment 7

[Vladan Djeric (:vladan)]

I think this crash was from a build without Ehsan's patch