New Message: Spinning beach ball cursor, Frontier locked up on Mac OS X

webmaster at userland.com webmaster at userland.com
Wed Aug 30 04:25:08 CDT 2006


A new message was posted:

Address: http://frontier.userland.com/discuss/msgReader$14469

By: Jeremy Reichman (jaharmi at mac.com)

I've got a copy of Frontier 9.0 that I continue to use to serve a Manila site. I recently moved the startup disk it occupied from a Power Mac G4 dual 450 to a G4/733, but in all other ways the computers are equivalent and no other changes were made to the startup disk during the move (the RAM was and is still 1 GB, for example). The system software in use is Mac OS X 10.3.9 plus all available patches.

I'm getting frequent Frontier lockups, where the system sees the app as not responding and I'm given the automatic option to Force Quit it when bringing up its pop-up menu from the Mac OS X Dock.

When Frontier first starts up, it behaves normally. Its CPU usage is initially low but at some point grows to 70-80%. At this point -- and I don't know at what point it reaches it, since I haven't been able to monitor it -- the app is unresponsive. Web visitors to my Manila site cannot see my site, and I'm not able to post to it (I largely use MarsEdit nowadays). Force Quitting it does work, and I can restart Frontier. It'll behave for some period of time, up to about a workday.

I have been running the blocker.root and metaData.root and a few other additions that have been useful. Some of those do have scripts that go in user.schedular so I've just commented those out this morning to see if that helps matters at all.

I took a sample of it with Activity Monitor when Frontier was in the locked up state, and the summary of the results is below. However, I lack the knowledge to make sense of this. I can provide the full sample, which is lengthy, if that would be useful.

Total number in stack (recursive counted multiple, when >=5):
 52 evaltree
 52 evaluatetree
 41 evaluatelist
 21 functionvalue
 21 langfunctioncall
 21 langhandlercall
 10 _pthread_body
 8 mach_msg
 8 mach_msg_trap
 6 0x96f2082c
 6 0x96f2b064
 6 0x96f3ed98
 6 0x96f740a8
 6 kernelcall
 6 kernelfunctionvalue

Sort by top of stack, same collapsed (when >= 5):
 mach_msg_trap 1416
 __memcpy 177
 semaphore_wait_signal_trap 177
 syscall 177
Sample analysis of process 26762 written to file /dev/stdout
Sampling process 26762 each 10 msecs 300 times

Any ideas about what could be causing this problem, and how to fix it? Thanks!

This is a Manila site... http://manila.userland.com/.




More information about the Manila-Server mailing list