We are running FileMaker unlimited 5.5v1 with the web companion 5.5v4 on Mac OSX 10.2.8 Server. We are experiencing crashes 5 to 6 times per week (unexpectedly quitting). We are serving approximately 25 databases and we have tried recovering and compressing all of these databases in the hope that it was a corrupted database that was causing the problem. We have also tried this one 2 different machines running fresh installs of OS X Server. Same results. The following is a readout of the crash log from apple system profiler. Has anyone run across this before... any ideas.

Date/Time: 2004-03-03 08:44:17 -0800

OS Version: 10.2.8 (Build 6R73)

Host: Xavier

Command: FileMaker Pro

PID: 585

Exception: EXC_BAD_ACCESS (0x0001)

Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:

#0 0x04f98788 in 0x4f98788

#1 0x04f20b4c in wc::OTTCPSocket::Notification::Run( (void))

#2 0x04f8c910 in wc::OTCarbonTCPSocket::BufferCompletion( (wc::BufferRef const &, long, unsigned))

#3 0x04f20034 in wc::OTTCPSocket::In::Run( (void))

#4 0x04eedea0 in Run__Q22wc13TaskQueueImplFRCQ22wc15Ref<Q22wc4Task>

#5 0x04ede444 in wc::TaskQueueImpl::Run( (void))

#6 0x04ede738 in wc::STMacCondition::WaitOnQueuedTasks( (void))

#7 0x04eded8c in wc::STMacScheduler::ShutDown( (void))

#8 0x04ef1e28 in wc::SchedulerImpl::Quit( (void))

#9 0x04e9aff4 in wc::AccessCompanionImpl::Stop( (bool))

#10 0x04e9e26c in wc::WebCompanionImpl::Stop( (bool))

#11 0x04eae014 in NSRV_NetworkStop(void)

#12 0x04e07674 in FMExternCarbonCallProc

#13 0x003cf690 in CallFMExtern

#14 0x003d0d28 in FMXC_ChangePlugInState(short, unsigned char)

#15 0x003d12a4 in fmxShutdownPlugin(int)

#16 0x003d1370 in FMXC_Shutdown(void)

#17 0x0038aa64 in DOC_Shutdown(void)

#18 0x003bfc20 in CFMProApp::ExitInstance(void)

#19 0x005c70a8 in 0x5c70a8

#20 0x003bee38 in main

Thread 1:

#0 0x9000508c in syscall

#1 0x90515d0c in BSD_waitevent

#2 0x905156dc in CarbonSelectThreadFunc

#3 0x90020c28 in _pthread_body

Thread 2:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x9051dbf0 in CarbonOperationThreadFunc

#3 0x90020c28 in _pthread_body

Thread 3:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x905259e0 in CarbonInetOperThreadFunc

#3 0x90020c28 in _pthread_body

Thread 4:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x9023317c in TSWaitOnSemaphoreCommon

#3 0x9024890c in AsyncFileThread(void*)

#4 0x90020c28 in _pthread_body

PPC Thread State:

srr0: 0x04f98788 srr1: 0x0000f030 vrsave: 0x00000000

xer: 0x00000000 lr: 0x04f022a4 ctr: 0x04edfe68 mq: 0x00000000

r0: 0x04edfe68 r1: 0xbffff140 r2: 0x04ff0000 r3: 0x05054028

r4: 0xbffff1d8 r5: 0x00000004 r6: 0x0000000c r7: 0x01000000

r8: 0x905725ac r9: 0x00000001 r10: 0x00000002 r11: 0xa00044b0

r12: 0x00000000 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000

r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000

r20: 0xbffffe44 r21: 0x05052ab0 r22: 0x0501552c r23: 0xffffffff

r24: 0xbffff344 r25: 0xbffff338 r26: 0x0503d7d0 r27: 0x05a5ba40

r28: 0x0503d7a0 r29: 0xbffff1d8 r30: 0x050160d8 r31: 0xbffff140

