Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 602437 - Seamonkey crashes often
Seamonkey crashes often
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: seamonkey (Show other bugs)
13
All Linux
low Severity urgent
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-09 16:33 EDT by Samuel Sieb
Modified: 2018-04-11 10:14 EDT (History)
10 users (show)

See Also:
Fixed In Version: seamonkey-2.0.8-2.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-22 14:10:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for cairo issue (53.90 KB, patch)
2010-06-23 01:00 EDT, Samuel Sieb
no flags Details | Diff
Full back trace for the crashing thread (24.37 KB, text/plain)
2010-08-27 17:30 EDT, Mason
no flags Details
Full back trace of crash upon exit (24.13 KB, text/plain)
2010-08-27 17:55 EDT, Mason
no flags Details
Comment out --enable-system-cairo (420 bytes, patch)
2010-10-07 11:51 EDT, Mason
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 522635 None None None Never
Mozilla Foundation 557785 None None None Never

  None (edit)
Description Samuel Sieb 2010-06-09 16:33:56 EDT
seamonkey-2.0.4-1.fc13.i686

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.
Comment 1 Matěj Cepl 2010-06-10 02:28:47 EDT
(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"?
Comment 2 Samuel Sieb 2010-06-23 00:55:47 EDT
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.
Comment 3 Samuel Sieb 2010-06-23 01:00:10 EDT
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)
Comment 4 Mason 2010-08-26 05:23:51 EDT
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?
Comment 5 Mason 2010-08-26 06:04:45 EDT
Does one need specific permission bits to mark bugs as dupes? I am willing to examine Seamonkey crasher reports and look for dupes.
Comment 6 Martin Stransky 2010-08-26 06:12:49 EDT
Let's handle the bug upstream, we don't want to take extra patches unless it's really necessary.
Comment 7 Mason 2010-08-26 07:53:54 EDT
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?
Comment 8 Mason 2010-08-26 17:35:51 EDT
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?
Comment 9 Martin Stransky 2010-08-27 06:48:43 EDT
Can you reproduce the bug with reproduction steps from https://bugzilla.mozilla.org/show_bug.cgi?id=522635#c0 ?
Comment 10 Mason 2010-08-27 13:51:41 EDT
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.)
Comment 11 Mason 2010-08-27 17:30:37 EDT
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.)
Comment 12 Mason 2010-08-27 17:39:18 EDT
NB: buf in gdk_x_error (function #7) contains:
"RenderBadPicture (invalid Picture parameter)"
Comment 13 Mason 2010-08-27 17:55:38 EDT
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.)
Comment 14 Mason 2010-08-27 18:23:23 EDT
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?
Comment 15 Mason 2010-08-28 05:18:38 EDT
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.)
Comment 16 Mason 2010-08-31 04:54:18 EDT
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.)
Comment 17 Mason 2010-09-06 12:51:48 EDT
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?
Comment 18 Chris Schanzle 2010-10-01 18:17:50 EDT
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!
Comment 19 Mason 2010-10-02 08:03:16 EDT
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?
Comment 20 Mason 2010-10-02 08:16:10 EDT
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.
Comment 21 Mason 2010-10-02 08:59:56 EDT
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+"$@"}
Comment 22 Martin Stransky 2010-10-07 11:39:52 EDT
There's a new test scratch build here - http://koji.fedoraproject.org/koji/taskinfo?taskID=2520259
Comment 23 Mason 2010-10-07 11:51:28 EDT
Created attachment 452138 [details]
Comment out --enable-system-cairo

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

Kai, do you remember why you added --enable-system-cairo 4 years ago? :-)
Comment 24 Mason 2010-10-07 12:05:07 EDT
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.
Comment 25 Mason 2010-10-07 17:00:06 EDT
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.
Comment 26 Timur Tabi 2010-10-11 10:58:12 EDT
Looks like the problem still exists -- see bug 639500.
Comment 27 Martin Stransky 2010-10-11 11:06:02 EDT
The test version is seamonkey-2.0.8-2.fc13, not seamonkey-2.0.8-1.fc13 from Bug 639500.
Comment 28 Fedora Update System 2010-10-13 09:56:57 EDT
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
Comment 29 Fedora Update System 2010-10-14 02:31:33 EDT
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 30 Mason 2010-10-15 07:06:12 EDT
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.)
Comment 31 Mason 2010-10-18 04:15:56 EDT
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).
Comment 32 Andrew Ross 2010-10-18 19:01:31 EDT
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
Comment 33 Chris Schanzle 2010-10-18 19:59:18 EDT
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
Comment 34 Fedora Update System 2010-10-22 14:09:59 EDT
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.
Comment 35 Mason 2010-10-22 17:58:51 EDT
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.
Comment 36 Timur Tabi 2010-11-11 13:51:56 EST
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.
Comment 37 Chad Feller 2010-11-12 00:57:08 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.