407792 - File -> Save Page As... (or file save) exits without warning on some pages [@ JS_IsSystemObject]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[mhr]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7

This has happened twice now to me, both times when I was trying to save a page that contained confirmation information about an effort to register with a financial institution for online bill payment.

Reproducible: Sometimes

Steps to Reproduce:
1. Go to GM Card web site
2. Register for online bill payment
3. Try to save the (only four steps more) page - first time access exited SeaMonkey
Actual Results:  
SeaMonkey exited without any warning.  The first time this happened, it closed all the tabs I had open, too.

Expected Results:  
Expected the file to be saved, as usual.

This has only happened twice, so I don't know how pervasive it is.

Comment 1

[mhr]

Correction - the page that would not save was the enrollment information page for their online bill pay service.  Note that the second time I tried this, it succeeded (the page was saved).

This is the exact same thing that happened the first time I saw this, but it was at a different site.

Comment 2

[mhr]

Addendum:  The same problem occurred again, only this time I was switching tabs while one was loading.  I had two tabs open to my gmail, and one was in the process of changing from trash to my inbox, and I clicked on the other tab and SeaMonkey exited.

Comment 3

[Andrew Schultz]

Do you have any means to hit this reproducibly?  This will hard to track down without steps to reproduce that we can use.

You might also try using a clean profile and/or a running without extensions if you have any installed.

You might also try a trunk build, which includes a crash reporting tool
ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

You don't need to uninstall 1.1.7.  Just install the trunk build somewhere temporary and try to reproduce the crash.

Comment 4

[mhr]

I will pull down the trunk build and use that for a while, but this just seems to hapen out of the blue.  It just happened again when I tried to save this page: http://www.linux.com/articles/61940 but there does not appear to be anything about the page that causes the problem.  I restarted SeaMonkey and went to that page and it saved just fine.

Is there an error file or log I can look into to see if there are any traces left behind?

Comment 5

[mhr]

I posted a question about this on the CentOS users email list, and these are the responses I received (relevant since they all apply to Mozilla products):

---------- Forwarded message ----------
From: fred smith <[e-mail]>
Date: Jan 7, 2008 5:27 PM
Subject: Re: [CentOS] Probably OT: Has anyone else seen SeaMonkey 'pop' without warning?
To: CentOS mailing list <[e-mail]>


On Mon, Jan 07, 2008 at 08:17:00PM -0500, Max Hetrick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> MHR wrote:
> > I sent a bug report to Mozilla about this, but I was hoping someone here
> > might have an insight on this.
> >
> > I use SeaMonkey as my default browser (32-bit even though I'm running
> > x86_64 CentOS 5.1), version 1.1.7.
> >
> > Shortyl after installing 1.1.7 on my 5.0 (and even since 5.1), I noticed
> > that every so often, seemingly at random, although it appears most
> > frequently when I click on something that wants to interact with the
> > file system, the SeaMonkey window just closes.  If I reopen it and go to
> > the same place and try the same thing, it works just fine (and usually,
> > the second SM window is more stable and doesn't do that again).
> >
> > This frequently happens when I try to save a web page, load an email
> > attachment, print a page, or anything that interacts with the file
> > system.  Just now it happened when I tried to switch tabs, but that's
> > unusual.
> >
> > Anyone have a clue?
>
> I've been having this happen on Firefox the last week or two since I
> loaded CentOS 5.1 on my laptop, on just a plain old 32 bit system.
>
> firefox-1.5.0.12-7.el5.centos
>
> I thought it was perhaps one of my plugins I have installed, so I've
> just been dealing with it because I haven't had time to check it out.
> Mine is doing exactly the same thing.

Firefox does this to me quite frequently, and it always has. every new
release they say they've improved the stability, but it hasn't made
any improvement for me in terms of this issue.

I recently downloaded the firefox source and did my own build, just to
see if the failures might have been due to some small incompatibility
between the target system the official binaries are built for, and my
box. Sad to say that while it may not die as often, it still does it.

--
-------------------------------------------------------------------------------
 .----    Fred Smith   /
( /__  ,__.   __   __ /  __   : /
 /    /  /   /__) /  /  /__) .+'           Home: [e-mail]
