547136 - [OOPP] Hang up when activating a window by clicking a flash player

Status: RESOLVED DUPLICATE of bug 561495

(Core Graveyard :: Plug-ins, defect)

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

1. Open a page which has flash plug-in, e.g., http://www.google.com/finance?q=INDEXDJX:.DJI
2. Open a new window (e.g., open source viewer) and activate the new window.
3. Click the deactivated window's plug-in.

Then Fx is hung up. Maybe, after bug 538918, current trunk build's plug-in process is crashed after that.

I found this bug in at working on bug 483136. The cause may be when a message is dispatched in plug-in process and our process handles it, we send a DOM event to the plug-in via nsObjectFrame. I'm not sure the reason, but if we send a new event in bug 483136, this bug is created by the patch of bug 483136.

For suppressing that, the latest patch of bug 483136 calls ReplyMessage() before we dispatch a GUI event.

Comment 2

[Jim Mathies [:jimm]]

fwiw, WFM. I'm testing with the patch in bug 547142, but a trace shows there are no ime events being generated clicking back and forth.

Comment 3

[Benjamin Smedberg]

Masayuki, I don't understand this report exactly... is it about current mozilla-central behavior, or a behavior you see only with the patch in bug 483136?

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Wow, I cannot reproduce this bug on today's build (20100219043232).

