FMU Unexpectedly Quitting

[valentc]

I have some Dbs I've had on the web for a number of years. Completely stable under 4.1, not quite as good under 5.0 Unlimited. Just upgraded to 5.5v2 Web Companion 5.5 v4 on a dual CPU G4 running OS X 10.2.2. Some of the Dbs are local, some are opened from Server v5.5 also running on a dual G4 under OS X 10.2.2. Every few days FMU just unexpectedly quits. Just pops up a dialog box that says that, no other hints or anything else in any of the logs. Anyone have any hints?

[Steve T.]

Hmm... we were just talking about that in the MAC Hardware & Networking forum of FMForums...

CLICK HERE TO SEE POST

I haven't seen/heard anything yet as to solutions but I hear Windows has a similar quirk (except not Anatoli's systems) with gobbling CPU resources. Someone else even said FileMaker, Inc. told him his system was too powerful to run FM properly. He used a more humble system with less RAM and his problems went away.

I'm trying to use a workaround that will auto-boot our server every day in the wee hours, but we're having trouble getting even that "simple" thing to work.

I've seen other folks with the same problems on Mac OS X 10.1.2 and FMP-u. You have both Unlimited and Server, right? But it's just U that quits? Hmm... good to know, but I don't think anyone's given any good answers yet.

[Anatoli]

Here is the proof:

http://www.didi.cz/servertime.gif

We scheduled the reboot to year 2004 when we will update the HW

[valentc]

Yes, Server seems to run just fine, it is only FMU that quits. I have started rebooting every morning when I come in, but that is only a short term solution. It is possible that lingering corruption in the DB's is the culprit. I mention this because Server 5.5 certainly seems to be more forgiving of "bad" databases. When I upgraded to 5.5 Server & Unlimited I immediately had some crashing problems when connecting to the Server. In the past Server would not open corrupted DB's, but this copy of Server had done just that. When I identified which one and Recovered it the problem ceased. Perhaps FMU 5.5 is more forgiving as welI. I may go ahead and do a Recover on everything, but all DB'd at least appear to be fine, and I was hoping to avoid the grunt work of running Recover on dozens os DB's, then having to test everything out (sighing heavily here). Hopefully something will turn up.

[Steve T.]

Hmmm.. what the heck: I only have a couple db's so I'll try that, too. If it works, I'll post a success story here.

Thanx for the tip.

[valentc]

Well, after talking to FMP support they tell me I should be restarting FMU every 24 hours, 48 at the outside. Yow, ugly!!! Ceratainly makes FMU far more unattractive as a web solution, but it still is a plus for me nonetheless. I may end up goinmg back to runnning it on OS 9.2.2 so I can use the scheduled shutdown & startup in the energy saver control panel. Also I didn't have unexpected quits under Classic, although I was running FMU 5.0 insteads of 5.5. From what FMP support told me this could be a result of lingering corruption that was magnified in the conversion of the Dbs from v4 to v5. There are platform specific chunks of code in the databases, so they could run OK under one OS, but have stability problems under another. I guess I'll see, since the only other suggestion was to recreate the databases. As I have dozens of complex ones this is not a good option.

[Vaughan]

Here is cheap insurance for the future: when you have finished a solution, save a cloned (empty) copy and keep it safe.

When the files need rebuilding it's just a simple matter of importing the data from the old files into new copies of the clones.

[Garry Claridge]

One of my clients has FMU 6.0 with "OS X 10.1.4". It runs fine without the need for restarts.

Just an observation.

All the best.

Garry

[Steve T.]

We have 2 FMP-u servers

(1) Mac OS9.2 restarts w/Energy Saver every day

(2) Mac OS X 10.2 running FMP-u in Classic mode restarts w/cron every day.

So far #2 has worked out best for us and has the most UP time. Plus, it has the distinct advantage of being able to be rebooted via SSH from the Mac OS X command line (terminal) from a remote location. #1 will soon be abandoned and replaced with a Mac OS X machine that will run FMP-u natively in X. We're hoping that pure X will be the most stable.

