487999 - Firefox 3.0.8 on Windows hung after selecting link APPLICATION_HANG_DEADLOCK_CrossThreadBoundaryInDLLMain_cfffffff_npGoogleOneClick7.dll!DllMain

Status: RESOLVED INCOMPLETE

(External Software Affecting Firefox :: Other, defect)

Description

[Bryan Bach]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8

After loading the aforementioned web page (http://mail.google.com/videochat?hl=en) and then selecting the "Learn more »" link, Firefox crashes. It does not crash immediately after clicking the link but rather a few seconds afterward. But even though I may catch a glimpse of the page that this links to, session restore restores to the former page (if this makes sense).

The problem still manifests itself after a clearing of private data and in safe mode, but I cannot reproduce it after turning JavaScript off. Thus I believe that it is a JS-related issue.

However, I cannot reproduce it with the latest nightly (3.6a1pre) on Linux either (at the moment I'm unable to test the nightlies on Windows). Nor can I find any other website that triggers this problem (but I still don't think it's because of a broken web page).

Reproducible: Sometimes

Steps to Reproduce:
1. Open mentioned URL;
2. Click on "Learn more" link
3. Observe.
Actual Results:  
Firefox crashes, but not until a few seconds afterward.

Expected Results:  
Firefox should work perfectly and shouldn't crash.

Comment 1

[Kevin Brosnan]

Please type about:crashes in the address bar of Firefox. On that page there should be crash ids assuming the Mozilla Crash Reporter appeared and you submitted a report.

Comment 2

[Bryan Bach]

To the contrary; the Crash Reporter did not appear. Sorry for not stating that earlier.

Comment 3

[timeless]

https://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg

Comment 4

[Bryan Bach]

OK, here's what I get with 3.0.10pre.

1:001> g
ModLoad: 77420000 77429000   C:\Windows\system32\LPK.DLL
...
(fbc.110c): Break instruction exception - code 80000003 (first chance)
eax=7ffa9000 ebx=00000000 ecx=00000000 edx=7736d094 esi=00000000 edi=00000000
eip=77327dfe esp=06d8f8cc ebp=06d8f8f8 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!DbgBreakPoint:
77327dfe cc              int     3

At which point it hangs, and I select debug -> break.

1:018> kp
ChildEBP RetAddr  
06d8f8c8 7736d0d0 ntdll!DbgBreakPoint
06d8f8f8 76a54911 ntdll!DbgUiRemoteBreakin+0x3c
06d8f904 7731e4b6 kernel32!BaseThreadInitThunk+0xe
06d8f944 7731e489 ntdll!__RtlUserThreadStart+0x23
06d8f95c 00000000 ntdll!_RtlUserThreadStart+0x1b

I'm fairly certain that I'm doing something wrong--what do you think?

Also I should note that after selecting "go unhandled exception", Firefox starts to work as expected as though nothing had happened. I did try to run this nightly before debugging it, and it hangs as reported.

Comment 5

[timeless]

so, if it's actually hanging instead of crashing then you need to execute:

!analyze -v -hang

at the prompt once you break in.

note that comment 0 and comment 1 make no mention of "hang", they say "crash".

please make sure you're "debugging child processes" if you choose to run firefox from windbg. but in general, i'd merely attach windbg to firefox before trying to crash/hang it.

for crashes, you'll get an exception of some type other than breakpoint, and issue:
!analyze -v -f

for hangs, you'll have to debug>break yourself and then issue:
!analyze -v -hang

Comment 6

[Bryan Bach]

Attachment: windbg output

OK, hopefully this should be more helpful.

It says that the debugger isn't using the correct symbols. Not sure how to remedy that, as I did load the symbols as instructed in link in #3.

Comment 7

[timeless]

wow.

so, npGoogleOneClick7 seems to be Google Update. Please file a bug against google and provide the url for your report here.

the reason it says it's missing symbols is because we don't have symbols for third party plugins. if they happen to have a symbol server, you can add theirs and do more debugging, however i don't know of any such groups, so the best you can do is file a bug against the vendor (google), you should include this bug's url.

Comment 8

[Bryan Bach]

I posted the bug report as a question on the Google support forum linked below. Not sure if there's a better place for it.

http://www.google.com/support/forum/p/Chrome/thread?tid=7799750a6092585c&hl=en

Comment 9

[Benjamin Smedberg]

Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.