fm9 bug, corruption or both? grrr.

[Reed]

So I recently upgraded a production system up to FM9, and immediately (within 12 hours) came across a disturbing issue where a script keeps calling itself in a loop even though there is no loop and no recursive call.

At first I thought I'd found a bug in FM9 since using the exact same file with fm8 or fm8.5 did not show the behavior. But copying and pasting the script steps from one script to a new empty script makes the problem disappear, so I guess the file (or at least that script) is corrupt.

I've attached the file in case anyone wants to have a look. The username and password for the full access account are both "root".

There are instructions in the file in red text directing which buttons to push to try and reproduce the problem. (In scriptmaker, the scripts in question are "complete_sample" and logout) I've seen this behavior both hosted and locally on both OS X and Win XP.

I've fixed the problem as I mentioned, but the scary thing is that it makes me wonder what else is messed up with this file. Especially since this file has never been crashed going back through a couple of years of timestamped backups, even the old files show the same issue with FM9.

Just wondering if anyone else has noticed this and if anyone has any suggestions besides rebuilding the whole database from scratch (which I plan to do in about 9 months when whole department's financial model will be changed).

fm9bug.fp7.zip

[normanicus]

I think I have had the same problem. I posted the below to another board (of experts) and no one there seemed to have an answer:

Hello,

The client has several price lists that need updating periodically. I have a separate table for each of them and do the import from Excel. All this goes OK. I played with various methods of applying changes to the main table (the one the users use). Yesterday a tried a looping script like this:

Go to Layout [ “Sony Import” (Sony Import) ]

Set Variable [ $FoundCount; Value:Get ( FoundCount ) ]

Go to Record/Request/Page

[ First ]

Loop

Set Field [ Sales Stock Generic::Make; "SONY" ]

Set Field [ Sales Stock Generic::Category; Sony Import::Category ]

...

Go to Record/Request/Page

[ Next; Exit after last ]

End Loop

The import table is related to the main table by the model name. The script loops through the imported records and updates any related ones. (I handle new items separately).

Trouble is that this script does not exit. It gets to the last record and keeps going. I have to hit ESCAPE a few times to stop it.

I then tried:

If [ Get ( RecordNumber ) = $FoundCount ]

Exit Script [ ]

End If

Same problem.

After several experiments I ended up doing it like this:

Go to Layout [ “Sony Import” (Sony Import) ]

Set Variable [ $FoundCount; Value:Get ( FoundCount ) ]

Go to Record/Request/Page

[ First ]

Loop

Set Field [ Sales Stock Generic::Make; "SONY" ]

Set Field [ Sales Stock Generic::Category; Sony Import::Category ]

...

Go to Record/Request/Page

[ Next ]

If [ Get ( RecordNumber ) = $FoundCount ]

Halt Script

End If

End Loop

Note that I had to use 'Halt Script' to terminate the script.

So, is this file corruption, is there something simple I haven't learnt or it it me?

BTW, I tried this both locally and from a served version.

[bcooney]

I've had a look at the "bug" file and cannot get the problem to happen. What button runs "complete_sample"?

As for the second post, are you sure that you are setting fields from the correct context? You haven't used the anchor/buoy technique to name TOs, so I can't tell where you are when you're setting fields.

[Reed]

after you:

1. Click "logout" to enter kiosk mode.

2. Click "Login" with account "user" to reach the user's account screen.

3. Click run to choose the appropriate budget (only one choice in this case.

then, if you are using FM9, clicking the Log Off button will call the "complete_sample" script and put you into an endless loop unless you cancel the script. This only happens in 9, not in 8 or 8.5 (I didn't test 7, since I don't know where my CD is)

If, instead of clicking Log Off, you click "Fix" an identical script is called, where the bug is not encountered even with v9. I did not remake the script, I simply copied the steps from the broken script to a new blank one.

If I duplicate the script and use that one, then the bug still happens.

Let me know if you still can't reproduce the bug with v9, and if so, let me know the exact setup of the machine you're using.

Thanks,

Dana

[comment]

I think I have followed the procedure, and it always gets me back to the user login, whether I click 'Log Off' or 'Fix' - and this is on v.8.5 (OS X 10.4.9, PPC).

Could you perhaps devise a simpler test file?

[Genx]

At first I thought I'd found a bug in FM9 since using the exact same file with fm8 or fm8.5 did not show the behavior.

I believe the problem only occurs for him when the file is run in FM 9.

[Reed]

That's right, it's only with v9, on either 10.4.10 or XP.

Another thing that's fishy is that if I run through the same script using 9 advanced with the debugger on, then it doesn't get caught in the loop... weird.

[Reed]

Also, I'm sure if I make a similar script in a simplified example file rather than my actual db file, then the problem will go away, since using a new script makes the problem disappear. Clearly there is a problem with my file (at least that script), but it's only apparent when using v9 or v9 advanced.

[comment]

I got confused because your "fixed" script ends up in a loop of its own: you get back to the user login and there seems to be no way out, other than to quit the application. I have now tried this on v.9A and seen the "real" loop. But the file is too complex for me to try and find the cause.

Try making a copy and deleting stuff until either the problem goes away or you're left with a demo of the problem in isolation.

[Reed]

sorry, I forgot to mention that you can only get out of kiosk mode if you log in as "root" with the password "root".

What seems to be happening is that the "complete_sample" script calls the "logout" script in its last step, sending you back to the login screen. But when the logout script ends, returning to the complete_sample script, it doesn't return at the same line in the script where it left off. Instead, you are returned to the second line of the script, after which you proceed through the script until "logout" is called again. This repeats forever unless you cancel the script.

I added the custom dialog steps to show which line of the calling script you are returned to in the loop. The problem appears to be only with the complete_sample script and the point in the script to which it returns from the subscript. If I add a "halt script" step at the end of the "logout" subscript, then the problem also disappears.

Sorry I'm having such a hard time describing this problem, but it's harder to explain something when it can't be reproduced in a separate demo file, and the conditions are so specific....

[normanicus]

I checked which table the script was running in and it was in the correct one. I could see it stuck on the last record in that table. If I had been in the wrong table then surely my test to see if I was on the last record would not have worked.

[bcooney]

Not table, table occurrence.

[Reed]

I'm working on figuring this out and making a simpler demo of the problem. I was able to reproduce the problem with the remade script this time since I realized that the scripts were not actually identical. The new script was not being run with full access privileges, and the old one was. When I changed the setting on the new script, the looping problem appeared in that script as well.

I think that the problem arises since the "complete_sample" script starts when you are logged in as "user", then it calls the "logout" script, which among other things relogs in as "dummy". Then when the "logout" script finishes and returns to "complete_sample" there is a problem because "dummy" isn't allowed to run "complete_sample", but you only see the problem if the script has been set to run with full access. (and only if you're using v9, which is why I think this is a bug)

I'm going to produce a simple demo file that does this without involving kiosk mode, and then I guess I'll post an official bug report...

[Reed]

I've made a simple demonstration file of the bug, and posted it in the FM9 subforum, since I think that's the best place for it.

http://www.fmforums.com/forum/showtopic.php?tid/191073/

[Lee Smith]

Please do NOT double post. I will be deleteding your other post, so just continue this one.

Lee

[Reed]

OK, here's the file...

testbug.fp7.zip

[comment]

It's a bit weird - but the situation you have set up is even weirder. Your subscript runs under the current privileges. You relogin as a user with no script-running privileges, but the script continues. What is supposed to happen?

Ideally, the script would halt at this point. I think the reason it doesn't (in 8.5) is that Filemaker checks the privileges for the entire script in advance. So one could say this behavior is faulty, since it allows a user with no privileges to continue with the script.

Version 9 is actually improved in this aspect (run the subcript on its own in both versions to see the difference). It seems your bug is a result of the main script being somehow aware that the subscript has not fully executed - therefore it goes back and tries again.

[Søren Dyhr]

since it allows a user with no privileges to continue with the script.

But only the subscript is abandoned, the waiting script are still in the original users ID, what is weird is that the script execution pointer keeps it's value and continues in the calling script from there.

I had a suspicion that the account was kept on the stack taking the waiting calls. So I tried out a recursive script to establish this ... take a look - it turns out that the current account isn't stored on the stack while the scriptparamters revitalize them selves to present values as the recursion unwinds!

If you however put disallow scripting on the cc password does it simply teminate further scripting this happens when breaking the recursions out in seperate script as well.

Is it posible to import a buggy script?? It seems to happen when I imported the buggy script in a newly created file... have anyone tried to replicate the error in a new file by entering the script manually??

--sd

test.zip

[Reed]

I think you're right that the subscript should halt, but so should the main script, rather than trying to reexecute most of the main script. Also the fact that it restarts the main script from the second line doesn't make any sense.

If you give the dummy user privileges to execute the subscript, then it finishes as you would expect, but still returns to main at the second line rather than where it was invoked, and the loop still continues.

The other thing of note is that if you uncheck the "runs with full access" box in the main script, then it doesn't go into the loop.

[comment]

the subscript should halt, but so should the main script

I don't see why - the main script is run with full privileges, so it has no qualms about proceeding. The only thing that's wrong - so I surmise - is that the subscript has not returned an OK.

No doubt there's a bug here, but the circumstances required to evoke it are so esoteric, that it should be possible to avoid it - possibly by moving the relogin to the main script.

[m.v.peabody]

GRRR.....

Is that short for "Go Ruin Related Record"?

I'm not familiar with that one . . . . not in Filemaker, anyway. :(

[Søren Dyhr]

evoke it are so esoteric, that it should be possible to avoid it

Indeed, esoteric!!!

--sd

[Reed]

certainly it's possible to avoid this bug, but only if you know about it...

My original file had been running 24/7 this way since 2004 when I rewrote my old FM6 solution. I didn't expect updating the client machine to FM9 (especially since I'd been running the file with v9 and had been testing it since June) would have this effect, and it ended up costing me a few hundred dollars in lost sales when I put it live into my kiosk mode machines.

