482091 - fennec crashes frequently while browsing, disabling shockwave flash plugin reduces the crashes

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

I have noticed while browsing Fennec will crash quite frequently. Initially I thought this was jit, but turning jit off didn't help.  I found out that disabling the shockwave flash plugin, I had a hard time crashing the browser.

I played around a lot with this and found that with the plugin enabled, I crash a LOT, with it disabled, very infrequently.  Others have noticed this as well.

I recommend disabling the plugin by default for beta1 to improve the user experience.  

I would recommend visiting a website that has flash (www.tokbox.com -> www.facebook.com, or aljazeera.net -> qq.com), then browsing away from it if you want to reproduce this.

Comment 1

[timeless]

whose flash library are you using?

please be nice and include a useragent and a uname when filing such bugs. and the flash plugin version for bugs about flash....

Comment 2

[:Gavin Sharp [email: [e-mail]]]

The n810's ship with a symlink in .mozilla/plugins to /usr/lib/browser/plugins/libflashplayer.so, so we end up using that, as far as I know (certainly was the case for my device).

Comment 3

[timeless]

ok, so it's the nokia flash player, and which version? (ask dpkg)

if your provide me with urls for core dumps, i can send them to the people who have symbols for flash player (note that it would be helpful if you also including a link to symbols for the corresponding xulrunner+fennec).

for whatever reason, the OS for this system was selected as 'Linux (embedded)', which means that I'm not guaranteed this is Maemo. Therefore, I kindly request that when you file bugs you actually include things like the OS (uname -a, /etc/osso_software_version) and package version info if it's relevant (dpkg...)

Comment 4

[Joel Maher ( :jmaher ) (UTC -8)]

there is no other target to specify maemo, so I have been using linux (embedded).  Here is the specifics to the device I am using:
Nokia-N810-51-3:/media/mmc1/unittests/fennec# uname -a
Linux Nokia-N810-51-3 2.6.21-omap1 #2 Fri Dec 7 11:17:13 EET 2007 armv6l unknown
Nokia-N810-51-3:/media/mmc1/unittests/fennec# cat /etc/osso_software_version 
RX-34+RX-44_2008SE_2.2007.51-3.4.SINGTEL_PR_SI0
Nokia-N810-51-3:/media/mmc1/unittests/fennec# 

The Fennec build in use can be found here:
http://ftp.mozilla.org/pub/mozilla.org/mobile/b1rc2/

As for core dumps, I don't see any on my system.  This is a release build and not a debug build.  

The version of shockwave-flash is what is provided by default in the Maemo device that I have:
Shockwave Flash 9.0 r31

I couldn't find the package using dpkg

Comment 5

[timeless]

err, that's chinook.

please upgrade to diablo.

and as long as maemo can exist in different versions, please continue to include those details when you file bugs.

you should have at least:

RX-34+RX-44+RX-48_DIABLO_5.2008.43-7_PR_MR0
Shockwave Flash 9.0 r48

Comment 6

[timeless]

err sorry, not chinook, original shipping diablo

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Do the same websites crash using microb?

Comment 8

[Joel Maher ( :jmaher ) (UTC -8)]

I have updated my device to the latest OS2008 and reverified this issue.  My plugin in:
shockwave flash 9.0 r48

I browse to:
tokbox.com  <- verify it doesn't load because it is missing a compatible flash plugin

then browse to:
facebook.com


This results in a crash before facebook loads.  I verified this happens twice, disabled the plugin in fennec, retested and I could get to facebook.

Next I launched microb and I was able to get to facebook as expected.

So it appears this is a Fennec specific crash.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

It looks like this one is my fault. I'm not sure what's going wrong yet. I've got a patch that papers over the problem.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Attachment: Bandaid over plugin problem

This keeps facebook from crashing. I'll see if I can figure out what's going on.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

Attachment: Avoid trying to draw windowless plugins

This seems to work better than the previous patch and makes more sense.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

The patch above makes sure we don't try to draw windowless plugins as though they had a window and keeps us from crashing in those cases.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

It also doesn't seem to help the situation on the device.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

If anyone can provide a stack trace of the crash that would be very useful.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

It looks like we are crashing in libdbus when handling glib events. 

lr = dbus_connection_dispatch

and the stack looks like something like:

 -- libpthread.so.0
 -- _dbus_pthread_mutex_unlock()
message_queue_dispatch()
...
g_main_context_iteration
nsAppShell::ProcessNextNativeEvent(int)
nsBaseAppShell::DoProcessNextNativeEvent(int)

So I'm not even sure that this my fault.

Comment 16

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #12)
> The patch above makes sure we don't try to draw windowless plugins as though
> they had a window and keeps us from crashing in those cases.

For the record, it turns out this patch was fixing crashes I was seeing that were caused by upgrading to flash 10 (supporting windowless mode) in my linux vm.

I can not reproduce the problem in my linux vm, even with flash 9.

Comment 17

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #15)
> It looks like we are crashing in libdbus when handling glib events. 
> 
> lr = dbus_connection_dispatch

It looks like we crash trying to call an invalid filter->function on
line 4267 of dbus-connection.c.

Comment 18

[Jeff Muizelaar [:jrmuizel]]

It looks like the problem is that libplayback adds a dbus_connection_filter when called into by flash but does not remove that filter when libplayback is unloaded.

microb likely avoids this problem by having libplayback always loaded and we could likely work around the problem the same way.

Comment 19

[timeless]

please file a bug in bugs.maemo.org, thanks.

Comment 20

[Jeff Muizelaar [:jrmuizel]]

Attachment: try to workaround libplayback problem.

This patch should work but I haven't been able to get it too. I'm not sure why.

Comment 21

[Jeff Muizelaar [:jrmuizel]]

Attachment: cleanup composited plugins

Comment 22

[Jeff Muizelaar [:jrmuizel]]

Attachment: dlopen libplayback.so

dlopening libplayback keeps us from crashing when we unload the flash plugin.

Comment 23

[Jeff Muizelaar [:jrmuizel]]

Attachment: dlopen libplayback.so v2

This version adds a comment explaining what's going on. The dlopening could happen anywhere. I chose the current location because it's already ifdefed away and I want the dlopen to happen on plugin load and not startup.

Comment 24

[Jeff Muizelaar [:jrmuizel]]

Joel,

I've put up a build up for testing at:
http://people.mozilla.com/~jmuizelaar/fennec-1.0a3pre.en-US.linux-arm.tar.bz2

Comment 25

[Joel Maher ( :jmaher ) (UTC -8)]

I tested this build and could not get the browser to crash.  The only odd thing I noted (which I assume isn't part of the patch) is that when hitting a site with flash, the browser is very hard to use as the response time is measure in seconds.  The memory usage of Fennec is very high then, so I am considering this a factor of plugins and streaming audio/video.

Great job on the patch making Fennec work.

Comment 26

[Stuart Parmenter]

Comment on attachment 366965 [details] [diff] [review]
dlopen libplayback.so v2

scary, but lets go with it for now.

Comment 27

[Brad Lassey [:blassey] (use needinfo?)]

has this landed?

Comment 28

[Jeff Muizelaar [:jrmuizel]]

It's in trunk, I don't know about 1.9.1

Comment 30

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 366965 [details] [diff] [review]
dlopen libplayback.so v2

Fennec will be built off of 1.9.2, so this can wait for that branch.