Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#19005 - [seamonkey] crashes with RenderBadPicture X error

Attached to Project: Arch Linux
Opened by Michal Svoboda (pht) - Friday, 09 April 2010, 05:10 GMT
Last edited by Jan de Groot (JGC) - Tuesday, 28 September 2010, 14:58 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Since some pacman -Syu a couple of weeks ago seamonkey would start crashing at purely random times while browsing with the pesky RenderBadPicture X error. I've tracked this issue down to an incompatible version of the 'cairo' library.

Seamonkey (and mozilla in general) ships with its own (stable, tested, holy, etc) version of cairo. You can switch between the bundled and system version with the --enable-system-cairo (or so) in mozconfig. I've found out that removal of this parameter and thus usage of the internal cairo library fixes the issue.

So please change the mozconfig in the package build source in this manner. Alternatively, if you wish, pursue the issue and fix the system cairo (the one that's installed with pacman).
This task depends upon

Closed by  Jan de Groot (JGC)
Tuesday, 28 September 2010, 14:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  2.0.8-2 builds with internal cairo.
Comment by Jan de Groot (JGC) - Friday, 09 April 2010, 10:14 GMT
Building against internal cairo will never happen, as this means mozilla products will link against two versions of cairo: one from the internal tree, and one linked through GTK/Pango.
Comment by Michal Svoboda (pht) - Friday, 09 April 2010, 13:12 GMT
Yes, and I've succeeded in abs-building seamonkey that way. Even the official downloadable binary builds are done this way. If I understand correctly, the two cairos don't conflict in any way. The internal one is responsible for rendering web pages, the system one for rendering the GTK stuff - the open/save file dialogs, etc.
Comment by Bob (Cotton) - Sunday, 18 April 2010, 15:01 GMT
I confirm this bug. Its seriously irritating.
Comment by Michal Svoboda (pht) - Monday, 19 April 2010, 19:29 GMT
To work around this bug, follow these steps (approximately)

1) fetch seamonkey from abs
2) edit the mozconfig and remove the --enable-system-cairo line
3) makepkg, go get a coffee
4) install the created package with pacman
Comment by Karen (karenslfs) - Tuesday, 13 July 2010, 22:23 GMT

The work around still works but the latest update of seamonkey still has the problem. It does appear to be the system cairo being out of date vs the new Seamonkey(s) expecting to use their up to date cairo 1.9.10??? & for a while both our i686 cairo 1.8.10-1 & x86_64 cairo 1.8.10-1 were showing as out of date (no bug report allowed??) In the last few days the out of date status has now gone away again & I can't see anything in testing repo?. Seems till cairo is updated or Seamonkey's mozconfig file is amended it will need recompiling each update.
Comment by Jan de Groot (JGC) - Tuesday, 13 July 2010, 22:31 GMT
cairo 1.9 is a development snapshot, 1.8.10 is the latest stable version.
Comment by Michal Svoboda (pht) - Wednesday, 14 July 2010, 03:53 GMT
I'm so "happy" to see the maintainer still refusing the fix while people with crashing browsers have to still apply it manually after each update.

FYI back then when I was researching the problem I spoke with seamonkey people (on IRC) and they specifically told me that using any version of cairo but theirs is "unsupported and at your own risk".

Please tell me if you wanna heed their advice or continue shipping broken software for whatever (purity?) reasons.
Comment by Karen (karenslfs) - Friday, 23 July 2010, 23:46 GMT
Apologies. Updated i686 system which included new seamonkey 2.0.6-1 (bld 2010-07-22 08:01:44 UTC) update. Using seamonkey 2.0.6-1 a few hours later it crashed again. Went to do the usual work around detailed above & noted the mozconfig file has been amended from "--enable-system-cairo" to "--enable-default-toolkit=cairo-gtk2". Removed the line, recompiled & used that seamonkey for hours with no crash. Just for the exercise went back to the arch build & it crashed again within 30 mins. It's not regular so can't say what site or content does it but I did deliberately open lots of varying tabs. Result is;
(1/1) upgrading seamonkey [###################] 100%
$ sudo pacman -Q seamonkey
seamonkey 2.0.6-1
$ /usr/bin/seamonkey
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 1508862 error_code 158 request_code 148 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'll continue to use the arch build & report any further crashes
Comment by Karen (karenslfs) - Saturday, 24 July 2010, 00:24 GMT
Apologies yet again:-( OK so I just provoked it again & still no real understanding of what site or content trips it. Result is;

$ /usr/bin/seamonkey --sync
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 4347541 error_code 158 request_code 148 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.)
$ /usr/bin/seamonkey --sync
Comment by Michal Svoboda (pht) - Saturday, 24 July 2010, 05:32 GMT
You would have to run seamonkey --sync in gdb, that's how I linked the problem to cairo. It would be possible to track the bug down to the concrete bits if you did some hard work. Otherwise it seems that it just dies on random pages.
Comment by snuo (snuo) - Monday, 26 July 2010, 22:16 GMT
I think that in this case KISS should be trumped by Keep It Stable Stupid.
A constantly crashing browser in the name of principle is silly.
Comment by Jan de Groot (JGC) - Wednesday, 08 September 2010, 12:44 GMT
I suspect this is mainly caused by the XCB backend that is enabled in our cairo package. The backend is not supported upstream and hasn't received development for quite a while. I'm thinking about disabling the cairo-xcb backend, but this will mean that any users of this backend will no longer work after upgrading cairo. One example is Awesome, which directly depends on cairo-xcb.
Comment by Karen (karenslfs) - Thursday, 09 September 2010, 20:47 GMT

Thanks so much!! I've upgraded & included your new cairo from testing. I'll make sure I report any probs. with seamonkey. This is a classic example of "The Wisdom of Crowds" (James Surowiecki) & a pleasure to watch. Thanks again to all.
Comment by Karen (karenslfs) - Sunday, 12 September 2010, 01:40 GMT

I'm so sorry & I truly appreciate all that everyone has done to try to resolve this:-( So below is the lastest: the error msg is often there just after some usage, but seamonkey hasn't actually crashed.
On other occasions (like paste below) seamonkey "actually" crashes.
The recompiled one, leaving out the system cairo?? I haven't been able to generate the error msg nor crash it......... yet:-)??
Thanks again.

[............]$ sudo pacman -Q cairo seamonkey
cairo 1.10.0-1
seamonkey 2.0.7-1
[............]$ seamonkey
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 1864944 error_code 158 request_code 148 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.)
[............]$
Comment by Karen (karenslfs) - Sunday, 26 September 2010, 03:58 GMT

Just updated again & ............. apologies to all.The testing cairo still doesn't seem to help??

[ ~]$ sudo pacman -Q cairo seamonkey
cairo 1.10.0-1
seamonkey 2.0.8-1
[ ~]$ seamonkey
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 2659224 error_code 158 request_code 148 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.)
[ ~]$

Loading...