1 2 Previous Next 18 Replies Latest reply on Dec 2, 2014 7:10 AM by TSGal

    URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...

    StefanSmith4873

      Summary

      URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any further

      Product

      FileMaker Go

      Version

      13.0.2

      Operating system version

      iOS 7.1

      Description of the issue

      I have an application going out to 2000 people but my development is absolutely halted at present due to this SERIOUS BUG in FileMaker Go. 

      The application is quitting when running a particular series of scripts.  Under FM Pro it is not an issue.  These scripts contain nothing out of the ordinary AND I can stop the bug from occurring by introducing a series of SHOW CUSTOM dialog boxes!  This appears to slow down the application and when these custom boxes are introduced the app works fine EVERY TIME!    Removing these custom dialog boxes causes the app to crash on every single iPad we have tested -- the crash happens in less than 1 second.  Our solution uses multiple database files linked together.

      The custom dialog box was found by accident....in order to see where the app was crashing out I added customer dialog boxes to show me messages so I knew how far into the scripts it had got. 

      Eventually this causes the scripts to work fine EVERY SINGLE TIME.  Once enough of these were added, the app would NOT quit and complete the series of scripts. 

      The boxes were removed....and hey presto....FileMaker Go crashes!

      Steps to reproduce the problem

      In our current development of our filmmaker go solution, simply running the script we have causes an iPad to crash every time.

      I also have a version which does not crash...and all that version does is display custom dialog boxes.

      Expected result

      NOT TO CRASH

      Actual result

      FileMaker GO exits back to IOS HOME SCREEN

      Exact text of any error message(s) that appear

      None

      Configuration information

      None

      Workaround

      There is none!  We cannot develop our app any further unless a new version of FileMaker Go is released.  URGENT HELP REQUIRED.

        • 1. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
          StefanSmith4873

               UPDATE:

               Please can a FileMaker Tech Support person please contact us urgently regarding this.  We have now isolated the problem further and have various files in different states to demonstrate the problem.

               The problem 150% lies within the use of FLUSH TO CACHE commands.

               Ever since FM Go 12 we have experienced issues with crashing.  As a result, in other apps we have developed the use of the FLUSH CACHE TO DISK has helped reduce data loss during FM GO use.  Without this command we were experiencing a lot of data loss.

               In the new app we are developing --- the one where we have been able to replicate a fatal crash within FM GO, as mentioned above we have found that a number of custom dialog boxes were somehow making the app NOT crash.  

               The script which starts the process in turn calls numerous other scripts.  Our standard practice is to issue  a FLUSH TO DISK command wherever possible so we are always keeping data up-to-date because we see so many crashes.

               This is the first time, however, we have been able to replicate without failure a total failure of FM GO.

               We have now removed the FLUSH TO DISK commands from every script that runs through this process.  This has resulted in us removing all but two of the SHOW CUSTOMER DIALOG commands.

               Put another way:

               The main script which starts this process was not completing before it crashed!  Adding customer dialog boxes got us through that script onto the next major script.  Call that Script 2, if you like.  By removing ALL FLUSH TO DISK commands from script 1 we have been able to get to Script 2 WITHOUT the need to display custom dialog boxes.

               We have stripped back Script 2 in the same way...and now we can make it all the way to Script 3 before the need to display a customer dialog box!

               Through repetitious testing we have scaled back 7 x Show Customer Dialog boxes which guaranteed the app would not exit, down to 1 show customer dialog box!  And all we have done is remove unnecessary COMMITS and FLUSH TO DISK commands.

          • 2. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
            TSGal

                 Stefan Smith4873:

                 Thank you for your post.

                 I'll be happy to look at the file and hopefully determine why the script is crashing.  Check your Inbox at the top of this page for instructions where to send the file.

                 TSGal
                 FileMaker, Inc.

            • 3. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
              MarcHill

                   We have a similar issue here, though not as consistent as what was originally posted.  I have a FileMaker Go application that has a script that loops through a series of web viewer windows as it is parsing data and sending information back to the server (this can happen once or multiple times in succession...it all depends on the data they are using on that particular day).  It happens randomly, but for whatever reason, at some point in the web viewer part of the script it will exit the user to the iOS home screen.  In all cases I have encountered the file is then corrupted rendering it unusable.  When it happens, we have a clean copy that is loaded to the device and then it works fine (I may not see that device again for some time).  We have this application deployed on at least 15 iPads and it is completely random as to what device experiences the problem.  The same logic, and same file really, worked fine (no damaged files) in FMGo previous to 12 (we are running 12 now, plan to upgrade to 13 this summer).  I only had the issue happen to me once during testing; in most cases, I just have staff showing up at my desk with a damaged file dialog, so I am typically not there when it happens.  Anyway, with my experience, I looked through all of the data to find if there was perhaps an issue with something that was being parsed and found nothing.  I took the clean copy, ran through the same data and it worked fine.   All signs point to the web viewer being the issue (my experience, coupled with my queries of staff confirm that the issue appear when these web viewers are being invoked). 

                   I'm happy to provide a file, but as I mentioned, it is a random occurrence, so I don't have a formula for repeating the issue.  I was hoping that perhaps my experience coupled with the original post might help lead to an answer.  Any help/guidance is deeply appreciated.

              • 4. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                TSGal

                     Marc Hill:

                     Thank you for your post.

                     In the file sent in by "Stefan Smith4873", it appears to be a timing issue.  When a Pause/Resume Script step with a Duration of 0.3 seconds was added in the loop, there was no crash.

                     What else are yo doing within the Loop?  Let the WebViewer load the information before extracting the data.  That is, try inserting a Pause/Resume Script of Duration 0.5 seconds just prior to extracting the WebViewer data.

                     Keep me updated with any progress.

                     TSGal
                     FileMaker, Inc.

                • 5. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                  MarcHill

                       TSGal,

                       Thanks for the quick reply.  At the web viewer layout, the loops are waiting for a response from the PHP files we have on our server (which use FX to speak to FileMaker).  See sample below:

                       Loop

                            Pause/Resume Script [Duration (seconds): 1]

                            Exit Loop If [$Counter > Case ( IsEmpty ( Driver Route::Web Viewer Timeout ) ; 10 ; Driver Route::Web Viewer Timeout ) or PatternCount (GetLayoutObjectAttribute ( "RequestPage" ; "content" ) ; "Request Receipt Confirmation Received" )]

                            Set Variable [$Counter; Value:$Counter + 1]

                       End Loop

                       There is a similar loop later in the script that talks to PHP after some information has been processed on Go that follows the same exact logic, just looks for a different pattern.  As you can see, we have a pause for it to wait to get a response from the server, but once it gets the response, or if it doesn't after a maximum of 10 seconds, it immediately moves on.  So, basically, we are just waiting to read the statement that PHP sends back "Request Receipt Confirmation Received" in the example above. 

                       If I read/understand your recommendation correctly, perhaps I should try adding a second pause after each loop sequence to "give it a chance to breathe" before moving on?  In production, this process can be quite seizure-invoking as it rolls through these web viewers (depending on the # of records to process)...perhaps if circumstances are right, it can get caught up on itself.  I'll try adding another pause after each web viewer/loop sequence to see if that helps.

                       I will communicate the results as they are known (I expect to release a new version of our application in the next week or so).

                       Thanks again!

                       Marc

                        

                  • 6. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                    TSGal

                         Marc Hill,

                         If you already have a Pause/Resume Script step within the Loop, there is no need to add another.  Plus, the Loop is referencing fields in one record.

                         Rather than adding another Pause/Resume Script step, just before the Loop construct, put data into a field (possibly record number) and commit the data.  When the loop exits, update the field with some information to let you know the loop finished, and commit the data.  This way, if the file crashes, some data will exist in the file, and you can pinpoint where the file is crashing, and it may be specific to a single record.

                         Continue to keep me updated.

                         TSGal
                         FileMaker, Inc.

                    • 7. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                      StefanSmith4873

                           To Marc Hill:

                           We have the same issue and we experience random crashes multiple times per day.

                           1. Do you have any FLUSH CACHE TO DISK commands in any of the scripts?

                           2. One of the things we know from our testing which definitely reduces the number of random crashes, is if you are able to close the database and re-open just prior to it performing this "looping script".  From our observations, the crashes we experience are when there are daisy chained scripts running i.e. it is working hard, many times across multiple tables and records. 

                           Example:  We have an OFFLINE solution which synchronises to a server.  When a user uploads their quotes and orders, there is a heavy duty script which is running that loads up many other scripts.  This is a place where we often experience a crash.  We normally experience a crash between 1 and 6 uploads to the server.  However, we have found that if we close the application after 3 uploads, then re-open, upload another 3, close the database, re-open and so on, then we rarely see the crashes.  

                      • 8. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                        MarcHill

                             TSGal:

                             I thought we were on to something there with placing a pause after those loops.  Anyway, I'll try your suggestion, but because the files have, to date, been corrupted and unrecoverable after our crashes, I'll have to engineer it so that it sends that data to the server via our PHP interaction.  I wiill let you know results.

                             Stefan:

                             I appreciate the information.  We do not have any FLUSH CACHE TO DISK commands.  The phenomenon we experience has been more recent (last 6 months out of 2 years of deployment) and very random (sometimes 2 in a week; sometimes none for a few weeks).  When you state that you close the application, have you engineered it to automatically close and then re-open or do you rely on staff to re-open it? 

                             ---------

                             Just for clarity, the script I believe is failing pulls in a list of records via PHP and then loops through to parse them into records the device can use.  As it is doing so, it communicates with the server to say, "yes I received this" and then again to say, "yes, it has been processed on the device" all through PHP which requires us to open a web viewer (and a new window) multiple times.  I'm convinced that it has something to do with the web viewer because we are able to see when it is processing where it stopped at the "yes, I received this" step.  For example, we have 3 records to process, the first and second go through fine with both server "handshakes" occurring, then the device crashes.  When reviewing the server table that holds the handshake information, we can see that the third record did not say, "yes, I received this", and the feedback I get from our staff as well as my own singular experience, was that it failed as the web viewer windows are being open and closed.  When I get a clean copy, reset the data, and try again, it invariably works fine, so it is not consistently repeatable and appears to have nothing to do with our data.

                             Thanks.

                             Marc

                        • 9. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                          TSGal

                               Marc Hill:

                               If possible, I'd like to see your file.  I realize PHP code is pulling records from a server, but that action could help us determine why this is crashing on a (semi-) consistent basis.  If you want to go this route, check your Inbox at the top of this page for instructions where to send the file.

                               TSGal
                               FileMaker, Inc.

                          • 10. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                            StefanSmith4873

                                 Marc,

                                 Your comments are interesting!  Since FMP12 we experience crashes DAILY....one of the most frequent (BUT STILL RANDOM) places it crashes is when we sync our OFFLINE solution to our server.  During this process it is running multiple scripts across many tables....and opening up new windows to jump to layouts like its going out of fashion.  

                                 Our users have developed a practice as follows.

                                 They will sync 3 jobs maximum to the server, close the database, quit to the iOS home screen, "kill FM GO", then re-open everything.  If they are strict to this, we have not yet seen a crash occur during the sync process.

                                 But, if we do not kill the application we often see crashes occur during this process.  

                                 For our newest solution which is still in development, entirely because we have found FM12 and now FM13 to be so unstable, we have changed our design methods to avoid opening multiple windows AND we have a small database file which when opened, closes the main database, then re-opens it again.  In testing, these two changes give the appearance of a more stable FM13!   Since our second solution is based on our first (except no code is shared; everything was re-coded from the ground up), we are not seeing the same problems when we have multiple scripts running across multiple tables.  We are still testing so in practice that could be turn out NOT to be the case but in the last couple of days we tested some heavy duty data sets which we were expecting to trip it, and it did not.  

                                 If you have the ability to close the database and return to it and continue from where you left off, I would place a very large bet it would make a significant difference.  In over 20,000 large sync transactions since we began using FM12, our sync 3 jobs only rule hasn't failed, and only fails when our users forget to close after the magic number 3.

                            • 11. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                              philmodjunk
                                   

                                        During this process it is running multiple scripts across many tables....and opening up new windows to jump to layouts like its going out of fashion

                                   Hmmm, I seem to recall an old bug where FileMaker had a limit as to how many windows could be opened. It may even have been a limit as to how many could be opened and then closed. I'm remembering something that pre-dates the Known Bugs List so I could be remembering incorrectly and who knows if the issue still occurs with current versions or not.

                                   There is also a known bug with windows and the correct focus that may be worth a look:  Incorrect Window selected when using a Floating Window and process window

                              • 12. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                                TSGal

                                     PhilModJunk:

                                     Your memory is correct.  Several versions ago (FileMaker Pro 7?), FileMaker relied on the OS window management, and Windows OS was limited to 15 or 16 open windows.  Mac OS did not have this limitation.  FileMaker Pro changed this design limitation (as did Windows), and this is no longer an issue.

                                     TSGal
                                     FileMaker, Inc.

                                • 13. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                                  TSGal

                                       Marc Hill:

                                       I received your file, and I have sent it off to Development and Testing for review.

                                       I immediately received a message from Testing that Web Viewer memory usage was improved with FileMaker Go 13.0v3, so make sure you at least have this version.  Regardless, Testing will be looking at your file.

                                       In your instructions, you mentioned to load "Today".  If Testing needs to continue on Monday, can you make sure there are also test records for Monday?

                                       TSGal
                                       FileMaker, Inc.

                                  • 14. Re: URGENT - Able to replicate filemaker go 13 crashing/exiting under iOS 7.1 - cannot develop app any...
                                    MarcHill

                                         TSGal:

                                         The request records automatically reset their "active" date...so if they are not grabbed and marked as complete today (Friday) they will be available to grab on "today" (Monday).  We designed it so that our staff don't have to worry about resetting dates, etc. if the request isn't complete...so you should be all set. 

                                         We will be putting out a new release of our application soon (next couple of weeks) and at that time we will be upgrading to FMGo13.  We haven't yet done so because this is some of the busiest times for the devices during the year and changing things in the middle of it didn't seem prudent.

                                         Thanks again.

                                         Marc

                                    1 2 Previous Next