Consistent crash from Popover triggered script

[Justin P.]

 

In the midst of trying to tune a solution for better WAN performance, I started to get consistent FMPA v14.0.1 and FMPAv14.0.2 crashes with a particular script. The type of crash that kills the whole Filemaker app (on Mac OS X 10.10.5). This was not a problem previously, but seems is now consistent for this one action.

The actions are related to modifying a value within a pop-up, and then running some triggered scripts upon dismissing it.

I laboriously traced through a bunch of scripts by gradually moving around an Exit Script step and found that the offending command is, believe it or not, a Go To Layout command. If I leave it in (even if I replace it with a new line for same layout)  I get the crash, if i comment it out, actions continue.

Behaviours:

• Tested it on a local machine and hosted, crashes the client FMPA version each time.
• Deleted the offending GTL command and wrote that line again, same result.
• The layout itself is used for other scripts, haven't noticed other crashes.
• A recover on the file found nothing of note, but recovered file crashes also. 
• Fearing record corruption, I tried creating a clone, populated a few new records, and tested it again, same crash result.
• If i step through this using the debugger, no crash happens. Memory management issue or similar?

I have a few more things I will try for hope's sake (e.g. rewriting the whole script), but wondering if anyone else has seen script caused crashes, and what they may have done to get around it? This and very inconsistent WAN performance slowdowns (<0.5 second logged for an action, that every now and then takes 10 seconds), been really getting the better of me! 

Thanks for any advice.

 

[Justin P.]

Additional tests:

• Duplicating the script and calling the copy instead of the original made no difference.
• Changing the GoToLayout command to use a different layout made no difference.
• Copy all the script steps into a new blank script, try calling that one, which I thought would work, but made no difference.

Exasperated!

[LaRetta]

Hi Justin,

If a script is corrupt, it is never good to copy steps from it since you can copy over the corruption.  Have you tried writing the script again from scratch?  What does the Recover log show - does anything stand out?  Does it indicate the file is safe to use (listed at the end)?  Recovered files should never be used except to test to see if Recover resolves a problem.  If it does resolve an issue, one should instead copy their data into a clean, undamaged backup copy.

With what you have presented, an obvious cause does not jump out at me and we would probably need to see the file itself.  :-)

[Justin P.]

LaRetta: thanks for the notes. Recover reported it as clean. I was not aware of recovered files being unusable, but will note that for future. 

Update 2:

I think this is related to the popover interacting with the script.
If I attach the same script to a button or field, no crash. But if I attach the same script to a completely new blank popover button, it still crashes. 

The oddity here is that this is an introduced instability, as the exact same popover worked perfectly well for months, up until I tried rewriting the script.

Edited September 2, 2015 by Justin P.

[LaRetta]

Interesting.  Then it does not seem to be Go To Layout causing the issue?   I am not aware of any bugs with Yosemite and popovers but that does not mean a bug may not exist.  I am willing to review the file and if you wish to keep it private, you can private message me.  I would like to see you get to the bottom of the problem.

Have you ran the 14.0v2 updater yet?  http://www.filemaker.com/support/downloads/

If not, I would do that first.

added:  Oh I see you've ran the updater - I'll leave that part in for others reading who may not be aware of the v2 updater.

Edited September 2, 2015 by LaRetta

[Justin P.]

Thanks LaRetta, very much appreciate the assistance.  I will attach a cut down version of the solution here as soon as I can prep it.

My suspicion at the moment is an interaction of a modified field and dismissing a popover to trigger the script. If I update a qty, click outside to save it, and then activate and dismiss (trigger) the popover, will usually not crash. But if I click straight from the qty field to the popover, crashes.

 

[Justin P.]

Here's a demo file where the crash is repeatable (at least on my iMac and MacBook), just the bare basics that still showed the behavior. Also a few workarounds shown (basically, avoid the script trigger).

All crash scenarios are related to a changed field within a portal, then dismissing a popover with a script attached (well, at least this Go To Layout script) before saving the field change. Steps are listed within the demo file.

This file instructs you to dismiss the popover by clicking within a portal row. I also have seen the crash in my larger solution when clicking outside the popover and outside the portal, but was not consistent, and not replicated here. Additionally, I tried redirecting the GTL to the main layout (not a different layout), and this stopped i from crashing. So the actual command in the script has something to do with it.

 Curious to know if this doesn't crash for your environment!

2015-09-02 Crash Demo.fmp12

Edited September 4, 2015 by Justin P.

[LaRetta]

Hi Justin,