After many unexpected quits in OSX 10.1.5 and 10.2 with both FMU 5.5 and 6.0, the Web Companion 6.0v2 patch from Filemaker (see http://www.filemaker.com/support/updaters.html) , solved all our problems.

We have been running for months now without a hint of trouble. For anyone still having difficulty, I would seriously recommend upgrading to 6.0 and installing all the updates

I had problems with FMU6 quitting off FMS 5.5 - upgrading the web companion seems to have fixed the problem for me. Are you running FMU and FMS on the same system? I understand that this may cause problems and is not recommended.

hello, i am in process of putting up site on new server. Dual processor XEON 3.06 GHZ with 1.5 GB RAM. Filemaker 5.5 unlimited running the DB. the site on old server P3 800 MHZ with 786 MB Ram runs great. when i put new more robust server into production, FM stops with no warning. earlier in the thread someone had mentioned this. I was wondering if there is a limit to what FIlemaker can actually handle.

The site is running on WIndows 2000 standard server - IIS 5.

ANY information is appreciated.

Hi -

What do you mean "stops with no warning" - do you mean the application locks up?

Have you applied any necessary FileMaker updates?

Have you checked the Windows event logs?

Will

Hi Will,

Perhaps i should have been more technical. the XEON chip uses hyperthreading which i know FIlemaker does not take advantage of. I did not know of it causing problems. Once the CPU usage reaches more than 50% on the webserve, the Filemaker client quits or needs to be restarted.

Applying the necessary updates and checking the event logs? thank you and of course.

i have disabled hyperthreading on the server and i am running tests to see if this resolves my issue.

is there anyone out there running a website with IIS 5 and filemaker 5.5 Unlimited using XEON technology? 3 GHZ. i heard at a certain point it switches to 64 bit which the application won't handle.

The latest version of WC (6.0v3) has really worsened the crashing problem for us.

ftp://ftp.apple.com/filemaker/Updaters/MacOSX/wc_60v3_osx_update.sit

Reverting back to 6.0v2 hasn't helped. Will have to try the vnode solution...

Anyone else having problems now with Web Companion 6.0v3 crashing?

Curtis -

I am also running FM 5.5 Unlimited on a Windows 2000/IIS Server. But it is a single processor P-III. Occasionally I have noticed FM using 95-99% of the processor. This started happening in the last 3 weeks or so. The last time this happened was about 2 years ago and the culprit was a new version of Netscape browser - whenever that browser connected to the site FM CPU usuage locked at 99% - I don't recall if I was using 5.0 or 5.5 Unlimited at that time.

Will

Just FYI... While working on my events calendar project, I discovered a weird UNEXPECTEDLY QUIT error yesterday whenever I auto-sent mail from one of my pages for the 2nd time. It's really strange.

Other than that, on our Mac systems we disabled the software updates utility and the auto-setting of the date and time and it may have helped some... hard to say. Still, 1 of our servers goes down maybe 1/month and the other one a little more but comparable... the former is on 10.2.8 and the latter is on 10.3.?. Both use FMP-U 5.5.

--ST

thats my problem too.. when ever a web client sends requests on FM. it quits unexpectedly.. I really dont know what the problem is..

I had a problem like this. Sometimes when a request was sent, FM would just quit. Oddly enough for me, it was my -error page. I still dont know what it was, but if a request was sent and something was amiss, the user would get sent to the -error page instead of the -format page. FM would then just quit.

Something was coded strange in my -error page. I rebuilt it from scratch, and now it no longer causes a crash. So if I had my -error page causing FM to quit, I wonder if there are any of your -format html files that are causing FM to quit?

Wish I could be more specific, but I never did find what it was on my original -error page. Double check your html pages. Maybe hidden characters or incorrect cdml links.

LR

We've been having quitting problems similar to what's been described so far in this thread - about every second day (sometimes more often), FMU 6v4 would 'unexpectedly quit' for no apparent reason (running on Mac OS X 10.2.8).

To cut a long story short, what eventually fixed it for us (fingers crossed, so far so good!) is upgrading Web Companion to the latest 6v3 patch.

Just thought I'd add our experience to the list ...

Cheers,

Kevin Futter

I've been following this lengthy post for years and still don't get reliable performance out of our FMU 6.x server, so now that I've come up with an AppleScript that seems to fix the problem, I thought I would share it.

The first part checks whether FileMaker is running at all, in case it has been quit, unexpectedly or otherwise. The "else" part uses a simple call for the version number to determine whether the application is responding (this is the problem I have most often--spinning beach ball, etc.). The 10-second timeout gives enough time for any current processing of web transactions to finish before it assumes FMU is hung. It will also kill FMU if a Define Fields or other dialog is open which prevents the script (and web users) from communicating with the databases. The OpenDBsOnCrash.fp5 file is an opener file, but the opener script also creates a new record in that database with the current date and time, so you get a log of server restarts. About the only thing it doesn't check for is whether an individual database has been closed, but that's not a problem I typically have.

I used Cronnix to create a crontab which runs the script every minute. My thanks to the folks on the message boards at MacScripter.net for helping me figure some of this out.

The script:

set exists_ to false

tell application "System Events"

set exists_ to exists process "FileMaker Pro"

end tell

if exists_ is false then

tell application "Finder"

open file "Users:Username:OpenDBsOnCrash.fp5" of startup disk

end tell

else

set v to ""

try

with timeout of 10 seconds

tell application "FileMaker Pro" to set v to version

end timeout

end try

if v is "" then

do shell script "killall "FileMaker Pro""

set exists_ to true

tell application "System Events"

repeat until exists_ is false

delay 2

set exists_ to exists process "FileMaker Pro"

end repeat

end tell

tell application "Finder"

open file "Users:Username:OpenDBsOnCrash.fp5" of startup disk

end tell

end if

end if

Having posted the above script before I actually got a chance to see if it stopped crashes, I thought I would provide an update on how it worked, now that I've actually had a lot of traffic.

Simply put, it does what it's supposed to do--it has crashed about 4-5 times in the last two months (almost always in the middle of the night, when traffic is virtually nonexistent), and the script always restarted it successfully, although a couple times it was necessary to restart 3-4 times in a 10-20 minute period. Overall, the number of hangs is down from this time last year, which might be because of the script "tickling" the FMU app every minute or because I upgraded the RAM from 512 to 1 GB since then.

Anyway, our customers are happy because downtime has been effectively eliminated. So we're happy too.

Hmm... AppleScript, eh? Thanx, iMarc... I'll give that a try soon and see how it works with FMU 5.5 and will post my success story here (I hope). Our crashes tend to be overnight or over the weekend as well so I used to think it was googlebots/spambots/spiders/crawlers... now I think it's a variety of things and not just 1 problem. One problem I've had from these crashes, though, is that once in a while, one of the db's will be corrupted and I have to do a RECOVER on it before it's operational again. Make sure you follow Vaughan's advice and backup your files; keep an empty shell, too, if you can.

Our upgrade to Panther 10.3 has reduced our crashes dramatically, however, so it may be a while before I'll even know if your solution worked for me.

BTW, is your crontab file a user-based crontab in the logged-in user's home directory somewhere or is it the main system cron file in the root area? And for those of you in the audience wondering what the heck a crontab file is, I think it's like a unix-based timed script system. In Mac OS X, for example, Apple has a number of tasks in cron that are performed fairly regularly to help keep your system running smoothly... housekeeping stuff the user usually isn't even aware of. Earlier in this thread, I mentioned using cron to reboot the server every day in the wee hours. While this worked for us, some users were experiencing too many breaks in services during the day so iMarc's solution should work better for Mac users. Windows has a scheduler but I'm not sure what can be done about the equivalent to the AppleScript shown.

Thanxagain for the post!

--ST

I'm pretty sure the crontab is user-based--if I were logged in as another user, I probably wouldn't be running the databases anyway.

I suspected spiders for a while, too--I blocked Google access to all the FM-generated pages for awhile, but it didn't seem to make much difference. Panther probably helped too, but... That's why this whole problem is so frustrating, there's just so many variables and nothing seems to make the problem disappear completely.