733323 - Crash in nsAppShell::ProcessNextNativeEvent with abort message: "X_CopyArea: BadDrawable (invalid Pixmap or Window parameter)"

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Scoobidiver (away)]

Signature 	TouchBadMemory More Reports Search
UUID	3dfe7622-7a21-4b13-8112-5be412120226
Date Processed	2012-02-26 05:05:05
Uptime	82
Last Crash	1.6 minutes before submission
Install Age	2.5 minutes since version was first installed.
Install Time	2012-02-26 05:02:31
Product	Firefox
Version	13.0a1
Build ID	20120225031723
Release Channel	nightly
OS	Linux
OS Version	0.0.0 Linux 2.6.32-1-mepis64-smp #1 SMP PREEMPT Wed Oct 20 18:35:31 EDT 2010 x86_64
Build Architecture	amd64
Build Architecture Info	family 16 model 6 stepping 3
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
OpenGL: NVIDIA Corporation -- GeForce 6150SE nForce 430/integrated/SSE2 -- 2.1.2 NVIDIA 295.20 -- texture_from_pixmap
X_CopyArea: BadDrawable (invalid Pixmap or Window parameter); 4 requests agoxpcom_runtime_abort(###!!! ABORT: X_CopyArea: BadDrawable (invalid Pixmap or Window parameter); 4 requests ago: file /builds/slave/m-cen-lnx64-ntly/build/toolkit/xre/nsX11ErrorHandler.cpp, line 190)
EMCheckCompatibility	True

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 	libX11.so.6.2.0 	libX11.so.6.2.0@0x4735b 	
5 	libXext.so.6.4.0 	libXext.so.6.4.0@0x210fff 	
6 	ld-2.7.so 	ld-2.7.so@0xd1f9 	
7 	libX11.so.6.2.0 	libX11.so.6.2.0@0x8f17 	
8 	ld-2.7.so 	ld-2.7.so@0x12f21 	
9 	libX11.so.6.2.0 	libX11.so.6.2.0@0x4ed4e 	
10 	libpthread-2.7.so 	libpthread-2.7.so@0x9fdf 	
11 	libX11.so.6.2.0 	libX11.so.6.2.0@0x4f615 	
12 	libX11.so.6.2.0 	libX11.so.6.2.0@0x37d6c 	
13 	libgdk-x11-2.0.so.0.2000.1 	libgdk-x11-2.0.so.0.2000.1@0x5abf5 	
14 	libgdk-x11-2.0.so.0.2000.1 	libgdk-x11-2.0.so.0.2000.1@0x5ab8f 	
15 	libglib-2.0.so.0.2400.2 	libglib-2.0.so.0.2400.2@0x42617 	
16 	libpthread-2.7.so 	libpthread-2.7.so@0x9fdf 	
17 	libglib-2.0.so.0.2400.2 	libglib-2.0.so.0.2400.2@0x2dc5ff 	
18 	libglib-2.0.so.0.2400.2 	libglib-2.0.so.0.2400.2@0x42a24 	
19 	libpthread-2.7.so 	libpthread-2.7.so@0x848f 	
20 	libglib-2.0.so.0.2400.2 	libglib-2.0.so.0.2400.2@0x68178 	
21 	libpthread-2.7.so 	libpthread-2.7.so@0x848f 	
22 	libglib-2.0.so.0.2400.2 	libglib-2.0.so.0.2400.2@0x2dc5ff 	
23 	libglib-2.0.so.0.2400.2 	libglib-2.0.so.0.2400.2@0x42fea 	
24 	libxul.so 	nsAppShell::ProcessNextNativeEvent 	widget/gtk2/nsAppShell.cpp:162
25 	libxul.so 	nsBaseAppShell::OnProcessNextEvent 	widget/xpwidgets/nsBaseAppShell.cpp:171
26 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:619
27 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
28 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
29 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:208
30 	libxul.so 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
31 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:295
32 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3564
33 	firefox 	main 	browser/app/nsBrowserApp.cpp:190
34 	libc-2.7.so 	libc-2.7.so@0x1e1a5 	
35 	firefox 	firefox@0x1c9f 	
36 	firefox 	firefox@0x1c9f 	

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

Comment 1

[Bill Gianopoulos [:WG9s]]

I get this message just trying to access mozilla sites like https://quality.mozilla.org/teams/

Comment 2

[Karl Tomlinson (:karlt)]

Bill, are you able to provide a stack with system library symbols, please?
It likely needs to be from a run with MOZ_X_SYNC=1 in the environment to be helpful.

Comment 3

[Thiago]

I run into a similar problem when I open this link: "http://www.boadica.com.br/pesquisa/multi_placavideo/precos?ClasseProdutoX=2&CodCategoriaX=7&XG=3&XJ=2&modelo=EVGA|04G-P4-2690-KR&regiao=&em_box=&preco_min=&preco_max="

then try to change the field "Modelo:" to anything. It crashes and dumps:

###!!! ABORT: X_CopyArea: BadDrawable (invalid Pixmap or Window parameter); 84 requests ago: file /build/src/mozilla-release/toolkit/xre/nsX11ErrorHandler.cpp, line 190

Segmentation Fault

Comment 4

[Mats Palmgren (inactive)]

Attachment: stack trace with MOZ_X_SYNC=1, clicking around on www.canon.co.uk

I'll leave gdb open overnight, let me know if you want any other values
from it.  (mozilla-release debug build on Linux x86-64)

Comment 5

[Karl Tomlinson (:karlt)]

Thanks, Mats.

Can you look at the XCopyArea call in _cairo_xlib_surface_composite, please, to see whether either the source or destination drawables or both match XID 0x1e00392?

Beyond that, I'd try to track the bad drawable xid up the stack to find where it might have been created.  The BadDrawable error may be because the Pixmap or Window has been destroyed.

Comment 6

[Karl Tomlinson (:karlt)]

> mIsDestroyed = false,

aWidgetToPaint at least doesn't think it has been destroyed.

Comment 7

[Mats Palmgren (inactive)]

Attachment: XCopyArea data

Yes, source is 0x1e00392.  Destination is 0x54017b2.

Comment 8

[Christian Ascheberg]

This action crashes Firefox basically every time on my laptop:
1. start Firefox
2. go to http://www.ai.rug.nl/robocupathome/ (page has embedded Youtube videos)
3. select "Mexico 2012" (see left side, new tab will open)
4. on new tab hover "Competitions" (see top), select "RoboCup@home"
5. if it hasn't crashed yet: click "Results" (left side)

I can not reproduce this with plugins.click_to_play=true though.
(Not sure if that pref is fully implemented in Firefox 13.0.1 at all.)

Comment 9

[Karl Tomlinson (:karlt)]

Christian, it sounds like your issue is plugin related, which would be a different cause of similar symptoms.
If you look in about:config and search for dom.ipc.plugins, is dom.ipc.plugins.enabled set to true?
Are there any non-default (bold) dom.ipc.plugins.something settings?

Comment 10

[Karl Tomlinson (:karlt)]

Hmm.  Maybe Mats' crash is plugin-related too, with the BasicShadowableImageLayer.
0x1e00392 looks like it is from a different X connection (likely different process) to 0x54017b2.  If the plugin process has deleted that drawable, then that would cause this error.  (We could also get this error if the X server hasn't processed the request to create the drawable, but MOZ_X_SYNC=1 should rule out that possibility.)

Comment 11

[Christian Ascheberg]

(In reply to Karl Tomlinson (:karlt) from comment #9)
> it sounds like your issue is plugin related, which would be a
> different cause of similar symptoms.

This is one of my crash reports, and it is how I found this bug:
bp-5dce8d32-8830-491d-bdfa-63dcd2120621

> If you look in about:config and search for dom.ipc.plugins, is
> dom.ipc.plugins.enabled set to true?

yes

> Are there any non-default (bold) dom.ipc.plugins.something settings?

no

Comment 13

[Karl Tomlinson (:karlt)]

Given bug 745488, there is a good chance this is an image layer bug.

Comment 14

[Karl Tomlinson (:karlt)]

Since http://hg.mozilla.org/mozilla-central/rev/1a345b043b47
container->SetCurrentImage(nsnull) is no longer called if
PluginInstanceParent::GetImageContainer() fails due to a NULL mFrontSurface.

Not clear exactly how a subsequent transaction would manage to still paint the
old image container after the NPP_Destroy is called on the plugin instance.
Perhaps that might be related to the container's oldSize now no longer being
invalidated in nsPluginInstanceOwner::InvalidateRect().

Comment 15

[Karl Tomlinson (:karlt)]

Bug 745488 happens after test_flush_on_paint.html which uses a windowless plugin.

Comment 16

[Karl Tomlinson (:karlt)]

Actually, nsNPAPIPluginInstance::InvalidateRect() does nothing when
RUNNING != mRunning and would have behaved the same even before 1a345b043b47.

mRunning == DESTROYING while NPP_Destroy is being called.

This means that the surface in the ImageContainer can get out of sync
with mFrontBuffer through a RecvShow from a Child::ShowPluginFrame even before
the child processes the NPP_Destroy.

The ImageContainer and its CairoImage with destroyed Pixmap stays alive well
after the plugin is destroyed until the next
FrameLayerBuilder::WillEndTransaction UpdateDisplayItemDataForFrame but I
don't know whether or not it can actually be used before then.

Comment 17

[Matt Woodrow (:mattwoodrow)]

Attachment: Prevent crash

Patches from bug 539359 make this reproducible on linux 32 tp4.

The attached patch fixes the crash at least, not sure if it's exactly what we want though.

Maybe always updating the ImageContainer (if a cached one exists) when we receive a new surface would be preferable.

Comment 19

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5d8b73612d33

Comment 20

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/5d8b73612d33

Comment 23

[Scoobidiver (away)]

It accounts for 27% of Linux crashes in case 16.0.2 is planned.

Comment 24

[Alex Keybl [:akeybl]]

Matt - how risky is this patch? I'm very hesitant to take a patch here if there is any chance of regression.

Comment 25

[Matt Woodrow (:mattwoodrow)]

It's very low risk, just makes sure we let go of the plugin surface immediately.

Comment 26

[u279076]

Marking this bug verified based on crash-stats. I'm not seeing any instances of this crash signature for Firefox 17 on Socorro in the last month.

Comment 27

[Scoobidiver (away)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #26)
> I'm not seeing any instances of this crash signature for Firefox 17 on Socorro
> in the last month.
I guess you meant crash signature AND abort message: https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A17.0b1&signature=mozalloc_abort%20|%20NS_DebugBreak_P%20|%20X11Error