35.33 KB, text/plain
Created attachment 387219 [details] "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
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.
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
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....
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...
This stopped happening. I'll work on trying to get it to start happening again. If unsuccessful I'll close it out at WFM.
Ignore the status change, I screwed that up accidentally.
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:188.8.131.52) Gecko/20090715 Firefox/3.5.1 Zimbra was running this time. I'll start run a shark build and try to catch it there.
Is this 4yr old bug still a bug, or has it since been resolved?