Yep, it crashed for me as well.  You have a damaged layout.  If you change your popover OOExit trigger to go to a newly created layout, it does not crash.

And you are correct, Recover shows the file is fine but it is obviously NOT fine.  And it is prime example that we cannot fully trust Recover when it says files are okay and why if a file is improperly closed, it should be considered potentially damaged and simply replaced with backup.  

The best move now is to grab a pristine (never-crashed) copy of your file and build forward on it instead.  If you cannot then delete that layout and use a new one.  There is possibility that objects on that layout were damaged as well and, if it were me, I would rebuild all objects/fields for the new layout instead of copying them over.

As an aside, a few other points, probably stemming from a rush to provide the demo file ... but I want to mention them just in case:

• You joined Orders::id = LineItems::OrderID.  However, you have specified LineItems::OrderID as auto-enter serial.  That of course will not work.  LineItems should have its own ID as auto-enter and another field should hold the OrderID.
• You have specified using Get ( UUID ) but the data type for both your keys are number.  You'll want to change them to text.  It is also wise to set validation to always unique.
• When hiding objects in your LineItems portal, IsValid() is not a good choice; in fact, it is not a good choice to ever test a relationship.  Instead, hide objects on the empty (allow creation) row as:  IsEmpty ( LineItems::ID )

Sorry my news about your file isn't better and I hope you have a good clean clone from which to revert.

 

[dwdata]

I did test your demo file. You have documented the behavior well.

So... Is it more important for you to know why this is crashing or find a workaround so there is no crash?

Just curious :-)

[Justin P.]

Thanks for the analysis everyone. 

dwdata: was wondering about the root cause of the crashing more than anything. I have already implemented a work around (which was to remove the script trigger and force a button click for update) which is working for now.

LaRetta: Awesome suggestions, thanks.

• The join was a rush job for the demo, forgot to change one of them.
• But the IsValid v IsEmpty is good advice.
• So if the Child Table layout is corrupt, it is only manifesting in this very specific circumstance (I use that layout for many other operations within the full file). Because it took so long for this issue to show up in testing, and it is such a specific combination of script/popover/layout, I don't have an easy way to backtrack and rebuild from last good version. Nonetheless...
• ...I have a workaround that is operating without issue right now, but obviously am worried this will manifest in other script calls, so will replace the layout. It is easy to replace, it is a blank (no fields) layout for internal operations, just got to catch all the references to it in the DDR first.

Thanks again! 

[dwdata]

All reports and suggestions are spot on.

I was seeing the issue of the single record with a "?" in all the fields which I thought was originally due to a corrupted INDEX, but in further restore routines and trials, everything led back to the layout being the culprit.

So glad you found a workaround, but I agree with you your confidence in the stability of that file should be shaky.

Take care.

[Jim Gill]

Hello All - I'm late to this party but wanted to share my experience with a recent corrupt layout - that I corrupted.  Basically I have a hosted file (Server Advanced 14) with a HOME layout that has evolved since FMP 5.  We are all now on 14.   I started adding a few Popovers to the HOME layout when 13 was launched (I really like Popovers).  

Last week, in a bit of haste I launched Filemaker on another users machine and did a quick font size change to one text box in the HOME layout - literally a 10 second dev.  My mistake was I launched FMPA 12.xx   which did not recognize the Popovers and probably didn't know how to render them.  A few days ago we noticed that the Popovers were not working and as soon as I tried to do anything in Layout mode (FMPA 14) -  Filemaker crashed.   I tried to Recover the file - everything checked out.  I couldn't delete, move or edit the popovers or anything the Popovers were interacting with (Tabs in my case).  I could delete all other objects on the layout - just nothing the popovers were associated with.  All the other layouts in my file were fine and worked as they should.  I could delete the corrupt layout BUT it would break the hundreds of script steps that reference the HOME layout in my file.  My file is massive (3.2 gigs) with a couple hundred Tables and we were looking at pulling a non-corrupt backup and shutting down for about two days while we imported our data into the non-corrupt file.  It was looking pretty ugly.  

In a last ditch effort I went back to the machine with FMPA 12, opened the file and was able to delete the corrupt Popovers - and then everything went back to working as it should...   

I know this isn't Best Practices but so far all is good.  I have saved the non-corrupt backup file so if I run into problems down the road I can still go to the import option.  Also I have set the File to option to 13.0 and higher only.

I found this tread when looking for solutions last week and thought I would add my experience and maybe save someone a trip to the psychiatrist - it may be temporary but I will report back if further corruption is found.

Good luck out there!

Jim 

 

.