We'll start using Vaughan's strategy but are a little sad (sigh) that it comes to that. "Finished" is always a relative term w/us.

Thanx for sharing, folks.

[Garry Claridge]

The method Vaughan describes for back-up is wise for any dbms. As an example, for mySQL the best backup method is to export the data and structures; then a restore can be done on any part of the database.

All the best.

Garry

[balooka]

hi,

My fmpU dies on me sometimes too (OSX.2.3). I can't figure it out since it occurs at times when the db's are doing almost nothing (just a few webusers). It certainly doesn't happen every 24 hours, but it's still annoying to turn on the panel and see the message that fmpu has quit unexpected...

Now that we're on this topic anyway, what is a 'safe' way to automate shutdown *and* launch of FMPu with an interval of lets say 5 minutes? Say, every 24 hours, just to be sure?

sorry, I just opened the link above concerning this topic, didn't know i was asking the same her

Thx

JP

[Anatoli]

On Windoze easiest is to use schedule for closing and opening FM.

I believe there is something like that in Mac OS X?

[taylor-daniel]

Yep I also have the same problems and I am very dissaponted, on OS9 I had a very stable server, and as soon as I entered the OSX 10.2.3 world it quits twice/four a day I also host a good number of FM db's that are accesed in several ways.. WEB, FMcompanion etc.. I created an AppleScript Script for recovering automatically from crashes that is trigered using IDOX scritpt scheduler that runs every 10min. (http://www.sophisticated.com)... there are not the answer as Filemaker still quits but at least it recovers..

Here are the scripts..

"rescuefromcrashv1"-- (this is the script that should runn with the idoX app.)

"laucherscriptcr' is the one in charge of opening back the DB's (it must be customized for your server file names etc.."

One last note, this is for a single server config, FMWSC and FMunlimited running on the same server. I am working on another script for a 2 server config..

And Finally if anybody has a Clue of what is going on or what causes the crashes PLEASE Advice...

[scratchmalogicalwax]

OSX users may want to have a look at Whistle Blower and an APC master switch(s).....very very good for checking all of your LAN and public servers are up and running.

http://whistleblower.sentman.com/

WB can disable checks based on the results of others e.g. you don't end up restarting your webserver because of missing content when your DB client or server has crashed.

I run two OSX.2.3 FMPro U 6 clents with no problems.... OSX FMPro server 5.5 had two installs before it would run properly... Why?..... who knows. It works fine now tho.

File names seem to be very important. The Apple front end allows you to use extended charaters in names of files. As soon as the underlying UNIX has to access the file you could have problems.... if it is being accessed by an application or daemon you could have a nasty crash and possibly corrupt files.

We keep filenames short (less than 31 chars. and only use a to z

[Piotr]

I am having exactly the same problem with FM Unlimited running in OS X. I have two systems: FM 5.5 Unlimited on OS X 10.1 and FM 6 Unlimited on OS X 10.2. Both unexpectedly quit every now and then (at least once a week) for no apparent reason. I am also running a copy of FM 5.5 Unlimited on an old Pentium III with Windows 2000 - this machine has not been rebooted in 18 months (FM has not been restarted either) and FM has not crashed once!

[lackey]

I am having the same problem as well running FMU 6 and FM Server 5.5 on Mac OSX 10.2.3. It sounds like the only solution thus far is to restart the server every or every other day. Since this isn't a very appealing workaround, are there any other solutions to this problem?

Thanks, in advance, for any suggestions!

[kenneth2k1]

Well I don't have much experience with FMU, but I know that OSX unexpectedly quitting is more common than we all would like. I have a G4 867 that unexpectedly quit frequently when writing to the HDD. We used a drive utility (I think it was called Drive X) because there was some shell data corruption, and when the repair was executed, the quits were almost all the way gone.

Ken

[dwal]

Has anyone seen a solution to this? I recently upgraded FMU 5.5 to FMU 6 on OS 10.2.4 and now FMU fails every 1-2 days. Prior to this there were no problems. When this happens FMU becomes extremely slow and the processor is at maximum. Of course FMU is using nealy all of the processor.

[Anatoli]

Has anyone seen a solution to this? I recently upgraded FMU 5.5 to FMU 6 on OS 10.2.4 and now FMU fails every 1-2 days. Prior to this there were no problems. When this happens FMU becomes extremely slow and the processor is at maximum. Of course FMU is using nealy all of the processor.

I know you will not like me: get the Windows

10 years ago I was always writing: get the Mac!

But in 5 years after my switch from Mac OS to NT4 and W2000 I didn't experienced

any problems. For sure less in 5 years that you experienced in a week.

[Steve T.]

Hi, folks!!!

FOLLOW-UP.

I am pleased to post a success story, although it may not help some folks who seem to already have simlar set-ups.

FMP-U 5.5 w/5 databases (only 1 has significant every-minute traffic).

We went from a PowerMac on Mac OS 9 to a beige G3/300 desktop (192MB RAM) with Mac OS X 10.2.4 and it has been running flawlessly for months now, with only an occasional (monthly?) re-start for Apple's software updates (not for problems). It is ROCK SOLID. I used to have to check every morning if it was running properly, but each day my confidence has grown and now I don't bother... even for weeks.

Our other system (G3/300 Server, X 10.2.4, 128MB RAM) runs FMP-U 5.5 in Classic and re-boots every day in the wee hours using CRON from the command line (we use a mail plug-in that is not available for X yet so must run Classic). We are very happy with this workaround. What's nice about this is that you can log into the system remotely (command line) and manually re-start the computer if FMP-U quits (which it rarely does now). Upon restart, we have X auto-load FileMaker and the 1st database and then have the 1st database execute a script upon opening to open all the other db's. We did this latter step because we could not get X to open all the db's. It would only load the first and then ignore the others.

I hope this helps some folks. For our pure X system, we did a full format/install from scratch, of course. In fact, we did not even install Classic, so EVERYTHING is X, and it is working GREAT... better than I had hoped.

[xtrim]

Hi

Well I got FMP6 U on win2000 adv server on a Compaq proliant dual P_III win 512MB mem, and it is running for 5 months now without any restarts...and the traffic is 200 entrances per day...

[smorr]

I too have been experience similar problems where no problems existed in OS 9.2.2

Last Summer I upgrade from OS 9 to X 10.1.5

This winter I jumped to X 10.2 (currently at 10.2.4)

Over the last month I have had the following crashes:

( They are all listed in crashreporter as

Exception: EXC_BAD_ACCESS (0x0001)

Codes: KERN_PROTECTION_FAILURE (0x0002)

Date/Time: 2003-02-26 17:13:12 -0500

Date/Time: 2003-02-27 07:24:10 -0500

Date/Time: 2003-03-03 10:12:49 -0500

Date/Time: 2003-03-03 17:59:15 -0500

Date/Time: 2003-03-05 10:39:43 -0500

Date/Time: 2003-03-09 11:33:02 -0500

Date/Time: 2003-03-09 18:06:33 -0500

Date/Time: 2003-03-10 15:48:34 -0500

Date/Time: 2003-03-13 10:36:03 -0500

Date/Time: 2003-03-13 17:56:55 -0500

Date/Time: 2003-03-14 11:17:10 -0500

Date/Time: 2003-03-16 19:04:52 -0500

Date/Time: 2003-03-24 15:52:34 -0500

(So 13 crashes in about 30 days.)

What I do now is have cron execute an applescript every 5 minutes to check to see if FMP is up and opens it if it is not up.

Generally speaking this works ok but sometimes things get fouled up with dialog boxes and it requires manual intervention.

I would love to see this fixed -- if anyone have more insight fire away.

BTW G4 dual 533 1GB RAM - running FMP Unlimited, Lasso 5, WebStar.

[kenneth2k1]

Smorr:

Hi, by looking at the error message given, i would guess that some process in FM is trying to access the protected OS memory space. You didnt say what version of FM you have, but you may want to check for an update.

Ken

[Anatoli]

RE: BTW G4 dual 533 1GB RAM - running FMP Unlimited, Lasso 5, WebStar.

AFAIK from Lasso List, there where some Lasso issues on Dual CPU, and I believe it is fixed in latest Lasso 6.0.4.

Also the speed is improving with every version of Lasso 6.

[valentc]

Well, this is the original poster. things are OK now because I went back to OS 9.2.2 instead of running under 10.2.2. I think my problem was twofold. First, there was lingering corruption in the databases due to crashes over the years. According to FM Inc corruption can be magnified during the DB conversion in version chnage, and these had been through 3-4 to 5-6. Also, there was some crashing that occurred recently under OS X, having to do with a DB that was corrupted that Server 5.5 was able to open causing problems when accessed via the web under Unlimited. What I did was retrieve copies that had not been through the OS X crashes, install them on a test OS 9.2.2 machine with a freshly installed and upgraded (v2 & v4 Web Companion) copy of FMU 5.5, and tweak the password privileges, default passwords, and Web Security privileges so that all DB would open with no intervention on a restart. I thne set the Energy Saver control panel to restart every day in the wee hours. After running for a week or so in test mode I copied everything over to the production G4, set it to boot in Classic, and let 'er rip. Everything has been solid since, about a month now with no downtime.

I think the lesson learned here is to use better practices in terms of implementing solutions. Because of the ease of use, self repair on restart, and easy painless converion through versions of FMP, I became (was? am?) lazy and made changes to production versions and migrated them through. What I should have done was to have the normal environment, separate test & production with clean, empty, archived copies of all solutions burned to CD to fall back on. Also for 5.5 I found that it was doubly important to upgrade everything. Part of the problem I had was not upgrading the Web Companion. I did upgrade the FMP version right away, but not the Web COmpanion. If I satayed with tthe stock v2 stuff it gave horrible crashes when accessed via the web. Upgrading to v4 on the Web COmpanion cured that, but by that time I had domne some damage to the files. Going back to previous versions of the DBs cured that as well. Live & learn!

[Steve T.]

HMMMM.....

My earlier success story seems to have been premature even though I had waited months to post. Without any significant changes to software or db's, all of a sudden we've had about 4 unexpectedly quit errors over the past 2 weeks whereas we had had several months of rock-solid performance.

We'll probably go back to CRON and restart each day if the errors continue, but it was REALLY NICE these past many months when it was all good. Or maybe we'll give smorr's AppleScript idea and valentc's (and FMFORUMS adm/mod's tips from other posts) to rebuild corrupted db's (or Vaughan's tip of saving an empty shell as a backup for re-importing data if needed). Unfortunately, our db was first made in FMP 2.1 and has grown over the years so going back to previous versions won't help much... gotta go from scratch, I guess.

Still, in the mean time, restarting each day at 3am is not a big inconvenience for us so I'm not going to start remaking our main db today... I'll just save it for "later" (wink & smile).

"Nudged Out of the Sweet Spot"-ingly Yours,

ST

[Steve T.]

FOLLOW-UP #3:

Well, it seems once every 1-2 months, FMP either unexpectedly quits or just stops serving on the web (everything looks ok on the admin side). At this point, we are not auto-rebooting the all-X machine since it is non-critical information and these problems are still infrequent (unlike some of the every day quit folks). As of today 7/11/2003 there are posts mentioning Netscape 6.0 and/or interrupted requests/loads as possible culprits.

User dwal already links that thread to this one, so I am linking this one back to that one... I hope the answer ends up in one of these threads someday...

Unlimted Stops Hosting thread

We are still happy with our MacOS X 10.2.4 / FMP-u 5.5 combo, though... despite the occasional quits/stops. We're now running 8 db's on it, although some are internal and light load. Good luck!

[tmoney]

We recently moved from Filemaker 4.0 (not even 4.1) on OS9 over to Filemaker 5.5 Unlimited (with all current updates) on OSX 10.2.6. It has been a very bad experience. It was stable in FM4/OS9, but now we have daily crashes - usually multiple crashes a day. I have been in touch with Filemaker and done everything they suggested (full recovers and all that jazz). We even broke down and bought a 1.25Ghz G4 and moved it all over there but we still have crashes (only now we recover faster ). The only suggestion from FM support now is to rebuild our databases from scratch, which is insane considering this software is a product that has grown over 10 years and has plenty of dbs and plenty of fields.

While there are no consitencies in the logs that are helping be track down the problem, it does do the same type of crash every time:

Exception: EXC_BAD_ACCESS (0x0001)

Codes: KERN_INVALID_ADDRESS (0x0001) at 0x07661608

Thread 0 Crashed:

#0 0x05369eb0 in Run__Q22wc13TaskQueueImplFRCQ22wc15Ref<Q22wc4Task>

#1 0x054104bc in Run__Q22wc15FMTaskQueueImplFRCQ22wc15Ref<Q22wc4Task>

#2 0x053167c8 in RunMainAppTasks__Q22wc19AccessCompanionImplCFRCQ22wc15Ref<Q22w

#3 0x0532a214 in HSRV_NetworkIdle__Fv

#4 0x0528365c in FMExternCarbonCallProc

#5 0x0040f690 in CallFMExtern

#6 0x004110f8 in FMXC_Idle__FUc

#7 0x003c2308 in DOC_Idle__Fv

#8 0x003fff8c in DispatchNullEvent__9CFMProAppFRC11EventRecord

#9 0x00619694 in 0x619694

#10 0x0061938c in 0x61938c

#11 0x0061928c in 0x61928c

#12 0x00607094 in 0x607094

#13 0x003fee38 in main

To me it certainly looks like a bug in Filemaker. Even if it IS some type of corrupted database, you'd think the software could catch the exceptions or whatnot and prevent unexpected crashes and maybe help me narrow down where the problem is ("The file X is corrupt and would have caused Filemaker to Unexpectedely quit if we weren't good coders and caught this exception"). Rebuilding one database from scratch is more likely than rebuilding all 45. So this IS a bug - any way you look at it. I've tried going back to OS9 with FMU5.5 also and I've still had crashes - and those usually take the entire system down. At least in OSX I can recover better.

We're not thrilled right now about spending the $1,000 on FMU5.5 (last year sometime) and from what I understand, FMU6 has the same problems and wouldn't be worth the price of the upgrade. Going through these forums makes me realize that we're not alone with all this. Why isn't there better error handling implemented yet?

I might have to strip out the minor updates we've made and go back to FM4.0 on OS9. That will take a good deal of time though and leaves me very little faith in all things Filemaker.

Any new suggestions for my problem here or thoughts on how to get Filemaker to fix this bug would be great.

AND IT JUST CRASHED WHILE WRITING THIS.

[Steve T.]

Hi, there! I feel your pain and can sympathize even though I'm in pretty good shape right now myself. If crashes are that frequent, maybe try testing in small sets as you kinda hint at... maybe 5 sets of 9 db's tested 1 set at a time (or however they break cleanly). Or maybe you could run both FMP4 (for most of yor db's) and FMP5.5-u (for the few db's that need the extras) if it's not all wholely intertwined.

I have NO idea what your error message means... I've never seen anything like it. I think a friend of mine said something about new Macs having a new kernel in the OS, though, so maybe it's a new incompatibility for which FMP, Inc. has to put out a patch? I dunno. We use 10.2.6, too and don't have trouble on our humble 300MHz machines.

Sorry. Maybe someone else will know more. --ST

[tmoney]

Well, I've reverted back over to OS9 and now at least the machine stays operational for our employees to use it all day, BUT, as soon as I quit out (but fortunately after all the files are closed safely) OS9 freezes. I need to quit out to do backups of our data (and yes I am researching a Filemaker Server option for hosting the db's while FMU simply serves them to the web). But anyway this really sucks because I access our server remotely and once it freezes it's all over. I assume the corruption that is killing the OSX version unexpectedly is probably causing OS9 to freeze on quit.

Any thoughts on that?

[Mariano Peterson]

I hate to admit this, but FMP (all versions) are much more stable (and faster) on Windows. IMHO, you should switch to a PC.

Without testing your database myself, I don't know for sure if this will solve the problem, but I think it is definitely a strong step towards stabilizing a production platform. I always advise against using Macs & FileMaker in a production environment, simply because they're not very stable, and to a much lesser extent because FMP runs much slower on Macs.

This is not to say that FMP on Windows is fault proof - it may crash there as well. However, I still say it is many, many times more stable on windows. Sorry .

Also, I think you should definitely invest in FM Server if you have multiple users accessing the database. You'll only need FM Unlimited if you have more than a few (10?) ip addresses pinging FM Unlimited within a 12(?) hr period. If you have a middleware app, like Lasso or PHP or ASP, then only one ip will be pinging the web companion (the IP of the machine running the middleware) and you won't have to worry about using Unlimited.

[Anatoli]

You can use FM4 or FM5-6 Unlimited ONLY for web serving of more than 10 IP's in 12 hours. Not using FM5-6 Unlimited in such case is against FMI license or FMI may call that unlicensed usage, who knows.

[Gisle]

Hi there!

Glad to find this thread, im having problems serving a web database reliably with OSX 10.2.6 and FM-U 6.0v4

I bought a g4 dual 1.42 mhz with a gig of memory to sereve our solution and it has been a great disappointment. I get "unexpected quit" almost every third day. The is performance is also slow.

Here are some of my observations for how and when it happens:

1) I suspected the cause to be the use of Scandinavian charaters in user names when logging inn. It happens almost instant when these characters are presented as a user name.

2) Another possible cause could be attack of the nimbda worms on the server, i sometimes see these random URL requests on the access logs prior to a unexpected quit.

3) Today i worked on a copy of the database at home, on a G4, it quitted on me, when checking the base at work it had also quit almost simultaneously at a time around 13.00. My unexpected quits are usually at this time of the day. This suggests there is something connected to time issues/time localization that generates this?