(In reply to comment #2)
> fwiw, WFM. I'm testing with the patch in bug 547142, but a trace shows there
> are no ime events being generated clicking back and forth.

No, this report isn't related the IME events.

(In reply to comment #3)
> Masayuki, I don't understand this report exactly... is it about current
> mozilla-central behavior, or a behavior you see only with the patch in bug
> 483136?

It was the m-c build's behavior, sorry for confusing you by the additional information. We found this bug at testing the patch of bug 483136 (v5.1, comment 108, comment 113, comment 115 and from comment 117 to comment 121).

However, today's build might fix this bug. I cannot reproduce with the comment 1's steps. I'll check this with the patch of bug 483136, please wait.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

NG: 20100218045818 (35059e8e8ce8)
OK: 20100219043232 (78cf81cafcff)

I'm not sure which check-in fixes this bug.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 483136's patch

When I applied this patch, the mouse wheel event makes the hanging up. So, I guess that the actual cause has not been fixed yet.

This patch sends mouse wheel messages to the plug-in window. So, there is a bad thing that we can make the freeze bug easily.

Comment 7

[Jim Mathies [:jimm]]

(In reply to comment #6)
> Created an attachment (id=427880) [details]
> Bug 483136's patch
> 
> When I applied this patch, the mouse wheel event makes the hanging up. So, I
> guess that the actual cause has not been fixed yet.
> 
> This patch sends mouse wheel messages to the plug-in window. So, there is a bad
> thing that we can make the freeze bug easily.

Masayuki, any chance you could post a stack of the parent a child after the hang?

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Breaking by VS2008 after the debug build was frozen.

firefox.exe (main thread)

>  	ntdll.dll!77b900fd() 	
>  	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>  	ntdll.dll!77b900fd() 	
>  	KernelBase.dll!75eb0962() 	
>>	msvcr90d.dll!getenv(const char * option=0x5f12d5c0)  Line 85 + 0xc bytes	C
>  	nspr4.dll!_PR_MD_GET_ENV(const char * name=0x0026a8c4)  Line 49 + 0xa bytes	C
>  	0b653298()	
>  	nspr4.dll!_MD_CURRENT_THREAD()  Line 308 + 0xc bytes	C
>  	0026a7bc()	
>  	nspr4.dll!_MD_CURRENT_THREAD()  Line 308 + 0xc bytes	C
>  	nspr4.dll!PR_GetCurrentThread()  Line 175	C
>  	nspr4.dll!PR_GetThreadPrivate(unsigned int index=1595339968)  Line 232 + 0x5 bytes	C
>  	xul.dll!NS_LogRelease_P(void * aPtr=0xdddddddd, unsigned long aRefcnt=3722304989, const char * aClazz=0xdddddddd)  Line 1031 + 0x15 bytes	C++
>  	dddddddd()	

another thread 1:

>  	ntdll.dll!77b8f871() 	
>  	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>  	ntdll.dll!77b8f871() 	
>  	KernelBase.dll!75eb0816() 	
>>	nspr4.dll!_PR_MD_WAIT_CV(_MDCVar * cv=0x021cdec4, _MDLock * lock=0x021cddbc, unsigned int timeout=4294967295)  Line 280 + 0x14 bytes	C
>  	nspr4.dll!_PR_WaitCondVar(PRThread * thread=0x035eb4b0, PRCondVar * cvar=0x021cde50, PRLock * lock=0x021cdda0, unsigned int timeout=4294967295)  Line 204 + 0x17 bytes	C
>  	nspr4.dll!PR_WaitCondVar(PRCondVar * cvar=0x021cde50, unsigned int timeout=4294967295)  Line 547 + 0x17 bytes	C
>  	mozjs.dll!JSBackgroundThread::work()  Line 91 + 0xf bytes	C++
>  	mozjs.dll!start(void * arg=0x02207cd8)  Line 44	C++
>  	nspr4.dll!_PR_NativeRunThread(void * arg=0x035eb4b0)  Line 426 + 0xf bytes	C
>  	nspr4.dll!pr_root(void * arg=0x035eb4b0)  Line 122 + 0xf bytes	C
>  	msvcr90d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
>  	msvcr90d.dll!_threadstartex(void * ptd=0x035ed440)  Line 331	C
>  	kernel32.dll!76553677() 	
>  	ntdll.dll!77ba9d72() 	
>  	ntdll.dll!77ba9d45() 	

another thread 2:

>  	ntdll.dll!77b8f871() 	
>  	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>  	ntdll.dll!77b8f871() 	
>  	KernelBase.dll!75eb0816() 	
>>	nspr4.dll!_PR_MD_WAIT_CV(_MDCVar * cv=0x021ce184, _MDLock * lock=0x021ccd3c, unsigned int timeout=1000)  Line 280 + 0x14 bytes	C
>  	nspr4.dll!_PR_WaitCondVar(PRThread * thread=0x035ed090, PRCondVar * cvar=0x021ce110, PRLock * lock=0x021ccd20, unsigned int timeout=1000)  Line 204 + 0x17 bytes	C
>  	nspr4.dll!PR_WaitCondVar(PRCondVar * cvar=0x021ce110, unsigned int timeout=1000)  Line 547 + 0x17 bytes	C
>  	xul.dll!XPCJSRuntime::WatchdogMain(void * arg=0x021a7028)  Line 808 + 0x17 bytes	C++
>  	nspr4.dll!_PR_NativeRunThread(void * arg=0x035ed090)  Line 426 + 0xf bytes	C
>  	nspr4.dll!pr_root(void * arg=0x035ed090)  Line 122 + 0xf bytes	C
>  	msvcr90d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
>  	msvcr90d.dll!_threadstartex(void * ptd=0x035eb620)  Line 331	C
>  	kernel32.dll!76553677() 	
>  	ntdll.dll!77ba9d72() 	
>  	ntdll.dll!77ba9d45() 	

another thread 3:

>  	ntdll.dll!77b8f871() 	
>  	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>  	ntdll.dll!77b8f871() 	
>  	mswsock.dll!74d1727f() 	
>  	mswsock.dll!74d1678c() 	
>  	ws2_32.dll!75cb3508() 	
>  	ws2_32.dll!75cb302d() 	
>  	ws2_32.dll!75cb4a20() 	
>>	nspr4.dll!_PR_MD_PR_POLL(PRPollDesc * pds=0x03757358, int npds=2, unsigned int timeout=65535000)  Line 279 + 0x20 bytes	C
>  	nspr4.dll!PR_Poll(PRPollDesc * pds=0x03757358, int npds=2, unsigned int timeout=65535000)  Line 173 + 0x11 bytes	C
>  	xul.dll!nsSocketTransportService::Poll(int wait=1, unsigned int * interval=0x0407f710)  Line 355 + 0x12 bytes	C++
>  	xul.dll!nsSocketTransportService::DoPollIteration(int wait=1)  Line 660 + 0x10 bytes	C++
>  	xul.dll!nsSocketTransportService::OnProcessNextEvent(nsIThreadInternal * thread=0x0215d4b8, int mayWait=1, unsigned int depth=1)  Line 539 + 0xd bytes	C++
>  	xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0407f794)  Line 510	C++
>  	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0215d4b8, int mayWait=1)  Line 250 + 0x16 bytes	C++
>  	xul.dll!nsSocketTransportService::Run()  Line 581 + 0xb bytes	C++
>  	xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0407f82c)  Line 527 + 0x19 bytes	C++
>  	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0215d4b8, int mayWait=1)  Line 250 + 0x16 bytes	C++
>  	xul.dll!nsThread::ThreadFunc(void * arg=0x0215d4b8)  Line 254 + 0xb bytes	C++
>  	nspr4.dll!_PR_NativeRunThread(void * arg=0x03754858)  Line 426 + 0xf bytes	C
>  	nspr4.dll!pr_root(void * arg=0x03754858)  Line 122 + 0xf bytes	C
>  	msvcr90d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
>  	msvcr90d.dll!_threadstartex(void * ptd=0x03757dc8)  Line 331	C
>  	kernel32.dll!76553677() 	
>  	ntdll.dll!77ba9d72() 	
>  	ntdll.dll!77ba9d45() 	

