Closed Bug 325343 Opened 19 years ago Closed 18 years ago

Closing any browser window crashes Seamonkey on Linux, not Windows

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 324988

People

(Reporter: marcndd, Unassigned)

Details

(Keywords: crash)

Attachments

(1 file)

cut out the icons I found in my bookmarks.html that may be causing the problem
7.65 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

This happens to me on Ubuntu 5.10 with Seamonkey 1.0.  I was using Seamonkey alpha and beta and didn't notice it (but that might have just been luck).

I tried to reproduce with Seamonkey on Windows XP and it didn't happen there.

When I close a browser window with Seamonkey on Ubuntu it crashes and outputs this:

/usr/local/seamonkey/run-mozilla.sh: line 131: 24174 Segmentation fault      "$prog" ${1+"$@"}

The number after "line 131:" varies a bit, but the rest of the message stays the same.

This crash happens when I close the browser window with File->close or by using the close window button that the window manager puts in the upper right corner.

I almost re-opened bug 314172, but that was on Windows and this bug isn't.  More importantly, that bug said it prevented updating the profile, and I can still update the profile.  When you exit with File->quit I don't think it crashes.

Reproducible: Always

Steps to Reproduce:
1.  Open Seamonkey 1.0
2.  Open a new browser window (Window->navigator, Help->About Seamonkey, etc.)
3.  Close the browser windows (File->Close, click on "x" button in upper right corner)
Actual Results:  
Seamonkey crashes with a segmentation fault

Expected Results:  
Browser window closes but mail/news window and other browser windows stay open.

I normally always keep one mail/news and just one browser window open and just use tabs in the browser.  So while I didn't see this with Seamonkey alpha/beta that doesn't prove it was new to Seamonkey 1.0.  I noticed it when I did a "Help->About Seamonkey" to verify I was on 1.0, which opened a new browser window.  I closed it and Seamonkey crashed.
Could you install with talkback and get a talkback ID for the crash? http://kb.mozillazine.org/Talkback
Keywords: crash
Works fine for me on Linux with a self compiled cvs seamonkey. No crashes whatsoever.
In response to Adam:

I spent quite a bit of time to find out the following:

This bug doesn't seem to happen on Fedora Core 4.

This bug does also happen with Seamonkey 1.0 beta on Ubuntu 5.10.

I saw one case where I closed a browser window that didn't cause a crash (it isn't totally consistent like I thought).

Seamonkey 1.0 install doesn't offer the option to install talkback (with linux at least).

Seamonkey 1.0 beta install on linux has the option to install talkback, but on both FC4 and Ubuntu I get an error on install saying something to the effect "error 621 - error installing component talkback.xpi".  So I couldn't get talkback installed on Ubuntu or FC4 (to copy the component files to Ubuntu, where the crash happens).

Sorry, I can't work on it more at the moment, I already spent more time than I should have.
Talkback wasn't included with SeaMonkey 1.0 because the builds didn't come from MoFo tinderboxes.  It wasn't in alpha/beta, but the installer thought it was and let you select it.

Talkback is still included with trunk builds here (latest bleeding-edge code):
http://ftp.mozilla.org/pub/mozilla.org/mozilla/latest-trunk/
Version: unspecified → 1.8 Branch
Andrew,

That URL was not valid, I think you missed a "nightlies" in there.  I think I found the place you meant, but they only had Mozilla 1.7 stuff and Seamonkey alpha.

I did find Seamonkey nightlies here: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

I installed seamonkey-1.5a.en-US.linux-i686, and could not reproduce the bug.

Is there a nightly build that I could download where I could copy a few talkback component files into the seamonkey 1.0 directory (/usr/local/seamonkey) to get talkback working with my seamonkey 1.0 install?

Since people are actually following up on my bug report I would like to help track it down and get it fixed.
absolutely not!

talkback information is tied to the specific build you use. if you copy a talkback binary/extension to the wrong build, you will pollute the talkback database with garbage. please don't do that.
I downloaded the last 1.0a nightly I could find (I assume the 1.1a and 1.5a nightlies are different branches) and reproduced the problem with talkback enabled.  I mentioned this bugzilla bug number in the description, and sent it in.

I hope that you can use that data to track down the problem.  I didn't see any "talkback ID" to identify the report.

