SIGSEGV in INT__moz_cairo_surface_destroy

[vandyswa]

32-bit KUbuntu 10.04, seeing SEGV's in Konqueror, Firefox, and Chrome. Stack backtrace gathered from Firefox:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3

Happens on multiple video hardware configurations on multiple machines here.

Note that under Chrome, due to its use of processes, it just displays an "Aw, snap!" failure page, but the browser keeps going. On FF it bombs all the way out.

SW version for Cairo components: libcairo2_1.8.10-2ubuntu1_i386.deb, libcairomm-1.0-1_1.8.0-1build2_i386.deb

#0 0xa7260e40 in ?? ()
#1 0xb7cbea95 in *INT__moz_cairo_surface_destroy (surface=0xa71df070)
    at cairo-surface.c:443
#2 0xb7c61e01 in gfxASurface::Release (this=0xa2ab4370) at gfxASurface.cpp:106
#3 0xb74d92a9 in nsRefPtr<gfxASurface>::assign_assuming_AddRef (
    this=0xa66d9740, rhs=0xa6960f40) at ../../../dist/include/nsAutoPtr.h:944
#4 nsRefPtr<gfxASurface>::assign_with_AddRef (this=0xa66d9740, rhs=0xa6960f40)
    at ../../../dist/include/nsAutoPtr.h:928
#5 nsRefPtr<gfxASurface>::operator= (this=0xa66d9740, rhs=0xa6960f40)
    at ../../../dist/include/nsAutoPtr.h:1003
#6 0xb7b4603a in nsWindow::GetThebesSurface (this=0xa66d9690)
    at nsWindow.cpp:7336
#7 0xb7b67abb in nsBaseWidget::GetRenderingContext (this=0xa66d9690)
    at nsBaseWidget.cpp:655
#8 0xb7b4cbb3 in nsWindow::OnExposeEvent (this=0xa66d9690,
    aWidget=0xb254c4c0, aEvent=0xbfffed08) at nsWindow.cpp:2244
#9 0xb7b4d3ff in expose_event_cb (widget=0xb254c4c0, event=0xbfffed08)
    at nsWindow.cpp:5465
#10 0xb6d93364 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb6920252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#12 0xb693499d in ?? () from /usr/lib/libgobject-2.0.so.0
#13 0xb6935c33 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#14 0xb6936256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#15 0xb6ec0566 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#16 0xb6d8cff0 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xb6b1184b in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#18 0xb6b3aad4 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#19 0xb6b0dfa3 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#20 0xb6b0ffbf in gdk_window_process_all_updates ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib/libgdk-x11-2.0.so.0
#21 0xb6b1003b in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#22 0xb6aec358 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#23 0xb686f661 in ?? () from /lib/libglib-2.0.so.0
#24 0xb68715e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#25 0xb68752d8 in ?? () from /lib/libglib-2.0.so.0
#26 0xb68754b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#27 0xb7b51884 in nsAppShell::ProcessNextNativeEvent (this=0xb5419100,
    mayWait=1) at nsAppShell.cpp:147
#28 0xb7b66fe4 in nsBaseAppShell::DoProcessNextNativeEvent (this=0xb5419100,
    mayWait=1) at nsBaseAppShell.cpp:151
#29 0xb7b67188 in nsBaseAppShell::OnProcessNextEvent (this=0xb5419100,
    thr=0xb5da4830, mayWait=1, recursionDepth=0) at nsBaseAppShell.cpp:296
#30 0xb7c342f7 in nsThread::ProcessNextEvent (this=0xb5da4830, mayWait=1,
    result=0xbffff0dc) at nsThread.cpp:508
#31 0xb7c02f0f in NS_ProcessNextEvent_P (thread=0xa7260e40, mayWait=1)
    at nsThreadUtils.cpp:250
#32 0xb7b67296 in nsBaseAppShell::Run (this=0xb5419100)
    at nsBaseAppShell.cpp:170
#33 0xb7a29a40 in nsAppStartup::Run (this=0xb54dcc10) at nsAppStartup.cpp:183
#34 0xb7373a84 in XRE_main (argc=1, argv=0xbffff664, aAppData=0xb5d18380)
    at nsAppRunner.cpp:3506
#35 0xb7ff59c3 in main (argc=1, argv=0xbffff664) at nsBrowserApp.cpp:158

[vandyswa (ajv-cauriumbin)]

FYI, I've come across Red Hat Bugzilla defect 575314 which might be related.

[Sebastien Bacher (seb128)]

Thank you for your bug report, do you have anything special on your configurations?

[vandyswa (ajv-cauriumbin)]

That's the weird part--no, this is a brand new, stock KUbuntu install. We see the failure on both thin clients as well as right on the console. No fancy font packages installed, nor alternative libraries or special builds. We also see it on multiple browsers. I have debugging symbols and the source pulled, so I'll see what I can find out from examining a failed process, since it sounds like this is only being reported sporadically from the field. Note that this *is* a quad core i7, so it might be a threading thing.