another thread 4:

>  	ntdll.dll!77b900fd() 	
>  	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>  	ntdll.dll!77b900fd() 	
>  	KernelBase.dll!75eb0962() 	
>  	nsi.dll!77541c90() 	
>  	kernel32.dll!76551921() 	
>>	xul.dll!nsNotifyAddrListener::Run()  Line 191 + 0x10 bytes	C++
>  	xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x03f7f948)  Line 527 + 0x19 bytes	C++
>  	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0215d530, int mayWait=1)  Line 250 + 0x16 bytes	C++
>  	xul.dll!nsThread::ThreadFunc(void * arg=0x0215d530)  Line 254 + 0xb bytes	C++
>  	nspr4.dll!_PR_NativeRunThread(void * arg=0x03745ca0)  Line 426 + 0xf bytes	C
>  	nspr4.dll!pr_root(void * arg=0x03745ca0)  Line 122 + 0xf bytes	C
>  	msvcr90d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
>  	msvcr90d.dll!_threadstartex(void * ptd=0x03746468)  Line 331	C
>  	kernel32.dll!76553677() 	
>  	ntdll.dll!77ba9d72() 	
>  	ntdll.dll!77ba9d45() 	

another thread 5:

>  	ntdll.dll!77b8f871() 	
>  	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>  	ntdll.dll!77b8f871() 	
>  	KernelBase.dll!75eb0816() 	
>>	nspr4.dll!_PR_MD_WAIT_CV(_MDCVar * cv=0x0215e12c, _MDLock * lock=0x0215e024, unsigned int timeout=3460)  Line 280 + 0x14 bytes	C
>  	nspr4.dll!_PR_WaitCondVar(PRThread * thread=0x03768590, PRCondVar * cvar=0x0215e0b8, PRLock * lock=0x0215e008, unsigned int timeout=3460)  Line 204 + 0x17 bytes	C
>  	nspr4.dll!PR_WaitCondVar(PRCondVar * cvar=0x0215e0b8, unsigned int timeout=3460)  Line 547 + 0x17 bytes	C
>  	xul.dll!TimerThread::Run()  Line 344 + 0x11 bytes	C++
>  	xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0443fc48)  Line 527 + 0x19 bytes	C++
>  	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0215dc38, int mayWait=1)  Line 250 + 0x16 bytes	C++
>  	xul.dll!nsThread::ThreadFunc(void * arg=0x0215dc38)  Line 254 + 0xb bytes	C++
>  	nspr4.dll!_PR_NativeRunThread(void * arg=0x03768590)  Line 426 + 0xf bytes	C
>  	nspr4.dll!pr_root(void * arg=0x03768590)  Line 122 + 0xf bytes	C
>  	msvcr90d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
>  	msvcr90d.dll!_threadstartex(void * ptd=0x03768d58)  Line 331	C
>  	kernel32.dll!76553677() 	
>  	ntdll.dll!77ba9d72() 	
>  	ntdll.dll!77ba9d45() 	

another thread 6:

>  	ntdll.dll!77b8f871() 	
>  	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>  	ntdll.dll!77b8f871() 	
>  	KernelBase.dll!75eb0816() 	
>>	nspr4.dll!_PR_MD_WAIT_CV(_MDCVar * cv=0x04976d2c, _MDLock * lock=0x04976c24, unsigned int timeout=60000)  Line 280 + 0x14 bytes	C
>  	nspr4.dll!_PR_WaitCondVar(PRThread * thread=0x04a33668, PRCondVar * cvar=0x04976cb8, PRLock * lock=0x04976c08, unsigned int timeout=60000)  Line 204 + 0x17 bytes	C
>  	nspr4.dll!PR_Wait(PRMonitor * mon=0x04995c40, unsigned int ticks=60000)  Line 184 + 0x1d bytes	C
>  	xul.dll!nsAutoMonitor::Wait(unsigned int interval=60000)  Line 340 + 0x11 bytes	C++
>  	xul.dll!nsThreadPool::Run()  Line 211	C++
>  	xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x05a8fc7c)  Line 527 + 0x19 bytes	C++
>  	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x04a58568, int mayWait=1)  Line 250 + 0x16 bytes	C++
>  	xul.dll!nsThread::ThreadFunc(void * arg=0x04a58568)  Line 254 + 0xb bytes	C++
>  	nspr4.dll!_PR_NativeRunThread(void * arg=0x04a33668)  Line 426 + 0xf bytes	C
>  	nspr4.dll!pr_root(void * arg=0x04a33668)  Line 122 + 0xf bytes	C
>  	msvcr90d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
>  	msvcr90d.dll!_threadstartex(void * ptd=0x048f6ad8)  Line 331	C
>  	kernel32.dll!76553677() 	
>  	ntdll.dll!77ba9d72() 	
>  	ntdll.dll!77ba9d45() 	

