563851 - Crash - Quicktime - also prevents left click on form fields to fill out BR

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Rob]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100502 Namoroka/3.6.5pre ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100502 Namoroka/3.6.5pre ( .NET CLR 3.5.30729)

On page http://folding.stanford.edu/English/FAQ-ATI2 there is an URL link to http://fah-web.stanford.edu/movies/gpu2-viewer.avi that causes the 'Plug-in Crash' page to be displayed. Quicktime worked last week, though I have never been to that particular page previously.

When I load that URL my Firewall prompts to allow the Plug-in_container.exe .


On _my_ System, when I load that URL I get a 'Quicktime Pop-up' that says it must fetch a Codec to play the video. I downloaded and saved that ".avi", then I loaded it into 'GSpot"; it needs an XVID Codec and reports that I have "XviD 1.1.2 Final" already installed. 

I can play the video (without Firefox) without using any downloaded Codecs in VirtualDub (which uses the System's XVID Codec) but if I use my installed Quicktime it too says it needs the plug-in but then takes me to the Mac-OS download Page :( .



Reproducible: Always

Steps to Reproduce:
1. Install Xvid -- http://www.xvid.org/Downloads.15.0.html
2. Install Quicktime -- http://www.apple.com/quicktime/download/
3. Visit http://fah-web.stanford.edu/movies/gpu2-viewer.avi


Actual Results:  
The Quicktime Player Plug-in activates our 'Plug-in Crash' page.

I send the report and retry the URL.


After the Quicktime Crash, when I come to __this__ Website I can NOT left-click on a "Form Field" to enter a 'Search Term' or type info into a Bug Report. I must restart Namoroka to enter the BR.



Expected Results:  
_NO_ Plug-in should take anything with it when it crashes. It is ?weird? that this Crash causes Form Fields to be inaccessible, it seems an "odd leak" of one Bug into another portion of the Program that causes an effect that is not easily noticed (you would need to click on a Field).



I did read https://developer.mozilla.org/En/How_to_get_a_stacktrace_with_windbg and did the Installation but I am unsure about how I would go about getting the "Plug-in_container.exe" to load into the Debugger since it is called from Firefox (the loading of FF into the Debugger (while complex) seems within my abilities).

Comment 1

[timeless]

it sounds like you're hitting a hang between the two processes. if the instructions here work, then don't worry about windbg:

https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report

if they don't, just following the instructions in the windbg url should do the right thing. it's supposed to automatically catch the plugin container as it goes if you debug firefox.exe

Comment 2

[Rob]

Attachment: Windbg Log 1 - 2010-05-06 19:49:36

timeless, here it is. It crashes (now) well before it even loads. I don't know much about this but I'd guess the problem is here:


Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: "C:\Program Files\Namoroka\firefox.exe"
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
ModLoad: 00400000 00418000   firefox.exe
ModLoad: 7c900000 7c9b2000   ntdll.dll
ModLoad: 7c800000 7c8f5000   C:\WINDOWS\system32\kernel32.dll
...
0:000> .sympath SRV*c:\symbols*http://symbols.mozilla.org/firefox
Symbol search path is: SRV*c:\symbols*http://symbols.mozilla.org/firefox
0:000> .symfix+ c:\symbols
0:000> .reload /f
Reloading current modules
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\sqlite3.dll
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\js3250.dll
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\plc4.dll
.*** WARNING: Unable to verify checksum for firefox.exe
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\nspr4.dll
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\smime3.dll
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\nss3.dll
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\nssutil3.dll
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\plds4.dll
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\ssl3.dll
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\xpcom.dll
.*** WARNING: Unable to verify checksum for C:\Program Files\Namoroka\xul.dll


I just updated a few minutes ago and only a few files are not checksumming.

Rob

Comment 3

[Rob]

Attachment: Windbg Log 2 - 2010-05-06 20:57:02

Please remember _this_ BR is NOT about whether the Quicktime Plug-in actually works, it is about it crashing us, and making the click-on-form-field broken.


I cut and pasted the commands and tried 5 times with the same result, the Debugging had the previously described difficulties.

The next time I tried I got a pop-up saying that the "NASA Night Launch" Theme had been updated, I installed it and restarted. Now it (WinDbg) works for some reason.


THIS time the behavior is a little different than first reported.

This time if I go through the "Reporter" and reload the Page I get a "QuickTime Pop-up" saying I need the Plug-in (which I already have). I dismiss the Pop-up and a 'White Video' downloads very quickly and plays nothing (but a white picture) __without__ crashing again. I exited and saved the Report.

Here is the Log. 

Rob

Comment 4

[timeless]

:(.

each time you see something like this (the question marks can be anything):
???????? cc              int     3
?:???>

you need to use 'g'

you're only going to switch to "|* ~* kp" and continue steps when you get something that does not look like that. i'm still working on improving the instructions, sorry.

Comment 5

[Rob]

(In reply to comment #4)
> :(.  each time you see something like ...
> you need to use 'g'
> 
Got it working, Windbg that is. With or without it, the Bug is (at this moment), not similar enough to this BR to continue this report. This BR may have been partially fixed in another BR or someone may have backed out some breakage.

I'll close in a few days if it will not reoccur.


Thanks for your help, useful for future Reports,
Rob

Comment 6

[Rob]

Attachment: Windbg Log 3 - 2010-05-16 17:33:31

(In reply to comment #1)
> it sounds like you're hitting a hang between the two processes. if the
> instructions here work, then don't worry about windbg:
> 
> https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report
> 
> if they don't, just following the instructions in the windbg url should do the
> right thing. it's supposed to automatically catch the plugin container as it
> goes if you debug firefox.exe

As a point of interest the "Error Pop-up" depicted on that Webpage (the "usuak one") is NOT the sort of "Error Pop-up" I am getting - it is 'inside the container'.


Here is where it occurred in the Log:

...
ModLoad: 67500000 675db000   C:\Program Files\QuickTime\QTSystem\QuickTimeVR.qtx
ModLoad: 77920000 77a13000   C:\WINDOWS\system32\SETUPAPI.dll
ModLoad: 4fdd0000 4ff76000   C:\WINDOWS\system32\d3d9.dll
ModLoad: 6d990000 6d996000   C:\WINDOWS\system32\d3d8thk.dll
ModLoad: 4fdd0000 4ff76000   C:\WINDOWS\system32\d3d9.dll
ModLoad: 6d990000 6d996000   C:\WINDOWS\system32\d3d8thk.dll
ModLoad: 76ee0000 76f1c000   C:\WINDOWS\system32\RASAPI32.dll
ModLoad: 76e90000 76ea2000   C:\WINDOWS\system32\rasman.dll
ModLoad: 5b860000 5b8b4000   C:\WINDOWS\system32\NETAPI32.dll
ModLoad: 76eb0000 76edf000   C:\WINDOWS\system32\TAPI32.dll
ModLoad: 76e80000 76e8e000   C:\WINDOWS\system32\rtutils.dll
(e54.b28): Unknown exception - code 00000005 (first chance)
ModLoad: 71e50000 71e65000   C:\WINDOWS\system32\msapsspc.dll
ModLoad: 78080000 78091000   C:\WINDOWS\system32\MSVCRT40.dll
ModLoad: 767f0000 7681d000   C:\WINDOWS\system32\schannel.dll
ModLoad: 769c0000 76a73000   C:\WINDOWS\system32\USERENV.dll
...


Thanks,
Rob

Comment 7

[timeless]

this isn't good:
> HEAP[firefox.exe]: HEAP: Free Heap block a600040 modified at a60a08c after it was freed
> (1284.1570): Break instruction exception - code 80000003 (first chance)

Ok, so slightly change of instructions.

generally, instead of 'g', do 'kp; g'

as soon as you see either something like the above 'Free Heap block ... modified ... after it was freed' or

> (e54.b28): Unknown exception - code 00000005 (first chance)

Change to:

'|* ~* kp; !analayze -v -f; g'

Comment 8

[Rob]

This BR is for "Namoroka/3.6.5pre" and over 6 months old, CLOSED.

Rob

Comment 9

[Wayne Mery (:wsmwk)]

rob, thanks for updating the bug.
HOwever, please use WORKSFORME rather than FIXED when it's not known what patch or other bug fixed the issue. see definitions at https://bugzilla.mozilla.org/page.cgi?id=fields.html#status