Closed Bug 763723 Opened 12 years ago Closed 12 years ago

Exception in TableTicker::doBacktrace

Categories

(Core :: Gecko Profiler, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 767488

People

(Reporter: vladan, Assigned: ehsan.akhgari)

References

Details

Attachments

(1 file)

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
Assignee: nobody → ehsan
Attached patch Patch (v1)Splinter Review
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.
Attachment #635938 - Flags: review?(dbaron)
Comment on attachment 635938 [details] [diff] [review]
Patch (v1)

I don't understand.  myThread is the result of a DuplicateHandle() call.
Attachment #635938 - Flags: review?(dbaron) → review-
Hmm, Vladan, did you get this crash with my patch in bug 767488 applied?
(In reply to Ehsan Akhgari [:ehsan] from comment #3)
> Hmm, Vladan, did you get this crash with my patch in bug 767488 applied?
Flags: needinfo?(vdjeric)
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?
Flags: needinfo?(vdjeric)
(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.  ;-)
I think this crash was from a build without Ehsan's patch
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: