Last Comment Bug 522635 - RenderBadPicture fatal error closing tab
: RenderBadPicture fatal error closing tab
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: Trunk
: x86 Linux
: P2 normal with 3 votes (vote)
: mozilla1.9.3a1
Assigned To: Karl Tomlinson (ni?:karlt)
:
Mentors:
http://motionandcolor.com/wrapper/
: 510867 542173 557785 591503 (view as bug list)
Depends on: 528386
Blocks: 528115 509895
  Show dependency treegraph
 
Reported: 2009-10-15 20:35 PDT by Karl Tomlinson (ni?:karlt)
Modified: 2010-12-08 13:32 PST (History)
23 users (show)
mbeltzner: blocking1.9.2+
karlt: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
beta3-fixed
.16-fixed


Attachments
destroy child nsWindows when destroying the parent (7.16 KB, patch)
2009-10-30 13:30 PDT, Karl Tomlinson (ni?:karlt)
roc: review+
Details | Diff | Review
(Big) patch for 1.9.1 (53.75 KB, patch)
2010-02-25 23:56 PST, Mike Hommey [:glandium]
mbeltzner: approval1.9.1.11-
Details | Diff | Review
minimal branch patch (2.18 KB, patch)
2010-10-07 07:43 PDT, Martin Stránský
karlt: review+
christian: approval1.9.1.16+
Details | Diff | Review

Description Karl Tomlinson (ni?:karlt) 2009-10-15 20:35:17 PDT
STR:
1. Open a new tab
2. In the new tab, load http://www.mozilla.org/
3. In the same tab, load http://motionandcolor.com/wrapper/
4. Click back.
5. Close the tab.

Results:

The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'RenderBadPicture (invalid Picture parameter)'.
  (Details: serial 118640 error_code 161 request_code 149 minor_code 7)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

#0  gdk_x_error (display=0x7f8fcd151000, error=0x7fffdd40cec0)
    at gdkmain-x11.c:614
#1  0x00007f8fd140af90 in _XError (dpy=0x7f8fcd151000, 
    rep=<value optimized out>) at XlibInt.c:2924
#2  0x00007f8fd1411f19 in process_responses (dpy=0x7f8fcd151000, 
    wait_for_first_event=0, current_error=0x7fffdd40d038, 
    current_request=118641) at xcb_io.c:207
#3  0x00007f8fd141253b in _XReply (dpy=0x7f8fcd151000, rep=0x7fffdd40d080, 
    extra=0, discard=1) at xcb_io.c:457
#4  0x00007f8fd1406aba in XSync (dpy=0x7f8fcd151000, discard=0) at Sync.c:48
#5  0x00007f8fd1406c34 in _XSyncFunction (dpy=0x7f8fcd151000) at Synchro.c:37
#6  0x00007f8fc6d8a2c2 in _cairo_xlib_surface_finish (
    abstract_surface=0x7f8f8ee56400)
    at /home/karl/moz/dev/gfx/cairo/cairo/src/cairo-xlib-surface.c:341
#7  0x00007f8fc6d6785e in *INT__moz_cairo_surface_finish (
    surface=0x7f8f8ee56400)
    at /home/karl/moz/dev/gfx/cairo/cairo/src/cairo-surface.c:537
#8  0x00007f8fc6d676cf in *INT__moz_cairo_surface_destroy (
    surface=0x7f8f8ee56400)
    at /home/karl/moz/dev/gfx/cairo/cairo/src/cairo-surface.c:440
#9  0x00007f8fc6d02ee3 in gfxASurface::Release (this=0x7f8f8eee6b40)
    at /home/karl/moz/dev/gfx/thebes/src/gfxASurface.cpp:106
#10 0x00007f8fc631516e in nsRefPtr<gfxASurface>::assign_assuming_AddRef (
    this=0x7f8fa9cd2cb8, newPtr=0x0) at ../../../dist/include/nsAutoPtr.h:944
#11 0x00007f8fc631519d in nsRefPtr<gfxASurface>::assign_with_AddRef (
    this=0x7f8fa9cd2cb8, rawPtr=0x0) at ../../../dist/include/nsAutoPtr.h:928
#12 0x00007f8fc63151bd in nsRefPtr<gfxASurface>::operator= (
    this=0x7f8fa9cd2cb8, rhs=0x0) at ../../../dist/include/nsAutoPtr.h:1003
#13 0x00007f8fc6311441 in nsWindow::Destroy (this=0x7f8fa9cd2ba0)
    at /home/karl/moz/dev/widget/src/gtk2/nsWindow.cpp:790
#14 0x00007f8fc7b277dd in ~nsView (this=0x7f8fa86ce100)
    at /home/karl/moz/dev/view/src/nsView.cpp:253
#15 0x00007f8fc7b253ef in nsIView::Destroy (this=0x7f8fa86ce100)
    at /home/karl/moz/dev/view/src/nsView.cpp:294
#16 0x00007f8fc7663f8d in nsFrame::Destroy (this=0x7f8f8f0a10e8)
    at /home/karl/moz/dev/layout/generic/nsFrame.cpp:470
#17 0x00007f8fc76ce3c6 in nsSplittableFrame::Destroy (this=0x7f8f8f0a10e8)
    at /home/karl/moz/dev/layout/generic/nsSplittableFrame.cpp:73
#18 0x00007f8fc764d90b in nsContainerFrame::Destroy (this=0x7f8f8f0a10e8)
    at /home/karl/moz/dev/layout/generic/nsContainerFrame.cpp:308
#19 0x00007f8fc76ead38 in ViewportFrame::Destroy (this=0x7f8f8f0a10e8)
    at /home/karl/moz/dev/layout/generic/nsViewportFrame.cpp:68
#20 0x00007f8fc75e10a9 in nsFrameManager::Destroy (this=0x7f8f8ee5ac38)
    at /home/karl/moz/dev/layout/base/nsFrameManager.cpp:290