If there is some way for me to get more/better talkback info let me know, it should be easy for me to do now.
oops, yes, the link I had was totally bogus.  This one actually works:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
OK, sorry, I hadn't really sent in a talkback report yesterday.  This morning I found a "talkback manager" type window hiding behind some terminal windows.  Apparently talkback doesn't pick up proxy settings from Seamonkey itself, and it wasn't able to send in the report.

I set up the proxy, sent in the report, and there was an ID for the report and everything.  I was going to copy and paste it into a comment here.  However, that didn't work and before I could manually copy down the ID number the "talkback manager" window disappeared.

No problem, I thought, I will just duplicate the problem and get a new talkback ID number.  I did that twice, but never got that "talkback manager" window back, so I wasn't able to get an ID number.

Anyway, sorry if anyone searched for that talkback report yesterday.  It should be there today, with this bugzilla bug number in the comment (if you can search comments for text).
Marc: run [seamonkey_dir]/components/talkback/talkback
Version: 1.8 Branch → Trunk
Thanks Andrew!

At long last, the talkback IDs for the crash are:

TB14660784G
TB14661024G

I hope this helps track it down, Ubuntu is a popular desktop Linux.

This was for Seamonkey 1.0a.  I couldn't reproduce the bug for 1.5a.  I can try 1.1a and send in a talkback ID if that crashes, if it would help.  Let me know.
those builds are way too old to have symbols. either install a release build or a build that's not more than a week old. sorry.
1.1a builds don't have talkback
Seems we are at an impasse.

1.0a builds are all old and don't have symbols.

release builds don't have talkback.

1.1a builds don't have talkback, may not even exhibit the problem (and I can't find recent ones anyway)

1.5a builds don't exhibit the problem.

If anyone has a suggestion for how I can help track this down please let me know.  And thanks for not giving up yet.
there are recent 1.1a builds here:
ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/latest-mozilla1.8/

A. You can grab the RPMS at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/1.0/contrib/fc1-rpm/ and install the debuginfo RPM.  That should allow you to get a stacktrace from gdb with at least function names.
B. You can build from source with symbols and get a stacktrace
C. Since the bug doesn't show up in trunk builds, it was fixed.  If you can narrow down the time period it got fixed in (down to the day), we can probably guess what patch fixed it and then see if that patch is appropriate for branch(es).  The builds are in http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/
Andrew,

Thanks for your suggestions.  Before dedicating that kind of time, I figured I better check if it happens on 1.1a.  If security releases only get security fixes, and if 1.1a didn't have the problem, then it might be a moot point, right?  (Assuming only security releases between 1.0 and 1.1).

Well, 1.1a does exhibit the problem.  I might be able to do what you suggest, but probably not for a while.

One suggestion I have is for anyone in the Seamonkey team who might have access to a Seamonkey 1.1a linux build with symbols compilied in.  Put that Seamonkey directory onto a USB key.  Boot Ubuntu 5.10 from a live CD on any PC.  Run Seamonkey from the USB key.  Help->About SeaMonkey, close new browser window.  Get stack trace with talkback or GDB (not sure if Ubuntu live CD includes GDB).

Or at least just run regular Seamonkey 1.0 with the Ubuntu 5.10 live CD and verify the bug so it can be changed to "confirmed" in bugzilla.  I imagine "confirmed" critical bugs would get a lot more attention than unconfirmed.

On a more general note, wouldn't it be useful to have a current build of each branch with talkback and symbols compiled in available on some FTP server?  It is ridiculous how hard it is to get a useful stack trace for the SeaMonkey team to work with.  Doesn't this come up a lot?
Lots of new stuff to report, (unfortunately no trace).

Seamonkey started crashing more on me, it started crashing every time that I clicked on a tab in the sidebar, or did a search (which automatically brought up the search tab in the sidebar).

So I started to suspect a corrupted profile (although I started with a fresh profile when I switched to Seamonkey).  I moved ~/.mozilla, started seamonkey, and was releived to find that the crashing bugs were gone.

So I started with a fresh profile (~/.mozilla directory), brought over bookmarks.html and abook.mab, and started the long process of setting all my preferences and re-creating my email and newsgroup accounts.  When I was done, I copied off a clean copy of ~/.mozilla in case it ever got corrupted again.

Then I decided to verify that the crash hadn't come back.  I was very suprised and dissappointed that it was back - and closing a browser window or clicking a tab in the sidebar would again cause a crash.

