Bug 622375

Created attachment 375989 [details]
backtrace of a crash with gdk_x_error: RenderBadPictrue

Created attachment 375994 [details]
backtrace of a crash with gdk_x_error: RenderBadPicture + some "up" + p *...

May be it's something like this:

<http://mail.gnome.org/archives/gtk-app-devel-list/2006-April/msg00255.html>  ?


Are you using threads? If so... You may have to protect the gtk calls
you make inside the timeout function using gtk_threads_enter/leave()
pair... I haven't bothered to look into the long backtrace... So it is
just an assumption...

timeout functions are not called within the GTK lock.

timeout_fn(...)
{
   other_call();
   ....
   gtk_threads_enter();
   my_gtk_call();
   gtk_threads_leave();
}

Regards,
Santhosh.

The RenderBadPicture is known bug: https://bugzilla.mozilla.org/show_bug.cgi?id=522635#c21

The bug https://bugzilla.mozilla.org/show_bug.cgi?id=522635#c26 
mentions a "minimal fix". I see that fix in the source of
seamonkey-2.0.6-2.1.x86_64. ( obs://build.opensuse.org/mozilla )

But it still crashes. May be it crashes less often but it still
crashes.

The opensuse package seamonkey-2.0.6-2.1.x86_64 crashes.

I tried the official package:
http://ftp.df.lth.se/mozilla/seamonkey/releases/2.0.6/linux-i686/en-US/seamonkey-2.0.6.tar.bz2

rpm -e seamonkey
tar xjvf seamonkey-2.0.6.tar.bz2 -C /usr/share/
cd /usr/share/seamonkey
./seamonkey

The official 2.0.6 package does not crash.
( It's a 32bit package with a lot o local libraries )

I am also seeing this on x86 with seamonkey, but not firefox.  I haven't tried eclipse or any other xulrunner apps on 11.3 yet (see e.g. bug #623444).  Debian, Arch, and Ubuntu all seem to have the same bug with cairo > 1.8.8 and xulrunner 1.9.1 or seamonkey.

If I've read the various bugs correctly, the reason the official binary doesn't crash is because it doesn't use --enable-system-cairo.  If backporting the 1.9.2 fix doesn't work, perhaps this is a reasonable solution?

This works fine for openSUSE 11.3 x86_64
with seamonkey 2.0.6-2.2 :

seamonkey.spec:
...
-ac_add_options --enable-system-cairo 
+ac_add_options --disable-system-cairo 
...

I don't know if any comfortable features are lost. But the crashes had made
the work already really bad.

Thanks for checking this out. There is/was another issue which would turn up when we use the internal cairo.
This is basically sorted out and I'll drive switching to internal cairo asap (either 11.4 or even for security updates given this bugreport).

I just upgraded from openSUSE 11.2 to 11.3 today and am now experiencing this bug with seamonkey-2.0.6-2.3.x86_64.

There is another Mozilla bug report which is relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=557785

This also looks somewhat similar to https://bugzilla.novell.com/show_bug.cgi?id=626042 although the status there is 172 / 152 / 7.  That one is triggered by closing Tabs.

I'm also experiencing those crashes couple of time a day.

The program 'seamonkey-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'RenderBadPicture (invalid Picture parameter)'.
  (Details: serial 4087814 error_code 172 request_code 152 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.)


I'm using OpenSUSE 11.3 x86_64.
# rpm -qf `which seamonkey`
seamonkey-2.0.6-2.3.x86_64

Thanks,
  Sagi.

I can confirm that rebuilding the RPM with --disable-system-cairo, as reported in Comment 8, solves this problem.  Provided this doesn't adversely affect anything else, is there any chance the spec file could be updated and a new official RPM published for openSUSE 11.3?  This bug means that the currently packaged SeaMonkey for 11.3 is pretty useless; waiting for 11.4 isn't going to be an option for most users, and many don't have the technical know-how to patch the spec file and rebuild the RPM themselves.

I've just prepared a new package (probably still building) in the OBS mozilla repository for immediate update possibilities.
I'm planning to release the switch to internal cairo with next security update.

I have just updated the bug referred to in comment 11 - which is almost certainly the problem addressed in comment 12 - saying that the new package referenced in comment 14 appears to have solved bug 626042.
Two for the price of one?

seamonkey 2.0.8/2.0.7 solved my problems.
:)

Who has to update the status of the bug? Me or somebody who does qa?

Have a nice day.

I implemented the fix, so I can and if you like you can "verify" (I think).

Set bug to verified. seamonkey-2.0.8-23.1.x86_64 works fine.

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

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

Closing as fixed.