mozilla, flash, hang

[waider]

Well, for what it's worth, it appears to be a Macromedia bug somehow. That said, I feel that Mozilla could be doing more to isolate plugin bugs and stop them from hanging up the entire browser (it's threaded; what's the excuse?)Here's a stacktrace from a hung mozilla process:

#0  0xffffe002 in ?? ()
#1  0x4238c7b1 in PlatformSoundMix::CloseDevice() ()
   from /usr/lib/flash-plugin/libflashplayer.so
#2  0x4238c38c in PlatformSoundMix::PlatformCloseDevice() ()
   from /usr/lib/flash-plugin/libflashplayer.so
#3  0x42306ac0 in CoreSoundMix::CloseDevice() ()
   from /usr/lib/flash-plugin/libflashplayer.so
#4  0x42306475 in CoreSoundMix::Destruct() ()
   from /usr/lib/flash-plugin/libflashplayer.so
#5  0x42350460 in CoreGlobals::Destroy() ()
   from /usr/lib/flash-plugin/libflashplayer.so
#6  0x42321685 in CorePlayer::~CorePlayer() ()
   from /usr/lib/flash-plugin/libflashplayer.so
#7  0x4235f996 in UnixCommonPlayer::~UnixCommonPlayer() ()
   from /usr/lib/flash-plugin/libflashplayer.so
#8  0x4239728c in PlatformPlayer::~PlatformPlayer() ()
   from /usr/lib/flash-plugin/libflashplayer.so
#9  0x42398f44 in PlatformPlayer::NsDestroyPlayer(_NPP*) ()
   from /usr/lib/flash-plugin/libflashplayer.so
#10 0x4239cb31 in NPP_Destroy () from /usr/lib/flash-plugin/libflashplayer.so
#11 0x4239ae30 in Private_Destroy ()
   from /usr/lib/flash-plugin/libflashplayer.so
#12 0x4224f73a in ns4xPluginInstance::Stop() ()
   from /usr/lib/mozilla-1.6/components/libgkplugin.so
... and so on

So basically the damn thing is hanging while trying to close the sound device, although that 0xffffe002 looks a bit dubious. Upshot, though, appears to be either don't use a sound daemon - which has its own collection of problems - or don't use flash, or, I dunno, whine at Macromedia until they debug this problem. Of course, as I mentioned, it doesn't happen with Konqueror, which suggests that the Konq guys have some smarter way of coping with this. Perhaps the Mozilla people could have a look at that.

Comments

[pobig.livejournal.com]

It's really looking more and more unfortunate that the X protocol didn't consider audio, but I guess back in 1985 all you had was .au files to rcp to /dev/audio for when you wanted to crash someone's workstation.

[waider.livejournal.com]

Actually, I think the problem with Linux is more that the OSS API doesn't allow multiple opens on the sound device. Which is why you get all these daft sound server gadgets, etc.

[candice.livejournal.com]

NOOOOOOOOO.

X is so not where you put audio. Audio is a whole separate variety of driver.

Display = display. X has enough shit crufted onto it in the first place...

/sorry, I used to do X for a living and even for fun(?!)
/rantlet

[ronebofh.livejournal.com]

Do not dare impugn the wonderfulness of Macromedia products, you dog.

[waider.livejournal.com]

You go fix the bug on your lunchbreak, I'll stop impugning. As I stated elsewhere, allowing esd to run (under arts, nngh ick puke) cures the problem, with the possible added voodoo of disabling input methods for Mozilla. Running flash under Konqueror (with esd disabled) also cures the problem. Thus, from the stacktrace, the hang appears to be within flash's impugnable code, and as such Macromedia should fix it; from Konq's behaviour, the problem is somehow caused, aggravated, or encouraged by Mozilla, so the Mozilla people should go fix it. Much as I like digging around in other people's buggy code, attempting to trace through the second-system-effect posterboy that is Mozilla is not the sort of thing I'm liable to do in a hurry.

It's occurred to me that the problem could well be that since Mozilla is so tied to esd, it assumes any attempt to start esd was successful and ends up passing a bogus audio handle to flash to play with. Maybe I will go digging in the code a bit. With a baseball bat.