#21 0x00007f8fc76104db in PresShell::Destroy (this=0x7f8f8ee5ac00)
    at /home/karl/moz/dev/layout/base/nsPresShell.cpp:1904
#22 0x00007f8fc75c8195 in DocumentViewerImpl::DestroyPresShell (
    this=0x7f8f8ee49c80)
    at /home/karl/moz/dev/layout/base/nsDocumentViewer.cpp:4350
#23 0x00007f8fc75cf23a in DocumentViewerImpl::Destroy (this=0x7f8f8ee49c80)
    at /home/karl/moz/dev/layout/base/nsDocumentViewer.cpp:1572
#24 0x00007f8fb2eb35ac in nsSHistory::EvictContentViewersInRange (
    this=0x7f8faa674280, aStart=0, aEnd=2)
    at /home/karl/moz/dev/docshell/shistory/src/nsSHistory.cpp:881
#25 0x00007f8fb2eb3895 in nsSHistory::EvictAllContentViewers (
    this=0x7f8faa674280)
    at /home/karl/moz/dev/docshell/shistory/src/nsSHistory.cpp:672
#26 0x00007f8fb2e44ca0 in nsDocShell::Destroy (this=0x7f8fc90ca400)
    at /home/karl/moz/dev/docshell/base/nsDocShell.cpp:4303
#27 0x00007f8fc78cf938 in nsFrameLoader::Finalize (this=0x7f8faa416bc0)
    at /home/karl/moz/dev/content/base/src/nsFrameLoader.cpp:302
#28 0x00007f8fc78a8f1c in nsDocument::MaybeInitializeFinalizeFrameLoaders (
    this=0x7f8fad154000)
    at /home/karl/moz/dev/content/base/src/nsDocument.cpp:5228
#29 0x00007f8fc78acf89 in nsDocument::EndUpdate (this=0x7f8fad154000, 
    aUpdateType=1) at /home/karl/moz/dev/content/base/src/nsDocument.cpp:3769
#30 0x00007f8fc7b10a51 in nsXULDocument::EndUpdate (this=0x7f8fad154000, 
    aUpdateType=1)
    at /home/karl/moz/dev/content/xul/document/src/nsXULDocument.cpp:3358
#31 0x00007f8fc7673a5c in ~mozAutoDocUpdate (this=0x7fffdd40d8b0)
    at ../../../dist/include/mozAutoDocUpdate.h:66
#32 0x00007f8fc78e6283 in nsGenericElement::doRemoveChildAt (aIndex=1, 
    aNotify=1, aKid=0x7f8faa59f1c0, aParent=0x7f8fabc81400, 
    aDocument=0x7f8fad154000, aChildArray=@0x7f8fabc81438, aMutationEvent=1)
    at /home/karl/moz/dev/content/base/src/nsGenericElement.cpp:3398
#33 0x00007f8fc78e6366 in nsGenericElement::RemoveChildAt (
    this=0x7f8fabc81400, aIndex=1, aNotify=1, aMutationEvent=1)
    at /home/karl/moz/dev/content/base/src/nsGenericElement.cpp:3321
#34 0x00007f8fc7d7b384 in nsXULElement::RemoveChildAt (this=0x7f8fabc81400, 
    aIndex=1, aNotify=1, aMutationEvent=1)
    at /home/karl/moz/dev/content/xul/content/src/nsXULElement.cpp:984
#35 0x00007f8fc78dc305 in nsGenericElement::doRemoveChild (
    aOldChild=0x7f8faa59f200, aParent=0x7f8fabc81400, 
    aDocument=0x7f8fad154000, aReturn=0x7fffdd40dd00)
    at /home/karl/moz/dev/content/base/src/nsGenericElement.cpp:4039
#36 0x00007f8fc78dc371 in nsGenericElement::RemoveChild (this=0x7f8fabc81400, 
    aOldChild=0x7f8faa59f200, aReturn=0x7fffdd40dd00)
    at /home/karl/moz/dev/content/base/src/nsGenericElement.cpp:3558
#37 0x00007f8fc7d7ea8f in nsXULElement::RemoveChild (this=0x7f8fabc81400, 
    oldChild=0x7f8faa59f200, _retval=0x7fffdd40dd00)
    at /home/karl/moz/dev/content/xul/content/src/nsXULElement.h:571
#38 0x00007f8fc86d7163 in nsIDOMNode_RemoveChild (cx=0x7f8fb33b6000, argc=1, 
    vp=0x7f8f8edf62a8) at dom_quickstubs.cpp:2943
#39 0x00007f8fd4a8c17d in js_Interpret (cx=0x7f8fb33b6000)
    at /home/karl/moz/dev/js/src/jsops.cpp:2166
#40 0x00007f8fd4a9e32d in js_Invoke (cx=0x7f8fb33b6000, argc=1, 
    vp=0x7f8f8edf6040, flags=0) at /home/karl/moz/dev/js/src/jsinterp.cpp:1372
#41 0x00007f8fd4a9eb36 in js_InternalInvoke (cx=0x7f8fb33b6000, 
    obj=0x7f8fc103e5c0, fval=140254774822720, flags=0, argc=1, 
    argv=0x7f8f8edf6038, rval=0x7fffdd40ecb0)
    at /home/karl/moz/dev/js/src/jsinterp.cpp:1427
#42 0x00007f8fd4a0f320 in JS_CallFunctionValue (cx=0x7f8fb33b6000, 
    obj=0x7f8fc103e5c0, fval=140254774822720, argc=1, argv=0x7f8f8edf6038, 
    rval=0x7fffdd40ecb0) at /home/karl/moz/dev/js/src/jsapi.cpp:5131
#43 0x00007f8fc7b40f6c in nsJSContext::CallEventHandler (this=0x7f8fc107c8e0, 
    aTarget=0x7f8faa494d00, aScope=0x7f8fb33a6cc0, aHandler=0x7f8f9c080740, 
    aargv=0x7f8f8ec9c8b0, arv=0x7fffdd40eef0)
    at /home/karl/moz/dev/dom/base/nsJSEnvironment.cpp:2092
#44 0x00007f8fc7bbfeb1 in nsJSEventListener::HandleEvent (
    this=0x7f8f8ec97fb0, aEvent=0x7f8f8ec84df8)
    at /home/karl/moz/dev/dom/src/events/nsJSEventListener.cpp:247
#45 0x00007f8fc7aee8fe in nsXBLPrototypeHandler::ExecuteHandler (
    this=0x7f8fabbc5e80, aTarget=0x7f8faa494d00, aEvent=0x7f8f8ec84df8)
    at /home/karl/moz/dev/content/xbl/src/nsXBLPrototypeHandler.cpp:343
#46 0x00007f8fc7ae8362 in nsXBLEventHandler::HandleEvent (
    this=0x7f8fabb0d900, aEvent=0x7f8f8ec84df8)
    at /home/karl/moz/dev/content/xbl/src/nsXBLEventHandler.cpp:88
#47 0x00007f8fc7958bac in nsEventListenerManager::HandleEventSubType (
    this=0x7f8fab9c2ea0, aListenerStruct=0x7f8fb43c4ed8, 
    aListener=0x7f8fabb0d900, aDOMEvent=0x7f8f8ec84df8, 
    aCurrentTarget=0x7f8faa494d00, aPhaseFlags=6)
    at /home/karl/moz/dev/content/events/src/nsEventListenerManager.cpp:1034
#48 0x00007f8fc79590fa in nsEventListenerManager::HandleEvent (
    this=0x7f8fab9c2ea0, aPresContext=0x7f8fad194000, aEvent=0x7fffdd40fb60, 
    aDOMEvent=0x7fffdd40f850, aCurrentTarget=0x7f8faa494d00, aFlags=6, 
    aEventStatus=0x7fffdd40f858)
    at /home/karl/moz/dev/content/events/src/nsEventListenerManager.cpp:1140
#49 0x00007f8fc7982c84 in nsEventTargetChainItem::HandleEvent (
    this=0x7f8fad86aa80, aVisitor=@0x7fffdd40f840, aFlags=6, 
    aMayHaveNewListenerManagers=1)
    at /home/karl/moz/dev/content/events/src/nsEventDispatcher.cpp:244
#50 0x00007f8fc7982fca in nsEventTargetChainItem::HandleEventTargetChain (
    this=0x7f8fad86a578, aVisitor=@0x7fffdd40f840, aFlags=6, 
    aCallback=0x7fffdd40f980, aMayHaveNewListenerManagers=1)
    at /home/karl/moz/dev/content/events/src/nsEventDispatcher.cpp:308
#51 0x00007f8fc798382d in nsEventDispatcher::Dispatch (
    aTarget=0x7f8faa494d00, aPresContext=0x7f8fad194000, 
    aEvent=0x7fffdd40fb60, aDOMEvent=0x0, aEventStatus=0x7fffdd41044c, 
    aCallback=0x7fffdd40f980)
    at /home/karl/moz/dev/content/events/src/nsEventDispatcher.cpp:539
#52 0x00007f8fc76053c8 in PresShell::HandleEventInternal (
    this=0x7f8fad194400, aEvent=0x7fffdd40fb60, aView=0x0, 
    aStatus=0x7fffdd41044c)
    at /home/karl/moz/dev/layout/base/nsPresShell.cpp:6302
#53 0x00007f8fc7605c8b in PresShell::HandleEventWithTarget (
    this=0x7f8fad194400, aEvent=0x7fffdd40fb60, aFrame=0x7f8fb437fa90, 
    aContent=0x7f8faa494d00, aStatus=0x7fffdd41044c)
    at /home/karl/moz/dev/layout/base/nsPresShell.cpp:6177
#54 0x00007f8fc795fb1e in nsEventStateManager::CheckForAndDispatchClick (
    this=0x7f8fad8259b0, aPresContext=0x7f8fad194000, aEvent=0x7fffdd4107a0, 
    aStatus=0x7fffdd41044c)
    at /home/karl/moz/dev/content/events/src/nsEventStateManager.cpp:3881
#55 0x00007f8fc7968857 in nsEventStateManager::PostHandleEvent (
    this=0x7f8fad8259b0, aPresContext=0x7f8fad194000, aEvent=0x7fffdd4107a0, 
    aTargetFrame=0x7f8fb437fa90, aStatus=0x7fffdd41044c, aView=0x7f8fad141180)
    at /home/karl/moz/dev/content/events/src/nsEventStateManager.cpp:2859
#56 0x00007f8fc76055a0 in PresShell::HandleEventInternal (
    this=0x7f8fad194400, aEvent=0x7fffdd4107a0, aView=0x7f8fad141180, 
    aStatus=0x7fffdd41044c)
    at /home/karl/moz/dev/layout/base/nsPresShell.cpp:6323
#57 0x00007f8fc7605e65 in PresShell::HandlePositionedEvent (
    this=0x7f8fad194400, aView=0x7f8fad141180, aTargetFrame=0x7f8fb437fa90, 
    aEvent=0x7fffdd4107a0, aEventStatus=0x7fffdd41044c)
    at /home/karl/moz/dev/layout/base/nsPresShell.cpp:6160
#58 0x00007f8fc76069fb in PresShell::HandleEvent (this=0x7f8fad194400, 
    aView=0x7f8fad141180, aEvent=0x7fffdd4107a0, aEventStatus=0x7fffdd41044c)
    at /home/karl/moz/dev/layout/base/nsPresShell.cpp:6024
#59 0x00007f8fc7b2c13c in nsViewManager::HandleEvent (this=0x7f8fad19a1a0, 
    aView=0x7f8fad141180, aPoint={x = -582941168, y = 32767}, 
    aEvent=0x7fffdd4107a0, aCaptured=0)
    at /home/karl/moz/dev/view/src/nsViewManager.cpp:1195
#60 0x00007f8fc7b308b3 in nsViewManager::DispatchEvent (this=0x7f8fad19a1a0, 
    aEvent=0x7fffdd4107a0, aView=0x7f8fad141180, aStatus=0x7fffdd4106d4)
    at /home/karl/moz/dev/view/src/nsViewManager.cpp:1174
#61 0x00007f8fc7b25e56 in HandleEvent (aEvent=0x7fffdd4107a0)
    at /home/karl/moz/dev/view/src/nsView.cpp:167
#62 0x00007f8fc631182a in nsWindow::DispatchEvent (this=0x7f8fad89cd40, 
    aEvent=0x7fffdd4107a0, aStatus=@0x7fffdd41081c)
    at /home/karl/moz/dev/widget/src/gtk2/nsWindow.cpp:584
#63 0x00007f8fc630d0af in nsWindow::OnButtonReleaseEvent (
    this=0x7f8fad89cd40, aWidget=0x7f8fb3383e80, aEvent=0x7f8f9c07c2e0)
    at /home/karl/moz/dev/widget/src/gtk2/nsWindow.cpp:2840

I don't seem to be able reproduce with Firefox 3.5.3.

Likely the same issue discussed here (in a bug report for a different bug):

http://bugs.freedesktop.org/show_bug.cgi?id=21583#c16
Comment 1 Karl Tomlinson (ni?:karlt) 2009-10-15 20:39:00 PDT
The cairo surface being destroyed is using the window for the drawable, and is
releasing the dst_picture

http://hg.mozilla.org/mozilla-central/annotate/4046f3843bdb/gfx/cairo/cairo/src/cairo-xlib-surface.c#l296

(gdb) f 6
#6  0x00007f8fc6d8a2c2 in _cairo_xlib_surface_finish (
    abstract_surface=0x7f8f8ee56400)
    at /home/karl/moz/dev/gfx/cairo/cairo/src/cairo-xlib-surface.c:341
(gdb) p *surface
$376 = {base = {backend = 0x7f8fc70987e0, type = CAIRO_SURFACE_TYPE_XLIB, 
    content = CAIRO_CONTENT_COLOR, ref_count = {ref_count = 0}, 
    status = CAIRO_STATUS_SUCCESS, finished = 0, user_data = {size = 1, 
      num_elements = 1, element_size = 24, elements = 0x7f8f8eee7438, 
      is_snapshot = 0}, mime_data = {size = 0, num_elements = 0, 
      element_size = 24, elements = 0x0, is_snapshot = 0}, 
    device_transform = {xx = 1, yx = 0, xy = 0, yy = 1, x0 = 0, y0 = 0}, 
    device_transform_inverse = {xx = 1, yx = 0, xy = 0, yy = 1, x0 = -0, 
      y0 = -0}, x_resolution = 72, y_resolution = 72, 
    x_fallback_resolution = 300, y_fallback_resolution = 300, 
    clip = 0x7f8f8f0d9260, next_clip_serial = 1, current_clip_serial = 1, 
    is_snapshot = 0, has_font_options = 0, font_options = {
      antialias = 2779096485, subpixel_order = 2779096485, 
      hint_style = 2779096485, hint_metrics = 2779096485}}, 
  dpy = 0x7f8fcd151000, display = 0x7f8fac641c10, 
  screen_info = 0x7f8fac6163d0, close_display_hook = {prev = 0x7f8f9bfdb520, 
    next = 0x7f8f8ed5cd20, 
    func = 0x7f8fc6d8f5f2 <_cairo_xlib_surface_detach_display>}, 
  gc = 0x7f8f8ef0ea60, drawable = 44044608, screen = 0x7f8fcd139180, 
  owns_pixmap = 0, visual = 0x7f8fcd11f470, use_pixmap = 0, render_major = 0, 
  render_minor = 10, buggy_repeat = 0, width = 1069, height = 619, 
  depth = 24, dst_picture = 44045647, src_picture = 0, clip_dirty = 0, 
  have_clip_rects = 0, gc_has_clip_rects = 0, embedded_clip_rects = {{x = 0, 
      y = 0, width = 1069, height = 619}, {x = -23131, y = -23131, 
      width = 42405, height = 42405}, {x = -23131, y = -23131, width = 42405, 
      height = 42405}, {x = -23131, y = -23131, width = 42405, 
      height = 42405}, {x = -23131, y = -23131, width = 42405, 
      height = 42405}, {x = -23131, y = -23131, width = 42405, 
      height = 42405}, {x = -23131, y = -23131, width = 42405, 
      height = 42405}, {x = -23131, y = -23131, width = 42405, 
      height = 42405}}, clip_rects = 0x7f8f8ee5659c, num_clip_rects = 0, 
  xrender_format = 0x7f8fcd0fc940, filter = CAIRO_FILTER_NEAREST, repeat = 0, 
  xtransform = {matrix = {{65536, 0, 0}, {0, 65536, 0}, {0, 0, 65536}}}, 
  a_mask = 0, r_mask = 16711680, g_mask = 65280, b_mask = 255}

The drawable of that surface is the Window of the nsIWidget being destroyed
but that Window has already been destroyed, probably when a parent nsIWidget
was destroyed:

http://hg.mozilla.org/mozilla-central/annotate/4046f3843bdb/widget/src/gtk2/nsWindow.cpp#l760

