Bug 602437

(In reply to comment #0)
> Seamonkey crashes randomly and often.  I suspect all the F13 abrt reports are
> this issue.  I will link the upstream bug numbers.  The problem is in the gecko
> engine.  Firefox uses a newer version so the bug has been fixed.  Seamonkey is
> still using 1.9.1.    

I am not sure about expected outcome of this bug.

Do I understand you correctly you plan this to be a tracker bug for all those crashes, or is this "please upgrade Seamonkey to the latest Gecko"?

Sorry, somehow I didn't end up CCed on this bug.  There is no progress on the upstream mozilla bug, so would it be possible to apply a patch?  I got the patch from the gecko bug that was fixed and created my own rpm with it.  I've had no problems since.  I will attach it here.

Created attachment 426162 [details]
patch for cairo issue

Copy of comment from https://bugzilla.mozilla.org/show_bug.cgi?id=522635#c21

 Mike Hommey [:glandium]      2010-02-25 23:56:01 PST

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

This bug has a large number of active dupes, e.g.

bug 590288
bug 608473
bug 618674
bug 620259

Basically, every Fedora 13 Seamonkey crasher report seems to be a dupe of this bug.

https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&version=13&component=seamonkey&product=Fedora

Martin, will you have time to test and apply Samuel's proposed patch?

Does one need specific permission bits to mark bugs as dupes? I am willing to examine Seamonkey crasher reports and look for dupes.

Let's handle the bug upstream, we don't want to take extra patches unless it's really necessary.

Martin,

Could you elaborate what you mean by "Let's handle the bug upstream".

I've posted a comment in Mozilla's Bugzilla.
https://bugzilla.mozilla.org/show_bug.cgi?id=522635#c33

This bug seems to impact many distributions, e.g. Suse.
https://bugzilla.novell.com/show_bug.cgi?id=622375

Someone suggested that building Seamonkey with --disable-system-cairo works around the problem. What would we lose by disabling cairo?

Would you consider publishing a Seamonkey package with cairo support disabled?

seamonkey-2.0.6-1.fc13 was built with --enable-system-cairo
http://koji.fedoraproject.org/koji/buildinfo?buildID=184669

system cairo is cairo-1.8.10-1.fc13
http://koji.fedoraproject.org/koji/buildinfo?buildID=157825
http://cairographics.org/news/cairo-1.8.10/

Seamonkey 2.0.x ships with a private version of cairo 1.8.8
http://mxr.mozilla.org/comm-1.9.1/search?string=CAIRO_VERSION&find=configure

As far as I understand, the bug does not trigger when Seamonkey is linked against cairo 1.8.8.

Martin, would it be possible for Fedora to publish a Seamonkey build where system-cairo has been disabled?

Can you reproduce the bug with reproduction steps from https://bugzilla.mozilla.org/show_bug.cgi?id=522635#c0 ?

Martin,

I do have a reproducible test case.

First, configure Seamonkey to load http://www.google.com/
when a new tab is opened.

Steps to reproduce:
1. Hit Ctrl+T 5 times in a row (open 5 tabs)
2. Hit Ctrl+W 5 times in a row (close the 5 tabs)

Repeat until Seamonkey crashes.
(It crashes consistently, in less than 30 seconds, for me.)

Do you confirm?

(Adding cairo-1.8.10-1.fc13 maintainer to CC list, because the proposed work-around is to ignore the system cairo library.)

Created attachment 441615 [details]
Full back trace for the crashing thread

I ran the procedure several times, and got this backtrace 4 times.
(I did try to disable address space randomization.)

NB: buf in gdk_x_error (function #7) contains:
"RenderBadPicture (invalid Picture parameter)"

Created attachment 441619 [details]
Full back trace of crash upon exit

I also get a similar but different back trace when Seamonkey crashes after I close the last window to exit the application.

NB:
o frames #1-18 are similar (same call stack)
o frame #7 still has buf = "RenderBadPicture (invalid Picture parameter)"
o functions at frame #19 are different:
NS_ProcessNextEvent_P( ) vs NS_ProcessPendingEvents_P( )

I will try and find a reproducible test case for this crasher.
(Probably involves opening a few tabs, and quitting.)

Here is the procedure to get the second crasher consistently.

First make sure Seamonkey is set up to load http://www.google.com/
when a new tab is opened.

1. Start Seamonkey
2. Hit Ctrl+T 5 times in a row (open  5 tabs)
3. Hit Ctrl+W 2 times in a row (close 2 tabs)
4. Hit Ctrl+T 2 times in a row (open  2 tabs)
5. Hit Ctrl+Shift+W (close the whole window)
6. Hit Q to quit Seamonkey without saving
7. Crash

Can anyone confirm?

Martin,

Do you want me to check the database, and mark as DUP every report with the
same back trace as this bug? (I will need the appropriate permission bits.)

Martin,

Seamonkey 2.0.7 is expected soon.

I don't think "upstream" will be fixing the problem this fast.

Will you, please, consider building Seamonkey 2.0.7 with --disable-system-cairo?

(In other words, don't use the system-wide cairo library.)

Where is the build script stored? (I will submit a patch for it.)

Martin,

I have provided a procedure to crash Seamonkey consistently.

Do you agree that, as a work-around, the next Seamonkey release (2.0.7)
should be built with mozilla's private libcairo?

For a fast-moving distro like Fedora, this frequent and repeatable crasher with several plausable workaround options leaves many Fedora users with a frustrating experience.  I'm sure progress on making a fix to the end users would be appreciated by many.  I can build/modify packages -- if you need help testing, please don't hesitate ask, but I don't want to work on a solution that will be rejected and thus, be a waste of time.  Thanks!

Ubuntu has just fixed the issue by applying Mike Hommey's patch.
https://bugs.launchpad.net/ubuntu/+bug/575160

Thus, AFAIU, there are two proposed fixes; either apply this patch OR build Seamonkey 2.0.8 with --disable-system-cairo

Martin, are you still involved with this bug, or should the "Assigned To" field be updated?

Martin,

I see you've built Seamonkey 2.0.8 on Wed, 22 Sep 2010 14:19:24 UTC.
(As far as I can tell, you ignored my request to --disable-system-cairo)
I will test the new release and report back.

This new build crashes exactly like the previous build, meaning all the suggestions have been ignored. I fail to see the point of releasing security fixes for software that crashes within minutes.

Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.13) Gecko/20100922 Fedora/2.0.8-1.fc13 SeaMonkey/2.0.8

$ seamonkey --sync

Gdk-ERROR **: 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 48298 error_code 156 request_code 147 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.)
aborting...
/usr/lib64/seamonkey-2.0.8/run-mozilla.sh: line 131:  2694 Aborted                 (core dumped) "$prog" ${1+"$@"}

There's a new test scratch build here - http://koji.fedoraproject.org/koji/taskinfo?taskID=2520259

Created attachment 452138 [details]
Comment out --enable-system-cairo

* Wed Sep 06 2006 Kai Engert <kengert> 1.0.4-7
- Use --enable-system-cairo

Kai, do you remember why you added --enable-system-cairo 4 years ago? :-)

