Freeze when quitting Camino

RESOLVED WORKSFORME

Status

Camino Graveyard
General
--
critical
RESOLVED WORKSFORME
11 years ago
10 years ago

People

(Reporter: Steven Hollingsworth, Unassigned)

Tracking

({hang})

Details

Attachments

(14 attachments)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 294491 [details]
Log pertaining to the bug.

Log pertaining to the bug.

Comment 2

11 years ago
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.

Comment 4

11 years ago
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

Comment 6

11 years ago
I don't use Flashblock, for whatever that's worth.

Comment 7

11 years ago
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.
(Reporter)

Comment 9

11 years ago
(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.

Comment 11

11 years ago
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
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
I just saw this again...
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
Created attachment 294874 [details]
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.
(Reporter)

Comment 15

11 years ago
Created attachment 294912 [details]
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.
(Reporter)

Comment 16

11 years ago
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?
Created attachment 294917 [details]
Sample from Activity Monitor
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
(Reporter)

Comment 20

11 years ago
Created attachment 295987 [details]
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)).
(Reporter)

Comment 21

11 years ago
Created attachment 295999 [details]
Sample of Camino.

And it happened again using the same build.
(Reporter)

Comment 22

11 years ago
Created attachment 296971 [details]
Sample of Camino

And it happened again using the latest nightly.
(Reporter)

Comment 23

11 years ago
Created attachment 296996 [details]
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.
(Reporter)

Comment 25

11 years ago
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
Last Resolved: 11 years ago11 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Comment 27

11 years ago
Created attachment 301301 [details]
Sample of Camino

Just had this issue occur again.
(Reporter)

Updated

11 years ago
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)?

Comment 31

11 years ago
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.
(Reporter)

Comment 32

11 years ago
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.
(Reporter)

Comment 34

11 years ago
Created attachment 301530 [details]
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.
(Reporter)

Comment 36

11 years ago
Created attachment 303453 [details]
Sample of Camino Pre-Quit

Sample of Camino Pre-Quit
(Reporter)

Comment 37

11 years ago
Created attachment 303454 [details]
Sample of Camino Post-Quit

Sample of Camino Post-Quit
(Reporter)

Comment 38

11 years ago
Created attachment 303587 [details]
Sample of Camino Pre-Quit
(Reporter)

Comment 39

11 years ago
Created attachment 303588 [details]
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).
(Reporter)

Comment 41

11 years ago
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.
(Reporter)

Updated

11 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → WORKSFORME
(Reporter)

Updated

10 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 43

10 years ago
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.
(Reporter)

Comment 44

10 years ago
I have not seen this issue occur in the past couple of months. I guess it can be closed now?

Comment 45

10 years ago
WFM per comment 44.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.