Closed Bug 522635 Opened 15 years ago Closed 15 years ago

RenderBadPicture fatal error closing tab

Categories

(Core :: Widget: Gtk, defect, P2)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta3-fixed
status1.9.1 --- .16-fixed

People

(Reporter: karlt, Assigned: karlt)

References

()

Details

(Keywords: regression)

Attachments

(3 files)

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
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.)
Keywords: regression
Assignee: nobody → mozbugz
Also affects
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b1pre) Gecko/20091014 Namoroka/3.6b1pre
Flags: blocking1.9.2?
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
This looks like a Cairo bug. Jeff, can you take responsibility for rolling in the fix to the fd.o bug Roberto posted above?
(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.
Doesn't crash for me using the steps in comment #1.

Linux x64, namoroka nightly 20091029061700
Still happens for me x86_64 nightly built from
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/61e9a14a8819
(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.
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.
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.)
Blocks: 509895
Whiteboard: [should block]
Comment on attachment 409402 [details] [diff] [review]
destroy child nsWindows when destroying the parent

This seems sensible to me for m-c, at least.
Attachment #409402 - Flags: review?(roc)
(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" :-)
"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
http://hg.mozilla.org/mozilla-central/rev/5aa509dd5c5d
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
I should be able to come up with a (browser?) crashtest-mochitest for this I expect.
Flags: in-testsuite?
Please either land with that crashtest or file a follow up to get the tests done.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Blocks: 528115
Depends on: 528386
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.
Seems bug 528386 is what I was missing.
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 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.
Attachment #429069 - Flags: approval1.9.1.11?
Attachment #429069 - Flags: approval1.9.1.10?
(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 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.
Attachment #429069 - Flags: approval1.9.1.11?
Attachment #429069 - Flags: approval1.9.1.11-
Attachment #429069 - Flags: approval1.9.1.10?
If this regressed after 1.9.1.3, can we figure out what regressed it and maybe back that out?
(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).
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.
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.
Can someone point me at the patch? I need to backport it to Fedora 11 for OLPC.

Yes, we ship really old stuff :-(
(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).
(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.
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?
That sounds correct and this is the right place to discuss.
IIRC, a patch that removed mThebesSurface from nsWindow would fix this.
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.
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.
(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?
(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.
(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?
(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.
Karl,

Is fixing this bug (on the 1.9.1 branch) an item on one of your TODO lists for the coming weeks?
No.  I'll review a patch if someone puts one up.
Or distros can apply Mike's patch if they are using system cairo.
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?
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.
Attachment #481492 - Flags: review?(karlt) → review+
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?)
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?
(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 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
Attachment #481492 - Flags: approval1.9.1.15?
Attachment #481492 - Flags: approval1.9.1.15? → approval1.9.1.15+
Keywords: checkin-needed
Whiteboard: [should block] → [c-n 1.9.1]
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?
(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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: