10 Replies Latest reply on Sep 5, 2013 9:16 AM by TSGal

    Memory Leak in SQL API

    StephenGBaker

      Summary

      Memory Leak in SQL API

      Description of the issue

      FileMaker Pro Version: 11.0v1Running on 10.5.8, have not tested on windows at this stage. When running SQL queries via the SQL plugin API there is a memory leak when certain queries are run. When running a simple query repeatedly for 100 iterations the leak is 6.7Mb.This result was achieved using the MMQuery plugin from CNS plugins but the leaks were first seen using the Reactor plugin, which was polling FileMaker for updated records. The following query was used to produce the leak.SELECT rowid, "bookings"."zmodid" FROM "bookings" WHERE  ("bookings"."bookingdate" = DATE '2010-06-10' )  interestingly removing the () from this query stopped the leaks ieSELECT rowid, "bookings"."zmodid" FROM "bookings" WHERE  "bookings"."bookingdate" = DATE '2010-06-10'  BUT this is not a work around as the example is a simple query, and most times the queries are much more complicated and leak memory even faster.This leak was tested with OSX Leopards  Instruments developer tool, and confirmed to be in the SQL parser. One of our clients is having difficulties with their Reactor calendar implementation in their solution due to this leak. I have a sample database and can produce Instruments traces if these would be of any help. Regards Stephen

        • 1. Re: Memory Leak in SQL API
          TSGal

          StephenGBaker:

           

          Thank you for your post.

           

          I don't have either plug-in to test.  I don't doubt this isn't happening, so it would be helpful here if you could send in your "sample database" file along with one or both plug-ins so I can give it to our Development and Software Quality Assurance (Testing) departments for review and confirmation.  I have sent you a private message (top of this page - right side - envelope icon just beneath the blue horizontal bar) with instructions where to send the files.

           

          TSGal

          FileMaker, Inc.

          • 2. Re: Memory Leak in SQL API
            maartenvanthof

            This problem is was there in Filemaker 10 and is still in 11. (v3)

            See http://forums.filemaker.com/posts/e5ad1e037f

            • 3. Re: Memory Leak in SQL API
              TSGal

              Maarten van 't Hof:

              Thank you for your post.

              This memory leak has been recently confirmed by our Testing department, and the issue has been sent to our Development department for further review.  No additional information is available at this time.

              TSGal
              FileMaker,Inc.

              • 4. Re: Memory Leak in SQL API
                maartenvanthof

                This memory leak is still there. The latest ODBC update mentioned that the SQL memory leak was solved. We hoped that this was also true for the API, but notso.

                This is still a major problem with our clients.

                It this still on the agenda?

                • 5. Re: Memory Leak in SQL API
                  maartenvanthof

                  I just tested the plugin again with FM12. (v2) (Demo file at http://fusionplugins.com/products/reactor/)

                  And still the memory problem is there. 

                  If I go to the calendar solutions and on the Mac you still see the memory groing over time. In the Reactron application the application refresh the calender a number of times per minute. Everytime the use of memory increases. This still happens in FM12 as in FM11.

                  This bug is already very old and makes our application running out of memory. 

                  Please put it on the priority list and tell us an estamete on the moment this is solved.

                  Maarten van 't Hof

                  • 6. Re: Memory Leak in SQL API
                    PeterWagemans

                         I just got this question  - linked to this support forum - on our own support forum for the DoSQL plug-in.

                         There is a mention in latest ODBC driver update that a memory leak was plugged, but this leak culd only be plugged in the driver, not in the engine, if you think about it logically.

                         Probably this is yet another leak.

                         The plug-in API does not use the ODBC driver, hence you can be sure that this is not fixed yet, in ANY plug-in that uses FQL.

                         The only workaround is to avoid the parenthesis, luckily in many situations you can.

                         As FileMaker is indeed very slow in solving this issue, maybe the people from the Reactor plug-in should think about writing some workaround code. My 5 cents.

                    • 7. Re: Memory Leak in SQL API
                      TSGal

                           Maarten van 't Hof and clarifix:

                           My apologies for the late reply.

                           Testing was able to verify the issue, but also verified the memory leak also occurred under Safari using the same link.  Can you verify?  This could be a Mac WebKit issue.

                           Also, please check with the makers of the Reactor plug-in to see if they are aware of the issue.

                           TSGal
                           FileMaker, Inc.

                      • 8. Re: Memory Leak in SQL API
                        maartenvanthof

                             We have tested this extensively. It does happen on Mac platform but also on Windows. 

                             If you go to an external browser and view the calendar, then the memory increase still happens. This memory increase happens on the FIlemaker application, not in the browser. And the increase happens at the moment an SQL refresh command is done in the plugin. So we concluded, after extensive testing, that any time the sql statements are used to get fresh data from the Filemaker table, and it does this to get the latest information in a multi-user environment, the memory use increase. Our workaround so far is to decrease the number of times a refresh is asked for. Default it refreses every second, but we have set it to 10 minutes. We accept that a new appointment made by user number 1 is not shown in the calender in the display of user 2. By increasing the time between refreses we where able to get a workable situation. As soon as a user logs out, the memory is set free off course and because one stops at the end of a workday, we prevent the crash of the workstations. 

                             An other observation why we think it is not the webkit, is that as we use our system with the preferences that does hardly any refresh, we can open and close the page in the external browser without any increase in memory.

                             The Reactor people are aware of the issue and have done, as far as I know, al kinds of tests to find a workaround. But they were, to my knowledge, not able to solve this. 

                             I hope this is helping in solving the problem.

                             Maarten van 't Hof.

                        • 9. Re: Memory Leak in SQL API
                          TSGal

                               Maarten van 't Hof:

                               Thank you for the information.  I have forwarded it to Development and Testing for further review.

                               TSGal
                               FileMaker, Inc.

                          • 10. Re: Memory Leak in SQL API
                            TSGal

                                 Maarten van 't Hof:

                                 Testing confirmed the leak occurs in FileMaker and not in Safari.  The data has been sent to Development for additional review.

                                 TSGal
                                 FileMaker, Inc.