Apparently, SUSE picked the --disable-system-cairo solution.
https://bugzilla.novell.com/show_bug.cgi?id=622375#c13

Martin, I will test the scratch build ASAP.

I installed the test build with yum.
yum --nogpgcheck install seamonkey-2.0.8-2.fc13.x86_64.rpm

Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.13) Gecko/20101007 Fedora/2.0.8-2.fc13 SeaMonkey/2.0.8

This build does not crash when I follow the steps given in comment 10 and comment 14. I will try and test it more thoroughly, in real-life use, over the week end. Thank you, Martin.

Looks like the problem still exists -- see bug 639500.

The test version is seamonkey-2.0.8-2.fc13, not seamonkey-2.0.8-1.fc13 from Bug 639500.

seamonkey-2.0.8-2.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/seamonkey-2.0.8-2.fc13

seamonkey-2.0.8-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update seamonkey'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/seamonkey-2.0.8-2.fc13

Comment on attachment 452138 [details]
Comment out --enable-system-cairo

I wasn't aware of Fedora's strict "No Bundled Libraries" policy until I read Martin's comment in a separate mozilla bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=577653#c9
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

I understand why you didn't use the simple work-around. (I've removed the review request for my patch.)

For the record, clegnitto@mozilla accepted Martin's patch a few days ago.
The patch is tagged "approval1.9.1.15+" (with gecko 1.9.1.15 due soon).

Tested: seamonkey-2.0.8-2.fc13.x86_64

Tried reproducing bug using comment#10 and comment#14 and combinations thereof. Could not get seamonkey to crash :D

I've also had an excellent experience - no crashes since updating:
rpm -q --qf="%{installtime:date} %{name}-%{version}-%{release}.%{arch}\n" seamonkey
Fri 08 Oct 2010 10:29:54 AM EDT seamonkey-2.0.8-2.fc13.x86_64

seamonkey-2.0.8-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

I think Seamonkey 2.0.10 will include Martin's patch in the source tarball, thus the patch won't be necessary in the Fedora package anymore.

I've just been prompted to update to Seamonkey 2.0.10-1.fc13.  Can anyone here confirm that this update includes the fix for this bug?  I'm currently running the testing version described in Comment 29, so I don't want to update to 2.0.10-1 if it doesn't have the fix.

(In reply to comment #36)
> I've just been prompted to update to Seamonkey 2.0.10-1.fc13.  Can anyone here
> confirm that this update includes the fix for this bug?  I'm currently running
> the testing version described in Comment 29, so I don't want to update to
> 2.0.10-1 if it doesn't have the fix.

No crashes here - so I'd say it is fixed for me.