502864 - Hang related to zimbra

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Tim Riley [:timr]]

Attachment: "Sample of Firefox" process state from Activity Monitor

I looked at few web pages like my Zimbra calendar.  I had 19 tabs open.  10 extensions installed.  After not using Firefox for a bit, I returned to it and it was hung:
* I couldn't select any tabs.  I couldn't type into or select 
  text in the URL bar.  
* I could create new tabs by clicking on a link in an email.  
  But the new tab was frozen (could not click the tab, click 
  links in a tab, or scroll the window).  The new tab start-up 
  was very quick.  
* I was able to access the Firefox menus.

Juan and I looked the Activity Monitor and my system was not CPU, Disk, Memory, or Network bound.  Firefox was not hogging CPU or Memory.  We took a Sample of the process from the Activity Monitor. See attached.

I killed it with the crash me extension so there should be a crash report for this also.

So far it has not happened again since I restarted.  So I cannot reproduce this yet.

User agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

Comment 1

[timeless]

timr: no. it has nothing to do with anything you see in the stack.

those things are merely public symbols, which have nothing to do with anything.

Comment 2

[Tim Riley [:timr]]

For the record, it happened again.  This time it was frozen from the moment I first looked at Firefox this morning.  I wonder if it has something to do with my system sleeping(?) or coming out of sleep?  I have another Activity Monitor sample (probably useless as Timeless says).  Also there is another stack trace after I did a "Crash Me Now": 0e68efd3-861a-41e5-a0bb-91d6a2090708

I am still on 3.5 rather then the nightly.  I want to see if this is something others 3.5 users might be dealing with. 

I'll make sure I don't have a Zimbra tab next time to double check if that is the culprit.

Here are some stats fort eh Firefox app from Activity Monitor.  When Firefox is quiescent:
  8-16% CPU usage
  39 threads
  328MB Real Memory size
  741 MB Virtual memory size
  0B shared memory
  221MB Private memory size
  251MB Virtual private memory size
  1.32 GB VSize
  Context switches: 800 /sec <<== seems like a lot!
  Faults: ~60 /sec

User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

Comment 3

[Boris Zbarsky [:bzbarsky]]

Tim, to get useful stacks out of the activity monitor you need to be using one of our shark builds, not just a nightly or release build....

Comment 4

[Boris Zbarsky [:bzbarsky]]

That crash stack just shows us coming in off an event handler and crashing in nsCrasher::Crash.  Which makes sense, if you're doing it from the menus (and if the problem is just that we're spinning in the event loop like mad but still respond to menus).

You might want to do a manual kill -SEGV from a terminal and hope to catch us in some relevant code, or use a shark build and get a sample from it...

Comment 5

[Tim Riley [:timr]]

This stopped happening.  I'll work on trying to get it to start happening again.  If unsuccessful I'll close it out at WFM.

Comment 6

[Tim Riley [:timr]]

Ignore the status change, I screwed that up accidentally.

Comment 7

[Tim Riley [:timr]]

The hang happened again.  This time it was with 3.5.1.  I did a  kill -SEGV as suggested by :bz .  No crash report was generated. And I just see the normal command execution prompt in the terminal window after the kill cmd.  I checked for core files in the pwd and elsewhere on my system and there are none from today.  Is there anywhere else I should look for output from the kill?

User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1

Zimbra was running this time.

I'll start run a shark build and try to catch it there.

Comment 8

[Troy W.]

Is this 4yr old bug still a bug, or has it since been resolved?