mozilla-runtime.exe (main thread):

>  	ntdll.dll!77b8f8f9() 	
>  	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>  	ntdll.dll!77b8f8f9() 	
>  	KernelBase.dll!75ea76bc() 	
>>	msvcr90d.dll!operator new(unsigned int size=5)  Line 59 + 0x9 bytes	C++
>  	mozilla-runtime.exe!wmain(int argc=6, wchar_t * * argv=0x006ff9b8)  Line 120 + 0xd bytes	C++
>  	mozilla-runtime.exe!__tmainCRTStartup()  Line 583 + 0x19 bytes	C
>  	mozilla-runtime.exe!wmainCRTStartup()  Line 403	C
>  	kernel32.dll!76553677() 	
>  	ntdll.dll!77ba9d72() 	
>  	ntdll.dll!77ba9d45() 	
>  	nss3.dll!pkix_Build_InitiateBuildChain(PKIX_ProcessingParamsStruct * procParams=0x94000000, void * * pNBIOContext=0x30000003, PKIX_ForwardBuilderStateStruct * * pState=0x00000003, PKIX_BuildResultStruct * * pBuildResult=0x44000000, PKIX_VerifyNodeStruct * * pVerifyNode=0xc4b12805, void * plContext=0x56000006)  Line 3590 + 0x30 bytes	C
>  	42000003()	

another thread:

>  	user32.dll!763a723b() 	
>  	[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]	
>  	user32.dll!763a723b() 	
>  	user32.dll!763b1c01() 	
>  	uxtheme.dll!751c6e9f() 	
>  	NPSWF32.dll!6a109208() 	
>  	NPSWF32.dll!6a107340() 	
>  	user32.dll!763a6238() 	
>  	user32.dll!763a68ea() 	
>  	user32.dll!763a6899() 	
>  	kernel32.dll!7655442e() 	
>  	user32.dll!763b0ad6() 	
>>	xul.dll!mozilla::plugins::PluginInstanceChild::PluginWindowProc(HWND__ * hWnd=0x00020cd2, unsigned int message=522, unsigned int wParam=4293001216, long lParam=46595525)  Line 736 + 0x1d bytes	C++
>  	user32.dll!763a6238() 	
>  	user32.dll!763a68ea() 	
>  	user32.dll!763a6899() 	
>  	user32.dll!763a7d31() 	
>  	user32.dll!763a7dfa() 	
>  	xul.dll!base::MessagePumpForUI::ProcessMessageHelper(const tagMSG & msg={...})  Line 364	C++
>  	xul.dll!base::MessagePumpForUI::ProcessNextWindowsMessage()  Line 336 + 0xc bytes	C++
>  	xul.dll!base::MessagePumpForUI::DoRunLoop()  Line 205 + 0x8 bytes	C++
>  	xul.dll!base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate * delegate=0x02c9f71c, base::MessagePumpWin::Dispatcher * dispatcher=0x00000000)  Line 54	C++
>  	xul.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate=0x02c9f71c)  Line 78 + 0x15 bytes	C++
>  	xul.dll!MessageLoop::RunInternal()  Line 217	C++
>  	xul.dll!MessageLoop::RunHandler()  Line 193	C++
>  	xul.dll!MessageLoop::Run()  Line 174	C++
>  	xul.dll!base::Thread::ThreadMain()  Line 168	C++
>  	xul.dll!`anonymous namespace'::ThreadFunc(void * closure=0x00d795f0)  Line 27	C++
>  	kernel32.dll!76553677() 	
>  	ntdll.dll!77ba9d72() 	
>  	ntdll.dll!77ba9d45()

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Ah, sorry, this should be marked as WFM. We're unlocking the child process when we receive the messages.

-> WFM.

Comment 10

[Daniel Veditz [:dveditz]]

Is that WFM on the 1.9.2 branch as well?

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yes, the comment #0's problem was WFM at comment 4. And the remains in comment 4 are gone by bug 561495, the cause messages unlock the process always.