/    /  (__ (___ (__(_ (___ / :__                                 781-438-5471
-------------------------------- Jude 1:24,25 ---------------------------------

_______________________________________________
CentOS mailing list
[e-mail]
http://lists.centos.org/mailman/listinfo/centos


---------- Forwarded message ----------
From: fred smith <[e-mail]>
Date: Jan 7, 2008 7:02 PM
Subject: Re: [CentOS] Probably OT: Has anyone else seen SeaMonkey 'pop' without warning?
To: CentOS mailing list <[e-mail]>


On Mon, Jan 07, 2008 at 08:31:33PM -0500, Chris Mauritz wrote:
> fred smith wrote:
> >Firefox does this to me quite frequently, and it always has. every new
> >release they say they've improved the stability, but it hasn't made
> >any improvement for me in terms of this issue.
> >
> >I recently downloaded the firefox source and did my own build, just to
> >see if the failures might have been due to some small incompatibility
> >between the target system the official binaries are built for, and my
> >box. Sad to say that while it may not die as often, it still does it.
> >
>
> This doesn't answer the original poster's question, but....
>
> As far as Firefox is concerned you might want to try giving 3.0b2 a
> try.  I found it to be significantly more stable than the 1.5.X branch
> under Winders and on various Macs (haven't gotten around to trying it on
> a CentOS 5.X desktop box yet).

Hey Chris, a blast from the past (remember the old Coherent newsgroups??)

Well, From 1.0, or perhaps even earlier, up thru 2.0.whatever-todays-release
is I've always had that issue. It's largely nothing more than a modest
irritant since I can reopen the same page(s)/window(s) I had open before
the crash.

I'll probably take a look at version 3 one of these days, thanks for
reminding me.

Fred
--
---- Fred Smith -- [e-mail] -----------------------------
 "And he will be called Wonderful Counselor, Mighty God, Everlasting Father,
 Prince of Peace. Of the increase of his government there will be no end. He
 will reign on David's throne and over his kingdom, establishing and upholding
     it with justice and righteousness from that time on and forever."
------------------------------- Isaiah 9:7 (niv) ------------------------------

_______________________________________________
CentOS mailing list
[e-mail]
http://lists.centos.org/mailman/listinfo/centos


So apparently this is NOT just me or a one time thing.

Any progress on this?  It is still happening, and usually at most inconvenient times.

Comment 6

[Andrew Schultz]

> Any progress on this?  It is still happening, and usually at most inconvenient
> times.

see comment 3.  without a stacktrace from a trunk build or consistent steps-to-reproduce, there's not much we can do.

Comment 7

[mhr]

Bug report and stack trace are on the way - I have been running with the trunk build id 2008010701 and it finally happened again.

Hopefully this will help.

Comment 8

[Andrew Schultz]

If you submitted with crashreporter, you can retrieve the stack with:

http://kb.mozillazine.org/Breakpad#Location_of_crash_reports

Comment 9

[mhr]

I'm a little new to this, so I don't entirely understand.

The crash report is at http://crash-stats.mozilla.com/report/index/7927fe66-c218-11dc-b7f3-001a4bd43ed6?date=2008-01-13-20

I tried looking at it, but all I xould see was the content of the "details" tab, and that wasn't terribly revealing.

Please let me know what else I can do or you need.

Comment 10

[mhr]

Got another one: http://crash-stats.mozilla.com/report/index/70dc7791-c300-11dc-b763-001a4bd43e5c?date=2008-01-15-00.

Any clues on what the cause is yet?

Anything else I can do to help?

Thanks.

Comment 11

[Andrew Schultz]

It looks like the reports aren't coming through properly, but I don't know why.

Comment 12

[Andrew Schultz]

ted, any idea why the crash reports (comments 9 and 10) would be bogus?

Comment 13

[(not currently active) Ted Mielczarek]

Something really bad must be happening.  Usually what that means is that the minidump is missing important components (like the thread list or module list).  Hard to say without seeing an actual minidump.

Reporter: if you can reproduce this easily, could you crash, but not submit the report?  (Uncheck "submit crash report" in the crash reporter client.)  Then go to the "pending" directory, (right next to the "submitted" directory where you found your crash report IDs), and find the .dmp file (may have to list by date to make sure you get the latest one if there's more than one).  If you can email me the .dmp file, I'll take a look at it.

Comment 14

[mhr]

The crash only occurs once in a while, although the frequency appears to be on the increase (?).  The next time it happens, I'll do this and file a comment here.

For the record, I posted a question about this kind of problem in the CentOS users email list, and a number of people responded that they have the same problem in Firefox.  Since these are both mozilla projects, I am assuming (and, frankly, hoping) that they are related.

Thanks.

Comment 15

[mhr]

Latest dump emailed to Ted and Andy.

Hope that helps.

mhr

Comment 16

[mhr]

I have twelve dumps with this problem, which occurs with annoying regularity in both 1.1.7 and 2.0a1pre (20080207), only two of which were mailed to Ted (becuase, for some stupid reason, bugzilla eats my reports instead of posting them).

Is anything going to happen here?  Are there any answers available?

I don't mean to seem impatient or rude, but I reported this bug over two months ago, and this isn't the kind of support that encourages one to jump in and test newer versions....

This particular problem has become so irritating I am thinking of looking for another browser suite - I need something little less fragile, which is why I used SeaMonkey to begin with....

Thanks (?).

Comment 17

[(not currently active) Ted Mielczarek]

mhr: unfortunately, unless this is reproducible, it's very hard to fix.  Especially since crash reports are not being produced reliably, it's hard for anyone to get traction on this.  We have a lot of other crash bugs, and we don't have unlimited manpower.  I finally found some time to dig through your crash dumps, and they're missing the list of running threads, which is why they don't get processed.  I'm not sure why that is, but they do contain exception info, which tells us where they crashed, at least, and a list of loaded modules.  From this, I dug through the symbol files by hand, and came up with this:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsdbgapi.c&rev=3.120#1638

That's where your crash report indicates you're crashing.  That's all I can tell you for now.  Unless someone familiar with JS has a hunch here, or you build a debug build and catch this in a debugger, it's unlikely to get much further.

Comment 18

[mhr]

Okay, I put my foot in it, so I'm game.  How do I "build a debug build and catch this in a debugger?"

(My only concern is that I recently hit a problem in the 2008020702 build that prevents it from printing anything, and I'd rather not run into that one again as well....)

Let me know.

(I've had problems with Bugzilla reports on more than just SeaMonkey - no clue as to why....)

Comment 19

[Andrew Schultz]

mhr, there are docs at http://developer.mozilla.org/en/docs/Build_Documentation

Once you get a working build, the docs will appear straightforward, although it's sometimes hard to diagnose failures when you first start.  If you hit trouble, you can stop by #seamonkey on moznet (irc://irc.mozilla.org/seamonkey) and get help.

Comment 20

[mhr]

Have not had time to do a build yet, BUT I have noticed some things that may help:

1) If I go to save a page or a file early on, before the bug strikes, it never strikes at all.  So, if I open the browser and click File->Save Page As right away, that seems to forestall the problem form occurring (ever) as long as that browser is open.  (This might be considered a "workaround," but it's a pain to remember if I don't plan on saving pages up front.)

2) It takes some number of steps (links followed and/or pages opened) before the bug occurs.  This is the part where it gets murky - I've tested 3 and 4 steps in and not found it, but that is sketchy and may be unrelated.

My theory:

There is an uninitialized variable/field/class somewhere that starts off innocuous, but at some point, some number of web page fetches or links followed (or perhaps it is related to the type of the links, or the number of tabs opened, though I think it can happen even if only one 'tab' exists) later, that field becomes corrupted, after which any attempt to access it causes the crash.

I have not given up on this yet - it bites me at least once a day, always in an inconvenient place.

Comment 21

[mhr]

I have now built the SeaMonkey suite for version 2.0a1pre and I am not seeing the problem at all.  I have installed this as my default browser and linked to all my standard plugins (AR, mplayer, swf) and all of them work (so far).

I think this strengthens my theory that the problem is related to running the 32-bit build on a 64-bit machine, and might even be related to the mplayer plugins, which I installed last before I started seeing the problem.  I can't prove this, but I find it extraordinarily suspicious.

If I could get some guidance on how to build a SeaMonkey distribution rpm from a build, I would be willing to contribute and maintain a 64-bit distribution rpm for RHEL/CentOS base distributions, something you don't have now.

Special thanks to Andrew Schultz for his assistance and patience with me as I've gone through this annoyance since December.

Comment 22

[mhr]

I am now, unfortunately, able to report that this also happens on a 32-bit machine in SM 1.1.11 and 1.1.10 (which I am now using because it is better at not crashing at random than 1.1.11 is).  I STRONGLY suspect that this is related to BZs 445540 and 448806 (all of which, sad to say, I've filed).

HTH.

mhr

Comment 23

[Jesse Ruderman]

mhr, it sounds like updating to Seamonkey 2 fixed this for you.  Is that correct?

Comment 24

[mhr]

That appears to be the case, yes.  Thanks.