(gdb) f 13
#13 0x00007f8fc6311441 in nsWindow::Destroy (this=0x7f8fa9cd2ba0)
    at /home/karl/moz/dev/widget/src/gtk2/nsWindow.cpp:790
(gdb) p *(GdkWindowObject*)mGdkWindow
$386 = {parent_instance = {parent_instance = {g_type_instance = {
        g_class = 0x7f8fcd179540}, ref_count = 2, qdata = 0x7f8f8ed4a180}}, 
  impl = 0x7f8f8f018700, parent = 0x0, user_data = 0x0, x = 0, y = 0, 
  extension_events = 0, filters = 0x0, children = 0x0, bg_color = {pixel = 0, 
    red = 0, green = 0, blue = 0}, bg_pixmap = 0x2, paint_stack = 0x0, 
  update_area = 0x0, update_freeze_count = 0, window_type = 2 '\002', 
  depth = 24 '\030', resize_count = 0 '\0', 
  state = GDK_WINDOW_STATE_WITHDRAWN, guffaw_gravity = 0, input_only = 0, 
  modal_hint = 0, composited = 0, destroyed = 1, accept_focus = 1, 
  focus_on_map = 1, shaped = 0, event_mask = 176910, 
  update_and_descendants_freeze_count = 0, redirect = 0x0}
(gdb) p *(GdkWindowImplX11*)((GdkWindowObject*)mGdkWindow)->impl
$388 = {parent_instance = {parent_instance = {parent_instance = {
        g_type_instance = {g_class = 0x7f8fcd1798c0}, ref_count = 1, 
        qdata = 0x0}}, wrapper = 0x7f8f8f018340, colormap = 0x7f8fcd139400, 
    xid = 44044608, screen = 0x7f8fcd107000, picture = 0, 
    cairo_surface = 0x0}, width = 1069, height = 619, position_info = {x = 0, 
    y = 0, width = 1069, height = 619, x_offset = 0, y_offset = 0, big = 0, 
    mapped = 1, no_bg = 0, clip_rect = {x = 0, y = 0, width = 1069, 
      height = 619}}, toplevel = 0x0, cursor = 0x0, 
  toplevel_window_type = -1 'ÿ', override_redirect = 0, 
  use_synchronized_configure = 0, damage = 0}
(gdb) p *this
$389 = (nsChildWindow) {<nsWindow> = {<nsBaseWidget> = {<nsIWidget> = {<nsISupports> = {_vptr.nsISupports = 0x7f8fc6599730}, mFirstChild = {
          mRawPtr = 0x7f8f8ef61050}, mLastChild = 0x7f8f8ef61050, 
        mNextSibling = {mRawPtr = 0x0}, mPrevSibling = 0x0}, mRefCnt = {
        mValue = 2}, _mOwningThread = {mThread = 0x7f8fcd110040}, 
      mClientData = 0x0, mEventCallback = 0x7f8fc7b25dea <HandleEvent>, 
      mContext = 0x7f8f8ef0ef60, mToolkit = 0x7f8fb43ed400, 
      mBackground = 2779096485, mForeground = 2779096485, 
      mCursor = eCursor_standard, mWindowType = eWindowType_child, 
      mBorderStyle = eBorderStyle_default, mOnDestroyCalled = 0 '\0', 
      mBounds = {x = 0, y = 0, width = 1069, height = 619}, 
      mOriginalBounds = 0x0, mClipRects = {mRawPtr = 0x0}, 
      mClipRectCount = 0, mZIndex = 0, 
      mSizeMode = nsSizeMode_Normal}, <nsSupportsWeakReference> = {<nsISupportsWeakReference> = {<nsISupports> = {
          _vptr.nsISupports = 0x7f8fc6599a68}, <No data fields>}, 
      mProxy = 0x0}, mOldFocusWindow = 0, mIMEData = 0x7f8fb33ab820, 
    mParent = {mRawPtr = 0x0}, mIsTopLevel = 0 '\0', mIsDestroyed = 1 '\001', 
    mNeedsResize = 0 '\0', mNeedsMove = 0 '\0', mListenForResizes = 1 '\001', 
    mIsShown = 0 '\0', mNeedsShow = 0 '\0', mEnabled = 1 '\001', 
    mCreated = 0 '\0', mPlaced = 1 '\001', mShell = 0x0, mContainer = 0x0, 
    mGdkWindow = 0x7f8f8f018340, mWindowGroup = 0x0, mContainerGotFocus = 0, 
    mContainerLostFocus = 0, mContainerBlockFocus = 0, mCanBeSeen = 0, 
    mRetryPointerGrab = 0, mRetryKeyboardGrab = 0, mTransientParent = 0x0, 
    mSizeState = 0, mPluginType = nsWindow::PluginType_NONE, 
    mTransparencyBitmapWidth = 0, mTransparencyBitmapHeight = 0, 
    mThebesSurface = {mRawPtr = 0x0}, mRootAccessible = {mRawPtr = 0x0}, 
    mIsTransparent = 0, mTransparencyBitmap = 0x0, mDragMotionWidget = 0x0, 
    mDragMotionContext = 0x0, mDragMotionX = 0, mDragMotionY = 0, 
    mDragMotionTime = 0, mDragMotionTimerID = 0, mDragLeaveTimer = {
      mRawPtr = 0x0}, mLastMotionPressure = 0, 
    mLastSizeMode = nsSizeMode_Normal, mKeyDownFlags = {0, 0, 0, 0, 0, 0, 0, 
      0}}, <No data fields>}

I suspect we might need to call Destroy() on all nsIWidgets associated with
child native windows.  (Currently we only call Destroy() on the nsIWidgets in
the nsIWidget child list which is not all children of the native window.)
Comment 2 Karl Tomlinson (ni?:karlt) 2009-10-15 20:47:55 PDT
Also affects
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b1pre) Gecko/20091014 Namoroka/3.6b1pre
Comment 3 robertojimenoca 2009-10-17 06:16:17 PDT
I can consistently trigger this bug using the steps in this bug in:
Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.1.3) Gecko/20090928 Iceweasel/3.5.3
using cairo 1.9.4 but I can not trigger it using cairo 1.8.8
What cairo version are you using?

