Closed Bug 409729 Opened 17 years ago Closed 16 years ago

Freeze when quitting Camino

Categories

(Camino Graveyard :: General, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: steven, Unassigned)

Details

(Keywords: hang)

Attachments

(14 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9b3pre) Gecko/2007122400 Camino/2.0a1pre (like Firefox/3.0b3pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9b3pre) Gecko/2007122400 Camino/2.0a1pre (like Firefox/3.0b3pre)

While attempting to close Camino (Cmd - Q and the red button) Camino froze and required a Force Quit though the activity monitor. While it was frozen Camino continued to use up more and more memory.

Reproducible: Didn't try

Steps to Reproduce:
1. Quit Camino
2. Freeze
3. Crash
Actual Results:  
Camino froze and required the use of a Force Quit to close it completely.

Expected Results:  
I expected Camino to close down properly the first time.
Log pertaining to the bug.
That's a freeze/hang, not a crash ;) I don't see anything too enlightening in the sample, but I haven't gotten my head around the Leopard sample format yet either.
Summary: Freeze and Crash When Quitting Camino → Freeze when quitting Camino
Oh, Sam was seeing exactly this when quitting the other day :(

We hoped it was related to the bug roc just fixed (bug 409337), but maybe it's not.
Yeah, I think I just saw this yesterday in a 20 Dec trunk build, and the page that was open when it happened had Flash in it. I finally had to just force-quit Camino after about 30 minutes.

I'm not sure if I'd be able to reproduce it, though.

cl
Are people seeing this regularly (and in current builds)?  Are people seeing this with Flashblock, without Flashblock, or both?
Keywords: hang
I don't use Flashblock, for whatever that's worth.
I don't remember ever having seen this kind of hang.
I do use Flashblock, and 10.4.11.
I *was* seeing this (not using Flashblock at all), but since I upgraded to a more recent nightly, I haven't seen it at all. I'm now using Version 2007122700 (2.0a1pre). Note that I still see a slight pause when quitting where my current tab goes blank before Camino actually quits (at about 12 tabs open). It doesn't hang indefinitely though.
(In reply to comment #5)
> Are people seeing this regularly (and in current builds)?  Are people seeing
> this with Flashblock, without Flashblock, or both?

I'm not seeing this in the latest nightly, and I have never used Flashblock.

Chris, if you're not seeing this in a current nightly, let's go ahead and WFM it.
I have no idea how I'd manage to reproduce what I saw (which only happened the one time), so WFM is good enough for me.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
I just saw this again...
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
Attached file Log from Force Quit
Here's the log I received after Force Quitting Camino. This is exactly what I've seen every time. I freeze on quit.
Oh, forgot to say, I was still using Version 2007122700 (2.0a1pre). I had 12 tabs open: 1 Gmail, 1 WikiMo, 1 Google Group post, 3 Static pages, and 6 Bugzilla bugs.
Attached file Log from Force Quit
Here's the log I received after Force Quitting Camino again after a freeze I had today. This is the second time I've had this happen.
Just had another freeze using Version 2007122900 (2.0a1pre). I had 1 tab open (a static page).
Can people seeing this get real samples instead of the Force Quit logs next time they see this?
Comment on attachment 294917 [details]
Sample from Activity Monitor

(Whoops, pushed enter before I entered my comment.)

Here's a sample from Activity Monitor when Camino was hanging on quit.

Smokey asked earlier if I had printed at all. I haven't. The closest I've come is accidentally hitting cmd-p then canceling. (Due to the bug that prevents me from using cmd-left arrow when going 'back'.)
Attachment #294917 - Attachment description: Sample from Activity Viewer → Sample from Activity Monitor
Attached file Sample of Camino
Here's a sample from Activity Monitor when Camino was hanging on quit.

This is using the latest nightly (2008010800 (2.0a1pre)).
Attached file Sample of Camino.
And it happened again using the same build.
Attached file Sample of Camino
And it happened again using the latest nightly.
Attached file Sample of Camino
And it happened again using the same build.
Same deal here: has anyone seen this again since we started getting symbols again?  If not, let's close this INCOMPLETE.
I have not had this issue in the past 13 days.
Neither Sam nor Chris have mentioned it, either; let's hope it was just Core voodoo that's been fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → INCOMPLETE
Attached file Sample of Camino
Just had this issue occur again.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Steven (Michaud): now that we have samples with actual symbols from Steven (Hollingsworth), this looks to me more than a little bit like the crashes from bug 400321 (which was fixed at that time by bug 400321).

Could something in December have un-done that work-around?
Smokey, I don't think this problem is related to the crashes that were
fixed by my patch for bug 400321.  This bug's hangs (at least those
illustrated in attachment 296996 [details] and attachment 301301 [details]) seem to happen
as the Gecko event loop is being processed, _before_ the crashes that
my patch for bug 400321 fixed (which happened after the appshell had
been destroyed, and all processing of Gecko events had finished).

Furthermore, while one of these two hangs seems to happen in
nsAppShell::WillTerminate() (attachment 301301 [details]), the other seems to
happen before nsAppShell::WillTerminate() is called.

These two samples are very complex, and hard to read.  But I'm not
aware of any changes to the Cocoa widgets' appshell, or to any part of
Cocoa widgets, that could plausibly have caused this problem.

I suspect the problem (whatever it is) has existed for a long time.

And in any case, until we have steps to reproduce that reliably
trigger this problem, I don't think there's much chance it will get
fixed.
I just noticed something interesting about the last five samples
posted here -- all of them contain a reference to
nsPrintSession::Release().

Steven, is it possible that your hangs are triggered by printing (or
trying to print), and then quitting soon afterwards (possibly before
the print job is finished)?
nsPrintSession::Release was one of those symbols that was turning up a lot as a bogus symbol when Camino was being mostly stripped, so it may well be that it's still just the closest thing to some symbols that are still not present.
I know for certain the last couple of times this issue has occurred I did not
try to print. I do remember that I always had a "Browse" dialog box open up and
upload a file (to Google Docs for example). Then Camino would become very
sluggish and after I tried to quit it would freeze.
> I do remember that I always had a "Browse" dialog box open up and
> upload a file (to Google Docs for example). Then Camino would become
> very sluggish and after I tried to quit it would freeze.

I bet this is the key to the problem -- that whatever happens in these
attempts to upload files is what causes your hangs (or apparent
hangs) when you try to quit.

The nsPrintSession::Release() stuff may be a red herring.
Attached file Sample of Camino
I just had this issue occur again.

This time I know for certain that I did not print and I did not have any dialog boxes popping up. However, Camino did start becoming sluggish as I was scrolling through Google Reader quickly and the browser started to become unresponsive.
This bug won't be easy :-(

Steven, why not try this the next time Camino becomes sluggish?  First
wait for a bit (30 seconds?) to see if the sluggishness clears up.
Then, if it doesn't, take a sample _before_ you try to quit, then
another after you try to quit.
Sample of Camino Pre-Quit
Sample of Camino Post-Quit
Attached file Sample of Camino Post
I don't really have time to work on this bug.

But what's puzzling about your two "pre-quit" samples, Steven, is that
both have calls to [NSApplication terminate:] -- which should only get
called _after_ you've tried to quit (by for example pressing
command-q).
Would Cmd + W on a tab cause the same call? Both times I had iGoogle and Google Reader opened in two tabs. I noticed that Camino was becoming sluggish so I closed the iGoogle tab and the only page left was Google Reader. Reader was really sluggish so I ran the sample then and then Cmd + Q and did another sample. 

Not sure if that would cause it, but that is what happened.
> Would Cmd + W on a tab cause the same call?

I don't think it should ... but I can't think of any other
explanation.

Try to come up with a set of steps that causes this bug at least 50%
of the time.  Once we can reproduce the problem, we'll be much further
along towards resolving it.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago16 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
What behavior with what versions caused this bug to be closed and reopened again? Bugs should not be closed or reopened without explanation.

(In reply to comment #41)
> Would Cmd + W on a tab cause the same call?

No; no amount of pressing Command-W will trigger a quit.
I have not seen this issue occur in the past couple of months. I guess it can be closed now?
WFM per comment 44.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: