733322 - Crash in nsAppShell::ProcessNextNativeEvent with abort message: "X_ShmPutImage or X_CopyArea: BadMatch (invalid parameter attributes)" with Flash Player in browser process

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Scoobidiver (away)]

Signature 	TouchBadMemory More Reports Search
UUID	33c2b014-8357-400f-a6f9-32c172120305
Date Processed	2012-03-05 13:31:13
Uptime	3307
Last Crash	55.2 minutes before submission
Install Age	57.2 minutes since version was first installed.
Install Time	2012-03-05 12:33:30
Product	Firefox
Version	13.0a1
Build ID	20120304031031
Release Channel	nightly
OS	Linux
OS Version	0.0.0 Linux 3.0.0-12-generic-pae #20-Ubuntu SMP Fri Oct 7 16:37:17 UTC 2011 i686
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 16 model 5 stepping 2
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
OpenGL: NVIDIA Corporation -- GeForce GT 220/PCI/SSE2/3DNOW! -- 3.3.0 NVIDIA 280.13 -- texture_from_pixmap
X_ShmPutImage: BadMatch (invalid parameter attributes); 167 requests agoxpcom_runtime_abort(###!!! ABORT: X_ShmPutImage: BadMatch (invalid parameter attributes); 167 requests ago: file /builds/slave/m-cen-lnx-ntly/build/toolkit/xre/nsX11ErrorHandler.cpp, line 190)	
EMCheckCompatibility	False

Crashing Thread
Frame 	Module 	Signature 	Source
0 	libmozalloc.so 	TouchBadMemory 	memory/mozalloc/mozalloc_abort.cpp:68
1 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:89
2 	libxul.so 	NS_DebugBreak_P 	xpcom/base/nsDebugImpl.cpp:388
3 	libxul.so 	X11Error 	toolkit/xre/nsX11ErrorHandler.cpp:190
4 	libbonoboui-2.so.0.0.0 	libbonoboui-2.so.0.0.0@0x1ea74 	
5 	libX11.so.6.3.0 	_XError 	XlibInt.c:1583
6 	libX11.so.6.3.0 	handle_error 	xcb_io.c:212
7 	libX11.so.6.3.0 	handle_response 	xcb_io.c:324
8 	libX11.so.6.3.0 	_XEventsQueued 	xcb_io.c:363
9 	libX11.so.6.3.0 	XPending 	Pending.c:55
10 	libgdk-x11-2.0.so.0.2400.6 	gdk_event_prepare 	gdkevents-x11.c:159
11 	libglib-2.0.so.0.3000.0 	g_main_context_prepare 	gmain.c:2762
12 	libglib-2.0.so.0.3000.0 	g_main_context_iterate 	gmain.c:3069
13 	libglib-2.0.so.0.3000.0 	g_main_context_iteration 	gmain.c:3152
14 	libxul.so 	nsAppShell::ProcessNextNativeEvent 	widget/gtk2/nsAppShell.cpp:162
15 	libxul.so 	nsBaseAppShell::OnProcessNextEvent 	widget/xpwidgets/nsBaseAppShell.cpp:171
16 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:619
17 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
18 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
19 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:208
20 	libxul.so 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
21 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:295
22 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3564
23 	firefox 	main 	browser/app/nsBrowserApp.cpp:190
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=TouchBadMemory

Comment 1

[Karl Tomlinson (:karlt)]

Gecko doesn't usually use XShm.
Some GTK themes may end up using it, but, given the Flash Player threads in the browser process, that looks the likely culprit.

Flash Player should not be doing much in the browser process unless preferences have been changed, which I expect is the case here.

Comment 2

[Karl Tomlinson (:karlt)]

I'll mark this as invalid as resetting  dom.ipc.plugins.* preferences to their defaults should resolve the browser crash, and we don't have a reason to support running Flash Player in the browser process.

Comment 4

[Chris Coulson]

There seem to be a lot of these types of crashes in Firefox 12 now, all with flash running in the main process:

https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-05-02&signature=TouchBadMemory%20|%20libxul.so%400x253252%20|%20libxul.so%400x159360f%20|%20mozalloc_abort%20|%20libxul.so%400xd492b5%20|%20libc-2.11.1.so%400x155863&version=Firefox%3A12.0

https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-05-02&signature=TouchBadMemory%20|%20mozalloc_abort%20|%20libxul.so%400xd6214a%20|%20libc-2.13.so%400x17a87b&version=Firefox%3A12.0

https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-05-02&signature=TouchBadMemory%20|%20mozalloc_abort%20|%20libxul.so%400xd5d8d6%20|%20libc-2.15.so%400x1a1d9b&version=Firefox%3A12.0

This is an abnormally high rate of crashes isn't it? I wonder if people are having a specific issue which is causing them to change dom.ipc.plugins.enabled?

Comment 5

[Chris Coulson]

Note, the broken traces are bug 750637

Comment 6

[Scoobidiver (away)]

(In reply to Chris Coulson from comment #4)
> I wonder if people are having a specific issue which is causing them to change
> dom.ipc.plugins.enabled?
It's bug 704249 caused by IcedTea 1.1.

Comment 7

[a_geek]

I'm not sure why I'm on this bug's list, but I specifically reset dom.ipc.plugins.enabled to the default value, after not knowing why it was changed in the first place, and I have

ii  icedtea6-plugin  6b18-1.8.13-0+squeeze1

which may or may not be that what you refer to as IcedTea 1.1 (but I have no clue about Java, either).

Comment 8

[Karl Tomlinson (:karlt)]

I'd also like to know why dom.ipc.plugins.enabled is often false, but the workaround for bug 704249 is setting a slightly different pref to true.

Comment 9

[Scoobidiver (away)]

(In reply to Karl Tomlinson (:karlt) from comment #8)
> I'd also like to know why dom.ipc.plugins.enabled is often false, but the
> workaround for bug 704249 is setting a slightly different pref to true.
Users usually know how to disable the OOPP with dom.ipc.plugins.enabled, but don't know it can be set for each plugin like dom.ipc.plugins.java.enabled for Java.

Comment 10

[Karl Tomlinson (:karlt)]

OOPP java is usually disabled, but the workaround for bug 704249 is to *enable* 00PP even for java.

Comment 11

[Chris Coulson]

The third hit on Google when searching for "plugin-container" is an article explaining how to turn off OOPP, so it's entirely conceivable that anyone who has a problem with it (something like high CPU usage, perhaps?) figures out how to disable it.

Comment 12

[Karl Tomlinson (:karlt)]

(In reply to Chris Coulson from comment #4)
> There seem to be a lot of these types of crashes in Firefox 12 now, all with
> flash running in the main process:

This is cause by Bug 751641.

Comment 13

[Josh Aas]

(In reply to Karl Tomlinson (:karlt) from comment #12)
> (In reply to Chris Coulson from comment #4)
> > There seem to be a lot of these types of crashes in Firefox 12 now, all with
> > flash running in the main process:
> 
> This is cause by Bug 751641.

That bug cannot be about something in Firefox 12. That bug is a regression on mozilla-central only. See deps.

Comment 14

[Karl Tomlinson (:karlt)]

Oh, sorry, I somehow missed the version=Firefox%3A12.0

Comment 15

[Scoobidiver (away)]

There is a spike in crashes starting in 15.0a1/20120503 making it #6 top crasher over the last day. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b13bfc70bc44&tochange=807403a04a6a
I think it's related to bug 751826.

Comment 16

[Geoff Lankow (:darktrojan)]

Bug 751641 does appear to be the cause in nightly. Removing a broken pluginreg.dat caused by that bug fixes this crash for me.

Comment 17

[Virgil Dicu [:virgil] [QA]]

http://crash-stats.mozilla.com/report/index/bp-3c010838-0942-427d-9241-1fb562120507

Hit this with today's Nightly.

Simply loading www.gsp.ro on a clean profile triggers the crash.

Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/15.0 Firefox/15.0a1

Comment 18

[Thomas Ahlblom]

Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/15.0 Firefox/15.0a1
Built from http://hg.mozilla.org/mozilla-central/rev/94ce5f33a9ea
Adobe Flash Player 11.2.202.235

No crash for me on http://www.gsp.ro with a new, clean profile and vanilla FX Nightly.

Comment 19

[Virgil Dicu [:virgil] [QA]]

Ubuntu 12.04 here. I get the following output in the console:

After trying another couple of times, the page does load normally, but rarely. It seems that the crash occurs in 4 out of 5-6 attempts, didn't find a useful pattern until now. When the page does load normally, the adds that use Flash aren't loaded (displayed as blank). 

Following output in the console. Only occurs on Nightly.

###!!! ABORT: X_ShmPutImage: BadMatch (invalid parameter attributes); 13 requests ago: file /builds/slave/m-cen-lnx-ntly/build/toolkit/xre/nsX11ErrorHandler.cpp, line 190

Comment 20

[Virgil Dicu [:virgil] [QA]]

With today's Nightly this seems to be fixed for me: 20120510.
The flash adds load completely and no crashes in Firefox when visiting gsp.ro (could also previously repro with one of the sites in crash stats comments:http://ava.furb.br)

Comment 22

[Josh Aas]

Fixed by the patch in bug 751641.

Comment 23

[Philipp von Weitershausen [:philikon]]

(In reply to Josh Aas (Mozilla Corporation) from comment #22)
> Fixed by the patch in bug 751641.

Either it's not fixed entirely, or I was seeing a different big in bug 754911. Which one should we reopen?

Comment 24

[Josh Aas]

If you're still seeing this then it probably doesn't have anything to do with bug 751641 or bug 748343, which is a blocking dep here.

Comment 25

[Scoobidiver (away)]

(In reply to Philipp von Weitershausen [:philikon] from comment #23)
> Either it's not fixed entirely, or I was seeing a different big in bug
> 754911. Which one should we reopen?
bug 754911 landed in 15.0a1/20120505 but hasn't fixed it (around 40 crashes per build). See https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A15.0a1&query_search=signature&query_type=contains&reason_type=contains&range_value=28&range_unit=days&do_query=1&signature=TouchBadMemory%20|%20mozalloc_abort%20|%20NS_DebugBreak_P%20|%20X11Error

Comment 26

[Scoobidiver (away)]

It seems the spike in 15.0 is gone in 15.0a1/20120518. The working range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c00a9c1940c5&tochange=762e95608da3

Comment 29

[Marcia Knous [:marcia]]

mozalloc_abort | NS_DebugBreak_P | X11Error has 49 crashes on the trunk.

TouchBadMemory has 2 crashes on Firefox 13/13.0.1.

TouchBadMemory | mozalloc_abort | NS_DebugBreak_P | X11Error still has a fair number of crashes for release versions but not for Aurora. That signature is also associated with 2 other open bugs (Bug 733323 and Bug 733325)

Comment 30

[Shyam Mani [:fox2mike]]

Ubuntu 11.04 saw this today - https://crash-stats.mozilla.com/report/index/63dc0524-aea0-43c2-8d50-b06912120708

Comment 31

[Karl Tomlinson (:karlt)]

Shyam: do you know why you have flash player running in the browser process?

Check dom.ipc.plugins.* preferences.  If they are at their defaults, then try moving pluginreg.dat out of the way in the profile directory and it will be regenerated.

Comment 32

[Alex Keybl [:akeybl]]

(In reply to Scoobidiver from comment #26)
> It seems the spike in 15.0 is gone in 15.0a1/20120518. The working range is:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=c00a9c1940c5&tochange=762e95608da3

Please re-nominate if this trends up again in the future. Untracking for FF15 for now.

Comment 34

[Schmitz Christian]

This work for me. never more has crashed.
Karl Tomlinson
Check dom.ipc.plugins.* preferences.  If they are at their defaults,

Comment 37

[Georg Fritzsche [:gfritzsche]]

Looking through the related signatures here:
https://crash-stats.mozilla.com/query/query?product=Firefox&version=ALL%3AALL&platform=linux&range_value=1&range_unit=weeks&date=02%2F28%2F2013+11%3A06%3A38&query_search=signature&query_type=contains&query=TouchBadMemory&reason=&build_id=&process_type=any&hang_type=any&do_query=1

... i only see those happening with Fx<=15.x.
Scoobidiver, could you confirm?

Comment 38

[Scoobidiver (away)]

The crash signature morphs with releases but it still #1 top crasher on Linux in any channel.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29+|+NS_DebugBreak_P+|+X11Error
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29+|+NS_DebugBreak_P

Comment 39

[Georg Fritzsche [:gfritzsche]]

Oh, thanks - i was somehow fixated on TouchBadMemory.

Worth noting that most of the "mozalloc_abort(char+const*)+|+NS_DebugBreak_P" ones are Fennec crashes below some "dalvik-LinearAlloc (deleted)" stack. I don't see a bug linked there for this, worth filing?

Comment 40

[Scoobidiver (away)]

(In reply to Georg Fritzsche [:gfritzsche] from comment #39)
> Worth noting that most of the
> "mozalloc_abort(char+const*)+|+NS_DebugBreak_P" ones are Fennec crashes
> below some "dalvik-LinearAlloc (deleted)" stack. I don't see a bug linked
> there for this, worth filing?
Stack traces for crashes on abort are buggy on Android. Only the abort message matters. It's bug 834243 and also bug 846243.

Comment 41

[Robert Kaiser]

This is not a topcrash any more.

Benjamin, should we close this bug completely as in-browser Flash is not supported any more at all?

Comment 42

[Benjamin Smedberg]

Yes.