See this bug:
http://bugs.freedesktop.org/show_bug.cgi?id=21583
Comment 4 Joe Drew (not getting mail) 2009-10-29 10:48:57 PDT
This looks like a Cairo bug. Jeff, can you take responsibility for rolling in the fix to the fd.o bug Roberto posted above?
Comment 5 Jeff Muizelaar [:jrmuizel] 2009-10-29 10:52:23 PDT
(In reply to comment #4)
> This looks like a Cairo bug. Jeff, can you take responsibility for rolling in
> the fix to the fd.o bug Roberto posted above?

Yes.
Comment 6 Chris AtLee [:catlee] 2009-10-29 12:12:24 PDT
Doesn't crash for me using the steps in comment #1.

Linux x64, namoroka nightly 20091029061700
Comment 7 Karl Tomlinson (ni?:karlt) 2009-10-29 13:44:24 PDT
Still happens for me x86_64 nightly built from
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/61e9a14a8819
Comment 8 Karl Tomlinson (ni?:karlt) 2009-10-29 13:59:39 PDT
(In reply to comment #4)
> This looks like a Cairo bug. Jeff, can you take responsibility for rolling in
> the fix to the fd.o bug Roberto posted above?

The fd.o bug is for bug 263160, which is unrelated to this bug, but that report contains a number of comments about this bug.

This bug is a bug in Gecko.  Gecko is creating a cairo xlib surface wrapper around a Window, but destroying the Window before destroying the wrapper.

Evidence suggests that the crash has been triggered (or at least made more likely) by a change in cairo.  However, even if we back out that change in our cairo, this bug will resurface when distros update their cairos.

(In reply to comment #3)
> I can consistently trigger this bug using the steps in this bug in:
> Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.1.3) Gecko/20090928
> Iceweasel/3.5.3
> using cairo 1.9.4 but I can not trigger it using cairo 1.8.8
> What cairo version are you using?

Mozilla 1.9.2 uses a cairo based on b71b019fe50a9188ddbecd1945606da8ba3bad53

http://hg.mozilla.org/releases/mozilla-1.9.2/file/61e9a14a8819/gfx/cairo/cairo/src/cairo-features.h.in
claims this is 1.7.4 but that must be wrong.
Comment 9 Karl Tomlinson (ni?:karlt) 2009-10-30 13:30:51 PDT
Created attachment 409402 [details] [diff] [review]
destroy child nsWindows when destroying the parent

This seems to fix the problem.  It makes sense to me to destroy descendant
nsWindows when their native Windows are getting destroyed, and I think this
behavior might resemble the OnDestroy behavior of windows\nsWindow.cpp.
Comment 10 Karl Tomlinson (ni?:karlt) 2009-10-30 13:33:15 PDT
Though the question is begged:
Why hold a reference mThebesSurface to the surface if it will be recreated
each time it is used anyway?

The "we should fix this at some point" comment was removed here:
http://hg.mozilla.org/mozilla-central/rev/ef0221c2a188#l12.606

The fix with the smallest change looks like it is to just remove
mThebesSurface.  (But ensuring child nsWindows are Destroy()ed might enable us to reuse mThebesSurface at some point.)
Comment 11 Karl Tomlinson (ni?:karlt) 2009-11-09 20:13:20 PST
Comment on attachment 409402 [details] [diff] [review]
destroy child nsWindows when destroying the parent

This seems sensible to me for m-c, at least.
Comment 12 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-11-10 13:35:36 PST
(In reply to comment #10)
> Though the question is begged:

Sorry to be pedantic, but this is an incorrect use of the phrase "begging the question" :-)
Comment 13 Karl Tomlinson (ni?:karlt) 2009-11-10 13:47:22 PST
"Arguments over whether such usage should be considered incorrect are an example of debate over linguistic prescription and description."
http://en.wikipedia.org/wiki/Begging_the_question#Modern_usage
Comment 14 Karl Tomlinson (ni?:karlt) 2009-11-10 16:58:25 PST
http://hg.mozilla.org/mozilla-central/rev/5aa509dd5c5d
Comment 15 Karl Tomlinson (ni?:karlt) 2009-11-10 16:59:29 PST
I should be able to come up with a (browser?) crashtest-mochitest for this I expect.
Comment 16 Mike Beltzner [:beltzner, not reading bugmail] 2009-11-11 08:27:19 PST
Please either land with that crashtest or file a follow up to get the tests done.
Comment 17 Karl Tomlinson (ni?:karlt) 2009-11-11 19:11:26 PST
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/53af277ed12f
Comment 18 Mike Hommey [:glandium] 2010-02-25 06:08:24 PST
FWIW, this fix (+ bug 506433) is not enough to stop 1.9.1 "crashing" with system cairo 1.8.10, though it "crashes" less often. I'm currently trying to build 1.9.2 to see if I can reproduce there in which case I may need to backport more, or if that still happens.
Comment 19 Mike Hommey [:glandium] 2010-02-25 07:08:13 PST
Seems bug 528386 is what I was missing.
Comment 20 Karl Tomlinson (ni?:karlt) 2010-02-25 19:22:30 PST
*** Bug 542173 has been marked as a duplicate of this bug. ***
Comment 21 Mike Hommey [:glandium] 2010-02-25 23:56:01 PST
Created attachment 429069 [details] [diff] [review]
(Big) patch for 1.9.1

FWIW, this is what I apply on 1.9.1, which is a combination of (backported) bug 506433, bug 522635 and bug 528386. (I thought reducing the number of gdkwindows was a worthwhile change)
Comment 22 Micah Gersten 2010-05-05 15:50:15 PDT
Comment on attachment 429069 [details] [diff] [review]
(Big) patch for 1.9.1

Would it be possible to get this on 1.9.1?  We have this issue with Seamonkey in Lucid.
Comment 23 Ian Neal 2010-05-05 16:12:27 PDT
(In reply to comment #22)
> (From update of attachment 429069 [details] [diff] [review])
> Would it be possible to get this on 1.9.1?  We have this issue with Seamonkey
> in Lucid.

This will probably impact Fedora 13 which is due out in May too.
Comment 24 Mike Beltzner [:beltzner, not reading bugmail] 2010-05-21 13:16:45 PDT
Comment on attachment 429069 [details] [diff] [review]
(Big) patch for 1.9.1

This is a really big patch, and a backport of all of those other bugs would require them to be nominated to land on mozilla-1.9.1 as well.

Is there a way to get a more minimal fix? Right now I think the risk outweighs the potential reward, here.
Comment 25 Mike Beltzner [:beltzner, not reading bugmail] 2010-05-21 13:17:40 PDT
If this regressed after 1.9.1.3, can we figure out what regressed it and maybe back that out?
Comment 26 Karl Tomlinson (ni?:karlt) 2010-05-21 15:08:43 PDT
(In reply to comment #25)
> If this regressed after 1.9.1.3, can we figure out what regressed it and maybe
> back that out?

I think the change was in the system cairo.

(In reply to comment #24)
> Is there a way to get a more minimal fix?

Removing mThebesSurface would be a safe minimal fix for branch (Comment 10).
Comment 27 Karl Tomlinson (ni?:karlt) 2010-05-21 15:10:19 PDT
If someone knows a reliable way to reproduce, please let me know.
I've had trouble writing a test for this because the site changed and I haven't come up with another way to reproduce.
Comment 28 Karl Tomlinson (ni?:karlt) 2010-05-25 14:38:50 PDT
*** Bug 510867 has been marked as a duplicate of this bug. ***
Comment 29 Samuel Sieb 2010-06-09 13:23:25 PDT
Can we get the minimal fix from comment 10 applied to 1.9.1?  This is affecting Seamonkey on Fedora 13 and other recent distributions.  See bug 557785.
Comment 30 Bernie Innocenti 2010-07-01 05:11:11 PDT
Can someone point me at the patch? I need to backport it to Fedora 11 for OLPC.

Yes, we ship really old stuff :-(
Comment 31 Ian Neal 2010-07-01 09:13:19 PDT
(In reply to comment #30)
> Can someone point me at the patch? I need to backport it to Fedora 11 for OLPC.
> 
> Yes, we ship really old stuff :-(

As far as I am aware Fedora 11 doesn't ship with a system cairo 1.8.10+ (I believe it is 1.8.8 which is not affected).
Comment 32 Bernie Innocenti 2010-07-01 11:36:53 PDT
(In reply to comment #31)

> As far as I am aware Fedora 11 doesn't ship with a system cairo 1.8.10+ (I
> believe it is 1.8.8 which is notnot affected).

You're right, F-11 is not affected. We're seeing the issue only on Fedora 13.
Comment 33 Mason 2010-08-26 04:27:14 PDT
As far as I can tell, this bug is responsible for 30-50 Seamonkey 2.0.x crash reports in Fedora 13 (seamonkey-2.0.6-1.fc13, cairo-1.8.10-1.fc13).

Seamonkey crashes often
https://bugzilla.redhat.com/show_bug.cgi?id=602437

This bug is marked RESOLVED. If I understand correctly, it was fixed in Gecko 1.9.2, but was not fixed in Gecko 1.9.1, and Seamonkey 2.0.x is built on the older Gecko? Is that correct?

Is this the appropriate place to discuss the problem, or should I file a new bug for Seamonkey, pointing to this bug?
Comment 34 Karl Tomlinson (ni?:karlt) 2010-08-26 04:54:39 PDT
That sounds correct and this is the right place to discuss.
IIRC, a patch that removed mThebesSurface from nsWindow would fix this.
Comment 35 Mike Hommey [:glandium] 2010-08-26 05:01:21 PDT
While I agree with comment 24, I'd just like to point out that tens of thousands of Debian users have been using the mentioned patch for six months without any bad feedback.
Comment 36 Mason 2010-08-27 16:22:38 PDT
I have opened bug 591503 in which I describe two methods that crash Seamonkey consistently for me. I can provide stack traces of the other running threads if necessary.
Comment 37 Karl Tomlinson (ni?:karlt) 2010-08-30 15:04:08 PDT
*** Bug 591503 has been marked as a duplicate of this bug. ***
Comment 38 Mason 2010-08-31 01:35:49 PDT
(In reply to comment #37)
> *** Bug 591503 has been marked as a duplicate of this bug. ***

Karl,

The back trace you provide in your original report is different from the one I attached in bug 591503. Are you confident it is the same bug?

AFAIU, bug 522635 was RESOLVED FIXED on the gecko trunk, which means gecko 1.9.2.x contains the fix, but the 1.9.1 branch still has the flaw. Should this bug be REOPENED with Version set to "1.9.1 branch" or should bug 591503 be used to track the progress of fixing the 1.9.1 branch?
Comment 39 Karl Tomlinson (ni?:karlt) 2010-08-31 02:23:39 PDT
(In reply to comment #38)
> The back trace you provide in your original report is different from the one I
> attached in bug 591503. Are you confident it is the same bug?

The one attached to bug 591503 is not from running the app with --sync and doesn't have enough information to confirm it is the same bug.

But I'm confident that Gecko 1.9.1 with system-cairo > 1.8.8 will display this bug.

> Should this
> bug be REOPENED with Version set to "1.9.1 branch" or should bug 591503 be used
> to track the progress of fixing the 1.9.1 branch?

Neither.  This bug will track the status on 1.9.1 branch until the status-1.9.1 flag changes.
Comment 40 Mason 2010-08-31 13:18:13 PDT
(In reply to comment #39)
> The one attached to bug 591503 is not from running the app with --sync and
> doesn't have enough information to confirm it is the same bug.

I've attached a new back trace to bug 591503 running with --sync

(I don't know if it's relevant) In your back trace, the nsView destructor is called by nsIView::Destroy (frames #14 - #15), whereas in mine, the nsView destructor is called by the nsScrollPortView destructor (frames #21 - #22).

> Neither.  This bug will track the status on 1.9.1 branch until the
> status-1.9.1 flag changes.

If I understand correctly, "status1.9.2: beta3-fixed" means this bug was fixed for gecko 1.9.2 in version beta-3. Is that correct?

And when (one can dream, right?) it is fixed for gecko 1.9.1, the status will be changed to something like "status1.9.1: 13-fixed" ?

RESOLVED FIXED only means the bug is fixed on the trunk?
Comment 41 Karl Tomlinson (ni?:karlt) 2010-08-31 13:36:29 PDT
(In reply to comment #40)
> And when (one can dream, right?) it is fixed for gecko 1.9.1, the status will
> be changed to something like "status1.9.1: 13-fixed" ?
> 
> RESOLVED FIXED only means the bug is fixed on the trunk?

Yes, that's right.
Comment 42 Mason 2010-09-06 09:59:05 PDT
Karl,

Is fixing this bug (on the 1.9.1 branch) an item on one of your TODO lists for the coming weeks?
Comment 43 Karl Tomlinson (ni?:karlt) 2010-09-06 14:30:55 PDT
No.  I'll review a patch if someone puts one up.
Or distros can apply Mike's patch if they are using system cairo.
Comment 44 Mason 2010-10-02 04:32:49 PDT
I'm confused: I downloaded the Linux/x86_64 version of Seamonkey 2.0.7 from the project's page. (Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100825 SeaMonkey/2.0.7)

I ran ldd on Fedora's seamonkey-bin and on Mozilla's seamonkey-bin; they link exactly to the same dynamic libraries (only the addresses changes).

For example, the three relevant (I think) libraries:

Fedora:
libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f46a58b0000)
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f46a5665000)
libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f46a53ec000)

Mozilla:
libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f91d1364000)
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f91d1119000)
libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f91d0ea0000)

/usr/lib64/libcairo.so.2 is system cairo, right?

Both versions seem to link the same cairo library, yet Fedora's version crashes, while Mozilla's version does not. How would one explain this?
Comment 45 Chris Coulson 2010-10-02 06:09:36 PDT
Yes, both versions are linked to cairo as a consequence of linking to GTK. However, the Mozilla build is still using it's internal tree cairo.
Comment 46 Martin Stránský 2010-10-07 07:43:21 PDT
Created attachment 481492 [details] [diff] [review]
minimal branch patch
Comment 47 Mason 2010-10-08 01:11:23 PDT
Karl,

Will Martin's proposed fix now land on the gecko 1.9.1 branch?
Or does it still need super-review?
(If so, from who? roc? vladimir? someone else?)
Comment 48 Mason 2010-10-13 07:20:28 PDT
I must be missing something. Martin's proposed fix is tiny compared to Mike Hommey's patch. Do they both fix the problem in gecko 1.9.1?

What does Mike's patch do that Martin's patch doesn't?
Comment 49 Mike Hommey [:glandium] 2010-10-13 07:36:22 PDT
(In reply to comment #48)
> I must be missing something. Martin's proposed fix is tiny compared to Mike
> Hommey's patch. Do they both fix the problem in gecko 1.9.1?
> 
> What does Mike's patch do that Martin's patch doesn't?

See comment 21 and comment 26.
Comment 50 Karl Tomlinson (ni?:karlt) 2010-10-13 14:35:20 PDT
Comment on attachment 481492 [details] [diff] [review]
minimal branch patch

Requesting approval for 1.9.1, mostly for SeaMonkey on distributions that build with system cairo.

It's a small patch, but changes semantics a little.

With XPCOM's ref-counting system, objects typically need to be AddRefed and Released to be deleted.  Without this patch nsWindow would do this and so the object would get deleted even if the caller did not.  With this patch callers must AddRef and Release.

The change actually makes the behavior consistent with cocoa and winnt's GetThebesSurface().

I checked that existing callers (in 1.9.1 mozilla-central) AddRef and Release.

nsBaseWidget::GetRenderingContext()
  > nsThebesRenderingContext::Init(nsIDeviceContext*, gfxASurface*)
    > gfxContext

nsThebesDeviceContext::CreateRenderingContext()

nsThebesRenderingContext::Init(nsIDeviceContext*, nsIWidget*)
  > gfxContext
Comment 51 Karl Tomlinson (ni?:karlt) 2010-10-21 19:19:34 PDT
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/16357bcadb6f
Comment 52 Mason 2010-10-26 02:40:30 PDT
According to the bug's history, Karl added "status1.9.1: .15-fixed" five
days ago : https://bugzilla.mozilla.org/show_activity.cgi?id=522635

However, in my browser, I see "status1.9.1: .16-fixed"

How did the "status" field change without the bug's history being updated?
Comment 53 Karl Tomlinson (ni?:karlt) 2010-10-26 15:46:16 PDT
(In reply to comment #52)
> How did the "status" field change without the bug's history being updated?

Sometimes labels get renamed when an extra release is squeezed in.
Looks like Firefox 3.5.15 is one of them.
https://wiki.mozilla.org/Platform/2010-10-26#Notices_.2F_Schedule
Comment 54 Philip Chee 2010-12-08 13:32:01 PST
*** Bug 557785 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.