Bug #531719 “Eclipse crashes using content assist with libcairo2...” : Bugs : eclipse package : Ubuntu

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-10-15:

#1

Download full text (6.8 KiB)

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_cla...

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.)

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-10-15:

#2

Also affects
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b1pre) Gecko/20091014 Namoroka/3.6b1pre

Revision history for this message

In Mozilla Bugzilla #522635, Roberto Jimeno (robertojimenoca) wrote on 2009-10-17:

#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?

See this bug:
http://bugs.freedesktop.org/show_bug.cgi?id=21583

Revision history for this message

In Mozilla Bugzilla #522635, Joe-drew (joe-drew) wrote on 2009-10-29:

#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?

Revision history for this message

In Mozilla Bugzilla #522635, Jmuizelaar (jmuizelaar) wrote on 2009-10-29:

#5

(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.

Revision history for this message

In Mozilla Bugzilla #522635, Catlee (catlee) wrote on 2009-10-29:

#6

Doesn't crash for me using the steps in comment #1.

Linux x64, namoroka nightly 20091029061700

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-10-29:

#7

Still happens for me x86_64 nightly built from
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/61e9a14a8819

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-10-29:

#8

(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.

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-10-30:

#9

Created an attachment (id=409402)
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.

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-10-30:

#10

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.)

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-11-09:

#11

(From update of attachment 409402)
This seems sensible to me for m-c, at least.

Revision history for this message

In Mozilla Bugzilla #522635, Roc-ocallahan (roc-ocallahan) wrote on 2009-11-10:

#12

(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" :-)

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-11-10:

#13

"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

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-11-10:

#14

http://hg.mozilla.org/mozilla-central/rev/5aa509dd5c5d

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-11-10:

#15

I should be able to come up with a (browser?) crashtest-mochitest for this I expect.

Revision history for this message

In Mozilla Bugzilla #522635, Beltzner (beltzner) wrote on 2009-11-11:

#16

Please either land with that crashtest or file a follow up to get the tests done.

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2009-11-11:

#17

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/53af277ed12f

Revision history for this message

In Mozilla Bugzilla #522635, Mh+mozilla (mh+mozilla) wrote on 2010-02-25:

#18

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.

Revision history for this message

In Mozilla Bugzilla #522635, Mh+mozilla (mh+mozilla) wrote on 2010-02-25:

#19

Seems bug 528386 is what I was missing.

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-02-25:

#20

*** Bug 542173 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #522635, Mh+mozilla (mh+mozilla) wrote on 2010-02-25:

#21

Created an attachment (id=429069)
(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)

Revision history for this message

Tristan Tarrant (tristan-tarrant-gmail) wrote on 2010-03-04: Eclipse crashes on content assist

#22

Binary package hint: xulrunner

The recent upgrade to libcairo2-1.8.10-2ubuntu1 exposes a bug in xulrunner 1.9.1 (the upstream bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=522635).
In the case of Eclipse, this causes a crash when the extra documentation popup disappears from the right of the content-assist popup menu (i.e. when an item is selected and the menu is no longer needed).
If I set the environment variable GRE_HOME to some nonsense path, Eclipse works fine (it uses a simpler rendering technique for the documentation window).
Installing xulrunner 1.9.2 (I used the mozilla-daily ppa) fixes the problem. Since several packages depend on xulrunner (yelp, couchdb-bin, eclipse-platform, miro, libgjs0, gnome-shell, etc) it would be advisable to upgrade xulrunner to prevent the bug from appearing in the LTS.

ProblemType: Bug
Architecture: amd64
Date: Thu Mar 4 05:26:48 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release Candidate amd64 (20091020.3)
NonfreeKernelModules: nvidia
Package: xulrunner (not installed)
ProcEnviron:
PATH=(custom, user)
LANG=en_US.utf8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-15.22-generic
SourcePackage: xulrunner
Uname: Linux 2.6.32-15-generic x86_64

Revision history for this message

Micah Gersten (micahg) wrote on 2010-03-04:

#23

Thank you for reporting this. We will be releasing xulrunner-1.9.2 into Lucid before the release. Please report any other bugs you may find.

affects:	xulrunner (Ubuntu) → xulrunner-1.9.1 (Ubuntu)
Changed in xulrunner-1.9.1 (Ubuntu):
assignee:	nobody → Micah Gersten (micahg)
importance:	Undecided → Medium
milestone:	none → ubuntu-10.04-beta-1
status:	New → Triaged
importance:	Medium → High

Revision history for this message

Kristian Rink (kawazu) wrote on 2010-03-05:

#24

Are there any workarounds known for that so far?

Revision history for this message

Tristan Tarrant (tristan-tarrant-gmail) wrote on 2010-03-05:

#25

Aren't the two methods I explained in my first comment working for you ?

Revision history for this message

gronbaek (gronbaek) wrote on 2010-03-06:

#26

I have followed Tristan's advice and have added the mozilla.daily ppa to my repositories and installed xul-runner 1.9.3. This works for me. If you experience the same problems, try to make sure that Eclipse is using xul-runner 1.9.3, and not your default version, by running Eclipse with the xul-runner path specified: "eclipse -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/bin/xulrunner-1.9.3"

Micah Gersten (micahg) on 2010-03-07

summary:	- Eclipse crashes on content assist + Eclipse crashes with xulrunner-1.9.1
summary:	- Eclipse crashes with xulrunner-1.9.1 + Eclipse crashes using content assist
summary:	- Eclipse crashes using content assist + Eclipse crashes using content assist with libcairo2 1.8.10

Bug Watch Updater (bug-watch-updater) on 2010-03-08

Changed in xulrunner:
status:	Unknown → Fix Released

Revision history for this message

Andrea Chiavazza (andrea-c7a) wrote on 2010-03-08:

#27

Setting GRE_HOME=. works for me.

Revision history for this message

dl.zerocool (dl.zerocool) wrote on 2010-03-09:

#28

Followed this : https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.1/+bug/531719/comments/26
and it worked, but very annoying... Hope it will be soon solved.

Revision history for this message

Björn Seifert (bjoern.seifert) wrote on 2010-03-09:

#29

Now that xulrunner -1.9.2 replaces 1.9.1 everything is fine again, thanks!
https://launchpad.net/ubuntu/lucid/+source/xulrunner-1.9.2/1.9.2+nobinonly-0ubuntu1

Fixed for me.

Revision history for this message

Mike van Straten (mike-van-straten) wrote on 2010-03-09:

#30

I have followed Tristan's advice also and it works fine with xulrunner 1.9.3. It does not work with the xulrunner that was shipped today (i.e. xulrunner-1.9.1.9pre)

Revision history for this message

Andrea Chiavazza (andrea-c7a) wrote on 2010-03-11:

#31

The 1.9.2 update fixed it for me too.

Revision history for this message

Olaf Krische (public-ecopatz) wrote on 2010-03-11:

#32

Update today fixed it for me too.

Revision history for this message

Micah Gersten (micahg) wrote on 2010-03-11:

#33

We'll be rebuilding eclipse against xulrunner-1.9.2 soon which should fix this for everyone in Lucid.

Changed in xulrunner-1.9.2 (Ubuntu):
importance:	Undecided → High
status:	New → Fix Released
Changed in xulrunner-1.9.1 (Ubuntu):
assignee:	Micah Gersten (micahg) → nobody
milestone:	ubuntu-10.04-beta-1 → none

Revision history for this message

Andrea Chiavazza (andrea-c7a) wrote on 2010-03-12:

#34

if the patch released fixes the bug for me should I set the bug as "not affecting me" ?
Does it make any difference to people keeping track of bugs ?

Revision history for this message

Micah Gersten (micahg) wrote on 2010-03-12: Re: [Bug 531719] Re: Eclipse crashes using content assist with libcairo2 1.8.10

#35

Shouldn't make a difference in this case as xulrunner-1.9.1 most likely
will not be patched for this.

On 03/11/2010 06:50 PM, Andrea Chiavazza wrote:
> if the patch released fixes the bug for me should I set the bug as "not affecting me" ?
> Does it make any difference to people keeping track of bugs ?
>
>

Revision history for this message

fejes (anthony-fejes) wrote on 2010-03-15:

#36

I seem to have had both 1.9 and 1.9.2 installed: (Tested with "dpkg -l xulrunner*")

ii xulrunner-1.9 1.9.0.14+build2+nobinonly-0ubuntu1 XUL + XPCOM application runner
ii xulrunner-1.9-gnome-support 1.9.0.14+build2+nobinonly-0ubuntu1 Support for Gnome in xulrunner-1.9 applications
rc xulrunner-1.9.1 1.9.1.8+build1+nobinonly-0ubuntu1 XUL + XPCOM application runner
un xulrunner-1.9.1-gnome-support <none> (no description available)
ii xulrunner-1.9.2 1.9.2+nobinonly-0ubuntu1 XUL + XPCOM application runner

Removing 1.9 fixed the problem for me:

sudo apt-get remove xulrunner-1.9

Revision history for this message

Andrew Cowie (afcowie) wrote on 2010-05-02:

#37

Removing xulrunner-1.9.1 along the lines as suggested in comment #36 fixed the problem here. Upgrading to eclipse 3.5.2-2 did *not*.

AfC

Revision history for this message

In Mozilla Bugzilla #522635, Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing) wrote on 2010-05-05:

#38

(From update of attachment 429069)
Would it be possible to get this on 1.9.1? We have this issue with Seamonkey in Lucid.

Revision history for this message

In Mozilla Bugzilla #522635, Iann-bugzilla (iann-bugzilla) wrote on 2010-05-05:

#39

(In reply to comment #22)
> (From update of attachment 429069 [details])
> 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.

Revision history for this message

Micah Gersten (micahg) wrote on 2010-05-05:

#40

No longer high since xulrunner-1.9.1 was dropped from Lucid and < Lucid has cairo2 < 1.8.10

Changed in xulrunner-1.9.1 (Ubuntu):
importance:	High → Low

Revision history for this message

In Mozilla Bugzilla #522635, Beltzner (beltzner) wrote on 2010-05-21:

#41

(From update of attachment 429069)
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.

Revision history for this message

In Mozilla Bugzilla #522635, Beltzner (beltzner) wrote on 2010-05-21:

#42

If this regressed after 1.9.1.3, can we figure out what regressed it and maybe back that out?

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-05-21:

#43

(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).

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-05-21:

#44

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.

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-05-25:

#45

*** Bug 510867 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #522635, Samuel-sieb (samuel-sieb) wrote on 2010-06-09:

#46

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.

Revision history for this message

In Mozilla Bugzilla #522635, Bernie Innocenti (codewiz) wrote on 2010-07-01:

#47

Can someone point me at the patch? I need to backport it to Fedora 11 for OLPC.

Yes, we ship really old stuff :-(

Revision history for this message

In Mozilla Bugzilla #522635, Iann-bugzilla (iann-bugzilla) wrote on 2010-07-01:

#48

(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).

Revision history for this message

In Mozilla Bugzilla #522635, Bernie Innocenti (codewiz) wrote on 2010-07-01:

#49

(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.

Revision history for this message

Benjamin Drung (bdrung) wrote on 2010-07-14:

#50

eclipse_3.5.2-2ubuntu4.3.patch Edit (1.1 KiB, text/plain)

Having xulrunner-1.9.1 installed breaks eclipse. Letting eclipse conflict with xulrunner-1.9.1 is a workaround (patch attached).

Changed in eclipse (Ubuntu Lucid):
status:	New → Fix Committed

Revision history for this message

Benjamin Drung (bdrung) wrote on 2010-07-14:

#51

xulrunner-1.9.2 should remove xulrunner-1.9.1, which isn't part of lucid any more.

Revision history for this message

Martin Pitt (pitti) wrote on 2010-07-16:

#52

What's left to do for SRU here? Comment 50 should not apply any more, since xulrunner 1.9.1 is not in lucid. I'll close that task.

Changed in xulrunner-1.9.1 (Ubuntu):
status:	Triaged → Invalid
Changed in xulrunner-1.9.1 (Ubuntu Lucid):
status:	New → Invalid
Changed in xulrunner-1.9.2 (Ubuntu Lucid):
status:	New → Fix Released

Revision history for this message

Martin Pitt (pitti) wrote on 2010-07-16:

#53

eclipse was rebuilt in maverick, so I take it this is not an issue in maverick?

What remains to be done for the "fix committed" lucid eclipse task?

Changed in eclipse (Ubuntu):
status:	New → Fix Released

Revision history for this message

Martin Pitt (pitti) wrote on 2010-07-16:

#54

Ah, I just saw the eclipse upload to lucid-proposed. However, this seems wrong to me, since it's not really eclipse's fault (and also we should avoid such a huge download which essentially changes nothing for most users).

So if the problem is that some people still have the old 1.9.1 installed, then I'd rather see the conflict being added to xulrunner-1.9.2 for proper cleanup. This will benefit more people, and it's a "more correct" place than eclipse IMHO.

Changed in eclipse (Ubuntu):
status:	Fix Released → Triaged

Revision history for this message

Benjamin Drung (bdrung) wrote on 2010-07-16:

#55

OK. xulrunner-1.9.2 should conflict with xulrunner-1.9.1 to get it removed.

Revision history for this message

Jonathan Riddell (jr) wrote on 2010-07-20:

#56

rejecting eclipse upload from lucid-proposed Unapproved queue

Revision history for this message

In Mozilla Bugzilla #522635, Shill (shill) wrote on 2010-08-26:

#57

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?

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-08-26:

#58

That sounds correct and this is the right place to discuss.
IIRC, a patch that removed mThebesSurface from nsWindow would fix this.

Revision history for this message

In Mozilla Bugzilla #522635, Mh+mozilla (mh+mozilla) wrote on 2010-08-26:

#59

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.

Revision history for this message

In Mozilla Bugzilla #522635, Shill (shill) wrote on 2010-08-27:

#60

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.

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-08-30:

#61

*** Bug 591503 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #522635, Shill (shill) wrote on 2010-08-31:

#62

(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?

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-08-31:

#63

(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.

Revision history for this message

In Mozilla Bugzilla #522635, Shill (shill) wrote on 2010-08-31:

#64

(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?

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-08-31:

#65

(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.

Revision history for this message

In Mozilla Bugzilla #522635, Shill (shill) wrote on 2010-09-06:

#66

Karl,

Is fixing this bug (on the 1.9.1 branch) an item on one of your TODO lists for the coming weeks?

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-09-06:

#67

No. I'll review a patch if someone puts one up.
Or distros can apply Mike's patch if they are using system cairo.

Bug Watch Updater (bug-watch-updater) on 2010-09-18

Changed in xulrunner:
importance:	Unknown → Medium

Revision history for this message

In Mozilla Bugzilla #522635, Shill (shill) wrote on 2010-10-02:

#68

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?

Revision history for this message

In Mozilla Bugzilla #522635, Chris Coulson (chrisccoulson) wrote on 2010-10-02:

#69

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.

Revision history for this message

In Mozilla Bugzilla #522635, Stransky (stransky) wrote on 2010-10-07:

#70

Created attachment 481492
minimal branch patch

Revision history for this message

In Mozilla Bugzilla #522635, Shill (shill) wrote on 2010-10-08:

#71

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?)

Revision history for this message

In Mozilla Bugzilla #522635, Shill (shill) wrote on 2010-10-13:

#72

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?

Revision history for this message

In Mozilla Bugzilla #522635, Mh+mozilla (mh+mozilla) wrote on 2010-10-13:

#73

(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.

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-10-13:

#74

Comment on attachment 481492
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

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-10-22:

#75

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/16357bcadb6f

Revision history for this message

In Mozilla Bugzilla #522635, Shill (shill) wrote on 2010-10-26:

#76

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?

Revision history for this message

In Mozilla Bugzilla #522635, Karlt (karlt) wrote on 2010-10-26:

#77

(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

Revision history for this message

In Mozilla Bugzilla #522635, Philip-chee (philip-chee) wrote on 2010-12-08:

#78

*** Bug 557785 has been marked as a duplicate of this bug. ***

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2015-06-17:

#79

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in eclipse (Ubuntu Lucid):
status:	Fix Committed → Won't Fix

Ubuntu
eclipse package

Eclipse crashes using content assist with libcairo2 1.8.10

Bug Description

Duplicates of this bug

Other bug subscribers

Patches

Remote bug watches

	Status	Importance	Assigned to
XULRunner	Fix Released	Medium	mozilla-bugs #522635
eclipse (Ubuntu)	Triaged	Undecided	Unassigned
Lucid	Won't Fix	Undecided	Unassigned
xulrunner-1.9.1 (Ubuntu)	Invalid	Low	Unassigned
Lucid	Invalid	Undecided	Unassigned
xulrunner-1.9.2 (Ubuntu)	Fix Released	High	Unassigned
Lucid	Fix Released	Undecided	Unassigned

Ubuntueclipse package

Eclipse crashes using content assist with libcairo2 1.8.10

Bug Description

Duplicates of this bug

Other bug subscribers

Patches

Remote bug watches

Ubuntu
eclipse package