Signature TouchBadMemory More Reports Search
Date Processed 2012-02-26 05:05:05
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
Build ID 20120225031723
Release Channel nightly
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
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)
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:
I get this message just trying to access mozilla sites like https://quality.mozilla.org/teams/
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.
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®iao=&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
Created attachment 633951 [details]
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)
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.
> mIsDestroyed = false,
aWidgetToPaint at least doesn't think it has been destroyed.
Created attachment 634018 [details]
Yes, source is 0x1e00392. Destination is 0x54017b2.
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.)
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?
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.)
(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:
> 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?
*** Bug 767810 has been marked as a duplicate of this bug. ***
Given bug 745488, there is a good chance this is an image layer bug.
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().
Bug 745488 happens after test_flush_on_paint.html which uses a windowless plugin.
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.
Created attachment 646795 [details] [diff] [review]
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.
*** Bug 781577 has been marked as a duplicate of this bug. ***
*** Bug 733325 has been marked as a duplicate of this bug. ***
*** Bug 797789 has been marked as a duplicate of this bug. ***
It accounts for 27% of Linux crashes in case 16.0.2 is planned.
Matt - how risky is this patch? I'm very hesitant to take a patch here if there is any chance of regression.
It's very low risk, just makes sure we let go of the plugin surface immediately.
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.
(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