779657 - [adbe 3301025] Flash hang in F_1152915508 on Nasa upstream live

Status: RESOLVED INCOMPLETE

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Summary: Crash in [@ hang | WaitForMultipleObjectsEx | RealMsgWaitForMultipleObjectsEx] while transitioning from Olympics live stream -> ads

Flash version:

File: NPSWF32_11_3_300_268.dll
Version: 11.3.300.268
Shockwave Flash 11.3 r300

STR:

1. Using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 on Windows 7, load http://www.nbcolympics.com/
2. Authenticate to your local cable/TV provider
3. Click to watch any of the live streams
4. Wait for an interstitial commercial to play

Expected:

Commercial plays

Actual:

Hangs, then crashes:

http://crash-stats.mozilla.com/report/index/bp-a6127b54-a303-4c09-8302-22b092120801
http://crash-stats.mozilla.com/report/index/bp-eef455b1-1137-41fa-9e32-58f2b2120801

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Screencast: http://screencast.com/t/A2E4rh5iSLCv

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

(I split this off of bug 778162.)

Comment 3

[smadayag]

would it be possible to get the dxdiag of the machine this example crashes on?

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: DxDiag output, as requested

Comment 5

[smadayag]

our internal bug, #3301025, has been forwarded to our video team...

Comment 6

[smadayag]

thank you for the attachment...

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to smadayag from comment #6)
> thank you for the attachment...

NP; let me know if you need anything else.

Comment 8

[smadayag]

our dev believes this to be resolved in 11.4.  although, crash-stats does have reports from 11.4.402.257, the samples are smaller.  

lets monitor the reports as people adopt flash player 11.4...

Comment 9

[Bob Clary [:bc] (inactive)]

see bug 566062 comment 40

Comment 10

[Scoobidiver (away)]

Let's use the topcrash keyword for the generic hang signature.

Comment 11

[banakon]

not only on olympics live, but on nasa live too.
https://crash-stats.mozilla.com/report/index/d834fbf9-9e0c-4102-b030-4991c2130709

Comment 12

[banakon]

I hav eto use IE9 for this live now
http://www.asitv.it/contenuti/nasa-live

a regular flash 11.8 hang.

Comment 13

[Benjamin Smedberg]

Can you please try to reproduce this with nightly/aurora? I have a better hang-reporting system there and can do a much more detailed analysis. Please paste in the hang report ID from there, which will be "hr-bp-<something>"

Comment 14

[candaules]

Hi, can you help me with this issue (every week, with three different pc) ?
thanks

https://bugzilla.mozilla.org/show_bug.cgi?id=789379#c15

hang.

Comment 15

[Georg Fritzsche [:gfritzsche]]

Can you reproduce this as per comment 13 here?

Comment 16

[candaules]

No, since FF11 you are telling that the next version would have a better report.
ff11 - ff22: too long time.
I am sure that when I send to you a report produced by FF26, you will ask me to install FF beta 27 for better report...and I become old man in the meantine ;)

workaround for my link above:

if you see the warning that flash plun hangs, you have to clic on Continue!!
wait, wait...then the playback starts.

Comment 17

[Scoobidiver (away)]

(In reply to candaules from comment #16)
> No, since FF11 you are telling that the next version would have a better
> report.
We haven't said that. We say that the Aurora and Nightly channels have a better hang reporting system. For instance, 24.0 is currently in Aurora and once in Beta the hang report system will be switched to a basic behavior that doesn't say much like your crash report.
Let's hope banakon is more cooperative.

Comment 18

[Igor]

Hi,

I was able to reproduce the issue on Aurora (Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130716 Firefox/24.0):

1) Install "Request Policy" add-on (I used https://www.requestpolicy.com/releases/requestpolicy-1.x.xpi)

2) Restart FF.

3) When FF restarts, RequestPolicy configuration wizard should launch. Configure RP to block everything, allow same domain and don't add any defaults.

4) Go to http://www.asitv.it/contenuti/nasa-live (this site was mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=789379)

5) You won't see the video, because ustream.tv is blocked. Click the RP icon (the red flag), click ustream.tv in the left pane and only allow requests from asitv.it to ustream.tv. Now, click on the webpage again, to close the RP dialog. This will reload the website.

6) The video should now appear. But watch the plugin-container.exe process and the Flash Plugin, how it will eat up all your memory. Then you will get the crash.

Here is a video, showing you all the steps:
https://www.dropbox.com/s/pi7clyplin7e156/ff-flash-hang-bug-779657.mp4

Some crash dumps, all invalid?!
https://crash-stats.mozilla.com/report/index/bp-hr-20130717-38b2a477-365a-4cd5-821a-5d302560c65a
https://crash-stats.mozilla.com/report/index/bp-hr-20130717-98f831a6-7e51-481b-9b10-17ff5284a8fd

FF 22 crash dumps seems to be valid:
https://crash-stats.mozilla.com/report/index/bec6c8c3-6ea3-4d54-b2c2-6e5362130717