I'm very glad for any help. Maybe someone should make a poll if everyone experience this kind of quits?

Also: Will it make a difference to run Filemaker in classic (i cant bot into os9 with this G4)

Thanks!

Gisle

[jfurness]

I keep popping back to this forum in the hope that someone is able to post a solution to this very frustrating and potentially damaging situation. I work at ULTRALAB, a learning technology research lab where we use and have used Filemaker extensively for many web delivered projects. I feel very despondant wth using Filemaker at all now - it just isn't stable yet I continue to plug it's versatility as a web database platform that allows rapid prototyping and development to take place.

I am running FM 5.5 Unlimited. In OS X 10.2.6, filemaker unexpectedly quits several times a day. I have even written an AppleScript which checks to see if Filemaker is running (every minute), if it isn't, it launches the FM application and opens all the databases. This works a treat until you discover a corrupt database which needs recovering (happens once every 3 days)

The project involves 400 people and the database receives over 1000 page requests a day. I am confident that Filemaker can support this activity - it isn't that much in the scheme of things.

In desperation, I have tried many options. I have now moved the databases to an OS 9.2.2 machine. Filemaker now runs for a day and a half without crashing (same no of hits) but it still crashes!

Something to note is that once upon a time I did have Filemaker running reliably for months and months using OS X 10.1.5 - not sure why. When I upgraded it all went belly up.

I have been in contact with the technical team at Filemaker. They suggest using uncorrupt copies of the databases - as someone said, it's daft cos the databases will just corrupt again.

They mentioned the technical people are aware and are writing a patch - somehow i don't believe it - it has been too long already.

Any thoughts would be appreciated....

[Anatoli]

Read Mariano Peterson's contribution above.

BTW I am saying this for 2-3 years now.