In any case, it might be good to have some documentation about what exactly should be the expected behavior of scriptmaker when the account name changes in the middle of a script or subscript.

I don't like being the one to find the bug, no matter how esoteric....

[Reed]

GRRR.....

Is that short for "Go Ruin Related Record"?

maybe it's a message to the script to

"Go Run Really Rampant"

[comment]

This is not the first time FMI has changed the order in which some of its actions are performed, resulting in broken solutions. I must say if I found myself changing privileges in the middle of a sub-script like that, I would have wondered about that - precisely because there is no documentation regarding what comes before what.

I think you should ask the moderators to move this to Accounts & Privileges, where it might get the attention of Steven Blackwell.

[Reed]

I posted this to Tech Talk and Rich Kalman told me he'd put it in the FMI Bug database, so hopefully something will be done about it at some point. At least now that I know about it, I can work around it.

Thanks,

Dana

[Steven H. Blackwell]

I think you should ask the moderators to move this to Accounts & Privileges, where it might get the attention of Steven Blackwell.

Indeed, I wondered where this entire thread just appeared from seemingly out of nowhere. I spent all of last week at FMI, and this did not come up. OTOH, we were a bit busy.

I will review and get back to you. But I gather that the essence of the complaint is that switching user accounts in the middle of a script or chain of scripts causes problems?

One thing to remember is that subscripts called from a script set to Run script with full access privileges do not inherit the full access powers unless they themselves are also set to run with full access.

Steven

[Søren Dyhr]

One thing to remember is that subscripts called from a script set to Run script with full access privileges do not inherit the full access powers unless they themselves are also set to run with full access

It's not quite the case here, the image shows when it goes wrong - keep in mind that the change of privileges are done in the subscript.

Why is the wrong line chosen in the Main script when the subscript can't continue due to the change of privileges or simply ends, the only difference from full/unchecked vs. full/full is that the steps after the change of privilges are done in the later, but then does the script continue back to line just above where the subscript were called from.

--sd

[Reed]

just for the record, I just installed the 9v2 update (only for Windows XP so far) and the behavior is the same.

[Søren Dyhr]

I tend to believe this statement:

I spent all of last week at FMI, and this did not come up

...you've just managed to find something else!

--sd

[Reed]

9v3, bug's still there.