User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3) Gecko/20100805 Firefox/4.0b3 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3) Gecko/20100805 Firefox/4.0b3 The Rhapsody music service plays its tunes in the Flash player. FF 3.6.8 seemed stable, but Firefox 4 Beta 2 and 3 both hang ("beachball") easily in this use scenario if the player is allowed to play for perhaps 30 minutes. Reproducible: Always Steps to Reproduce: 1. Visit rhapsody.com 2. search for an artist, say "supertramp." Load up a couple albums in the player's queue. 3. Listen and wait. The player will stop playing after some time, and will become unresponsive. The dreaded beachball will appear over firefox. Actual Results: Hung (unresponsive) browser. Firefox does sometimes recover if you can close the rhapsody player's window and wait for a while -- 10 minutes perhaps. Expected Results: It's hard to say whether it's flash or firefox hanging -- if not both. I'd expect firefox to remain responsive even if some plugin gets itself into trouble. I believe Flash dies -- I see it in Safari in this scenario, too. In fact, when I installed the latest Flash player the Adobe installer first complained about two "flash containers" being open even though no browsers were open. This told me Flash had at some point been spawned but hadn't been able to close gracefully. Still, Firefox should not (now) be taken down by that.
Created attachment 466013 [details] gdb stack trace for 50249 Mr. Beltzner says how to capture stack and other info on OS X: http://beltzner.ca/mike/2010/08/05/how-to-file-a-bug-on-a-firefox-hang-on-osx/ I hope the trace helps. NB: It's possible firefox had recovered by the time I captured this trace. There will be more. ;-)
Created attachment 466014 [details] firefox-bin process sample for 50249 And here's a sample of firefox-bin captured from Activity Monitor. Firefox was absolutely beachballing while the sample was taken. If this isn't enough I can absolutely reproduce.
Created attachment 479097 [details] another firefox-bin process sample Another "sample" after a ff 4 beta 6 crash. Crash Reporter submitted a crash as 0d1b4590-ecc8-4f94-a384-f90c02100928.
More generic summary.
frank, the build you used didn't have symbols, so your three attachments aren't useful :(. Signature mozalloc_handle_oom UUID 0d1b4590-ecc8-4f94-a384-f90c02100928 Time 2010-09-28 10:37:30.88608 Uptime 5543 Last Crash 1795655 seconds (3.0 weeks) before submission Install Age 1117606 seconds (1.8 weeks) since version was first installed. Product Firefox Version 4.0b6 Build ID 20100914072643 Branch 2.0 OS Mac OS X OS Version 10.6.4 10F569 CPU x86 CPU Info family 6 model 23 stepping 10 Crash Reason EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE Crash Address 0x0 User Comments This is ff beta 6 with the latest flash player. I believe the crash instigator is the rhapsody music service player, which is flash-based. I long ago opened bz 587348 which includes one stack trace and several "samples" from the apple activity monitor. Processor Notes EMCheckCompatibility False Related Bugs INCOMPLETE * Bug 590674 RESOLVED [Win64] OOM Crash at 1.5 GB [@ mozalloc_abort(char const*) ] [@ mozalloc_handle_oom ] Crashing Thread Frame Module Signature [Expand] Source 0 libmozalloc.dylib mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:64 1 libmozalloc.dylib mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:54 2 libmozalloc.dylib moz_xmalloc memory/mozalloc/mozalloc.cpp:100 3 XUL nsHtml5TreeBuilder::startTokenization loc.h:238 4 XUL nsHtml5Tokenizer::start parser/html/nsHtml5Tokenizer.cpp:345 5 XUL nsHtml5Parser::ParseFragment parser/html/nsHtml5Parser.cpp:457 6 XUL nsGenericHTMLElement::SetInnerHTML content/html/content/src/nsGenericHTMLElement.cpp:748 7 XUL nsIDOMNSHTMLElement_SetInnerHTML dom_quickstubs.cpp:21029 8 XUL js_NativeSet js/src/jscntxtinlines.h:584 9 XUL js::Interpret js/src/jsinterp.cpp:4232 10 XUL js::InvokeCommon<JSBool > js/src/jsinterp.cpp:577 11 XUL js::Invoke js/src/jsinterp.cpp:696 12 XUL js::InternalInvoke js/src/jsinterp.cpp:736 13 XUL JS_CallFunctionValue js/src/jsinterp.h:651 14 XUL nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2248 15 XUL nsGlobalWindow::RunTimeout dom/base/nsGlobalWindow.cpp:8585 16 XUL nsGlobalWindow::TimerCallback dom/base/nsGlobalWindow.cpp:8930 17 XUL nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:425 18 XUL nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:517 19 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:547 20 XUL NS_ProcessPendingEvents_P nsThreadUtils.cpp:200 21 XUL nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:126 22 XUL nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:394 23 CoreFoundation __CFRunLoopDoSources0 24 CoreFoundation __CFRunLoopRun 25 CoreFoundation CFRunLoopRunSpecific 26 CoreFoundation CFRunLoopRunInMode 27 HIToolbox RunCurrentEventLoopInMode 28 HIToolbox ReceiveNextEventCommon 29 HIToolbox BlockUntilNextEventMatchingListInMode 30 AppKit _DPSNextEvent 31 AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 32 AppKit -[NSApplication run] 33 XUL nsAppShell::Run widget/src/cocoa/nsAppShell.mm:747 34 XUL nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:191 35 XUL XRE_main toolkit/xre/nsAppRunner.cpp:3662 36 firefox-bin main browser/app/nsBrowserApp.cpp:158 37 firefox-bin firefox-bin@0xbe5 38 @0x1 ... is the crash reporter bit from comment 3. If you want to use gdb/sample/whatever, then you need to use a build which is friendlier to such tools. You could /try/ http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-4.0b7pre.en-US.mac64.dmg -- i'm not sure if it has symbols (I don't have time to check, sorry).
I don't see this any more on FF4, FF5, or FF6 Aurora.