100376 - flash plugin crash when audio is playing

Status: VERIFIED DUPLICATE of bug 58339

(Core Graveyard :: Plug-ins, defect)

Description

[Scott McPeak]

This isn't strictly a bug in Mozilla, but I haven't found acknowledgement of
this anywhere else.  If another process is using /dev/dsp when mozilla is
pointed at a page containing flash content, the flash plugin (5.0 r47) will
hang the browswer.  Bug 100120 may have the same cause.

It turns out that killing the other process will permit the page to
finish loading and unhang the browser (so this report also serves to document
this important workaround).

I have observed this behavior in Netscape 4.77, Mozilla 0.9.3, and Mozilla
0.9.4.  Mozilla 0.9.3 uniquely refuses to even start when audio is playing
and the flash plugin is enabled.

Steps to reproduce:
  - start mozilla with flash plugin enabled (confirm with about:plugins)
  - start playing an mp3
  - visit www.flash.com

Observed behavior:
A few page elements load and display, then all browser activity ceases.
WORKAROUND: Browser functionality resumes if mp3 player is killed.

Expected/desired behavior:
  - the flash plugin should deal with the problem more gracefully
  - mozilla should (ideally; cf. bug 30751) detect and recover

Comment 1

[Scott McPeak]

I forgot to mention: I have emailed [e-mail] to
report this as well.

Comment 2

[av (gone)]

This is a dup.

*** This bug has been marked as a duplicate of 58339 ***

Comment 3

[shrirang khanzode]

v

Comment 4

[av (gone)]

The hang on start has been fixed, but problems with visiting flash enabled sites 
still remain. I am reopening this bug as per serge's request.

Comment 5

[av (gone)]

reassigning...

Comment 6

[Scott McPeak]

Attachment: kernel patch: hack to let the es1371 pretend O_NONBLOCK was passed

Comment 7

[Scott McPeak]

I just attached a quick+dirty patch to the linux es1371 module
to make my audio device think O_NONBLOCK is always passed to
open(2).  This is a hint as to how desperate I am to get around
this bug!  :)  If you happen to be using the es1371 module,
this patch should work.

I've also been thinking it would be sufficient for someone to
find the place in libflashplayer.so where open(2) is called, and
just manually or O_NONBLOCK into the flags when they're pushed.
Then, Flash with a binary patch would work.

The version I have (5.0 r47) is statically linked with no
debugging symbols, and I don't know enough about the plugin
registration process, so I haven't had any success finding the
place open is called.  Perhaps someone else can pursue this.

Comment 8

[Scott McPeak]

I played a little bit with Mozilla in its new hang-free state, and find the
results are mixed.  Example: with the es1371 patch (and /dev/dsp busy), go to

  http://www.newgrounds.com/portal/content.php?id=31539

(some violent content :) ).  While playing the "game", it's very choppy,
as Flash is trying to open /dev/dsp every second or so (but why does that
produce visible delays? I don't know).  But, it does not hang.

After playing the game, I find Mozilla is permanently wedged in the will-not-
display-any-page state: see bug 91528.  Attempting to visit any site
yields an appropriate amount of network activity, but a blank browser page.
So, at least for the moment, the O_NONBLOCK hack is clearly not a substitute
for Macromedia doing their job and fixing the plugin!

Comment 9

[serge (gone)]

Scott McPeak, thank you for the patch, 
unfortunately I cannot reproduce the problem at all:(
my rh7.0 has emu10k1 which works just fine...

Comment 10

[R.K.Aa.]

Isn't the es1371 issues some of the reason bug 58339 was reopened?

Comment 11

[serge (gone)]

yes, that is true, I'm resolvig this as dup of 58339

*** This bug has been marked as a duplicate of 58339 ***

Comment 12

[shrirang khanzode]

mass duplicate verifications . For filtering purposes, pls use keywd
"massdupverification"