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