Comment 19

[candaules]

Hi Igor, I confirm that!
and congratulations, this is the first time since I write here that the bug can be reproduced! very good. (except the silent crash of xul.exe after closing FF after using flash sandboxed, after one year and 2 months it has been resolved from mozialla (nt from adobe) starting from ff22: now the minidumps folder is empty.).
I can do all your steps using Noscript too.
I guess...that all FF user have to use always aurora (for a "readable crash report), none should use stable release. Then my question: why there is crash  reprt in the stable relase, if they are *always* unuseful?

Comment 20

[Scoobidiver (away)]

(In reply to candaules from comment #19)
> Then my question: why there is crash  reprt in the stable relase, if they are *always* 
> unuseful?
Only plugin hang reports in Release and Beta are not useful, plugin crash reports are always useful whatever the channel. They are there for statistical purposes.

Comment 21

[Georg Fritzsche [:gfritzsche]]

(In reply to Igor from comment #18)
> Some crash dumps, all invalid?!
> https://crash-stats.mozilla.com/report/index/bp-hr-20130717-38b2a477-365a-
> 4cd5-821a-5d302560c65a
> https://crash-stats.mozilla.com/report/index/bp-hr-20130717-98f831a6-7e51-
> 481b-9b10-17ff5284a8fd

I'll have to check why about:crashes produces the wrong links now, but those would be:

https://crash-analysis.mozilla.com/hang-reports/2013/07-17/hr-20130717-38b2a477-365a-4cd5-821a-5d302560c65a.html
https://crash-analysis.mozilla.com/hang-reports/2013/07-17/hr-20130717-98f831a6-7e51-481b-9b10-17ff5284a8fd.html

Comment 22

[Robert Kaiser]

(In reply to Scoobidiver from comment #20)
> (In reply to candaules from comment #19)
> > Then my question: why there is crash  reprt in the stable relase, if they are *always* 
> > unuseful?
> Only plugin hang reports in Release and Beta are not useful, plugin crash
> reports are always useful whatever the channel. They are there for
> statistical purposes.

Also, note that the beta and release reports not being as helpful is a temporary state, we are working on making our production systems be able to understand the new format of hang reports, and then the beta and release reports will be just as useful as the nightly and aurora ones.

Comment 23

[Georg Fritzsche [:gfritzsche]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #21)
> I'll have to check why about:crashes produces the wrong links now

Apparently this is just a temporarily broken redirect on crash-stats.mozilla.com

Comment 24

[Scoobidiver (away)]

Stephen, is it still reproducible?

Comment 25

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Scoobidiver from comment #24)
> Stephen, is it still reproducible?

Nope, how should I mark it?  WFM or fixed?  Guessing the former?

Comment 26

[Igor]

Please, don't close this.

I still get the crashes (like described in #18). Latest crash with FF 23: https://crash-stats.mozilla.com/report/index/882722e9-ffb8-4843-925e-752252130814

Also with the latest Aurora (from 20130814): https://crash-stats.mozilla.com/report/index/bp-hr-20130814-e375a782-6176-467e-8e8a-0fba440d303a

Comment 27

[banakon]

please dont close this bug.

Comment 28

[Igor]

One month later, no fix but multiple new crash reports:

bp-hr-20130920-18ba7448-b23e-44e4-9817-105b06c494df
bp-hr-20130920-72b00c47-6fd1-4d53-ab32-85c6d0d35297
bp-224dc3fc-0a18-4454-9ecb-3c4992130920
bp-hr-20130920-c26b823f-e4c1-4561-9218-3534c7986dd9
bp-hr-20130920-515b4363-0277-44c1-9c48-5bdc919849ff

I found the tracker bug 789379.. not sure about it. But sounds like you don't plan to fix that. Can you please confirm if you are still working on this or if this is something you will never fix? Thanks.

Comment 29

[banakon]

Hi, on the 29th september we will watch here
http://www.hoc.gr/index.php?option=com_content&view=article&id=893&catid=63&Itemid=98&lang=el
the Lighting flame ceremony,
so we will test the behaviour, because the video comes from ustream.com, the same as Nasa videos.
I hope that there will be no issues inthe upcoming live streaming.

Comment 30

[banakon]

my error:
ustream.com > ustream.tv
asi tv, hellenic olympic comitee all they are using ustream.tv
that causes flash plugin to arise 1500MB ram and hang.
on the next sunday, as said, there is an important event, available only with ustream.tv, since ERT tv does not exist ever.

Comment 31

[banakon]

I fully agree whit the question at #28 from Igor.

Comment 32

[Benjamin Smedberg]

I'm closing a lot of bugs which are filed as Adobe Flash bugs which are either irrelevant, not actionable, or not serious enough to track in the Mozilla bug tracker. For the most part, Flash bugs should be filed in Adobe bugbase, and we'll only track a few highly-critical issues in the Mozilla tracker.