So I don't think that my profile is corrupted, but something in my profile is triggering this crashing bug.

Besides the usual preferences, I set a few through about:config, which may be the trigger, but I don't have time to verify right now.  The things I set are:
mail.phishing.detection.enabled - false
browser.chrome.favicons - true
browser.chrome.load_toolbar_icons - 2

However, I set those on my home linux box with Seamonkey and have no problem there.  So I really don't have any clue what in my profile is triggering this.

I will post more info when I find it.
I set these back to the defaults:

browser.chrome.favicons
browser.chrome.load_toolbar_icons

And the crashes went away.

So apparently the combination of those non-default settings (true and 2) and my saved bookmarks causes the problem.

I have those settings on my home linux box also, which has no problem.  It has some of the same bookmarks (news sites), but the box with the problem has a bunch of bookmarks internal to my company.  I would attach my bookmark file, but I can't with all those internal server names (besides, you wouldn't be able to load the favicons for those sites anyway, and that is likely the source of the problem.)

I am using the same bookmarks.html file (copied it over) on a Windows XP box with Seamonkey, with the favicon settings to true/2, and that box is not having the problem either (yet).  I don't think I have visited as many of the bookmarked sites to bring in the favicons, so maybe the "trigger" favicon(s) are just not there on that system yet.

So I likely way to reproduce the crashes is to turn those icon settings on, and if you have lots of saved bookmarks hopefully you will see the problem eventually.
Marc: thanks for tracking this down.  Do you see the crashes if you start with a clean profile and add those two prefs?
Andrew,

I tried it and the answer is no, I don't.  Just setting those two preferences with an otherwise default (brand new) profile did not cause the problem.  I didn't think it would, since my linux box at home with those two preferences set doesn't seem to have the problem.

Apparently something in the set of sites I have bookmarked causes the problem (when I started a new profile my history and cache was clean), and the problem happened before I visited any web sites.

I would hope that someone with hundreds of bookmarks would be able to reproduce this (on linux at least).
OK, more important info.

First, I reproduced the problem on Windows - it is NOT a Linux only bug.

By setting these parameters in about:config - 

browser.chrome.favicons - true
browser.chrome.load_toolbar_icons - 2

And then displaying certain bookmarks in the sidebar (ones with favicons are probably causing the problem, I am guessing) I reproduced the crash when closing a browser window or when clicking a tab in the sidebar - on Windows XP.

It is very specific, I have to display a certain set of bookmarks in the sidebar to cause the crashes.  If I don't it doesn't happen.  Maybe Seamonkey doesn't handle malformed favicons gracefully.

Unfortunately the bookmarks that cause the problem are a set that are internal to my company, so I don't think I can attach them to this bug report.

However, if someone can tell me how to save off the favicons displayed in the sidebar when the crashes happen I could try to do that.  Or if there is an easier way to get a stack trace from a crash on Windows XP, tell me how to do that.
Since I found that displaying certain bookmarks in my sidebar (with favicons enabled) causes this crash, I am attaching the icons from my bookmarks.html file that might be causing the problem.  Even if I could give the bookmark URLs, they are internal to my company and nobody would be able to get the favicons anyway.  So in hopes that it will help, I am attaching the icons (surgically cut out of bookmarks.html) that might be causing the crashes.  Maybe if they are pasted into an existing bookmarks.html file the bug can be reproduced.
I hit bug 324988 if I close the window while it's opening, but not if I let it open all the way.  That bug should be fixed now in SeaMonkey 1.1a builds.
Andrew,

Good instincts.  It appears that even though 1.1a exhibited the problem back when I posted comment #16 (02/03/06), the current 1.1a nightly doesn't have the problem.

Even though the symptoms seem somewhat different, I guess it boiled down to some layout element waiting for a favicon, and then the request being cancelled (in my case the sidebar was waiting for the favicons, and switching sidebar tabs or closing the window cancelled the favicon requests).

There is a lot if inaccurate info in the subject and comments (linux only, Ubuntu only, etc.  Not sure if how or if that should be corrected.

Also, am I supposed to close it as a dup of 324988, or resolve it as fixed, or let the mozilla team worry about closing it?
dupe is the way to go

*** This bug has been marked as a duplicate of 324988 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: