4 Replies Latest reply on Aug 4, 2008 12:55 AM by TJW-dev

    Large list memory problem

    TJW-dev
      Hi,

      I am using MX2004 (10.1), I am finding that when I am working with large lists, there seems to be a memory leak when the memory should be returned when the list is finished with. Projector is being run on Windows XP.

      This only seems to happen in a projector, it does not happen in authoring.
      Please see the attached code for a test sample I made.
      My actual application creates a list of property lists that is about 1500 evements x 10 properties, but the attached example has the same effect.

      The sample basically repopulates an array with 30000 text elements, every 5 seconds.

      If you make this into a projector, you will see (if the problem is not limited to the 5 machines I am using) that every 5 seconds, the memory in use will increment, and never go down, despite the fact that the list is VOID at the end of each calculation.

      Has anybody got any explanation for this, a work around or can at least replicate this so I know I am not going mad.
      I have tested creating the projector on several machines in our office, andon several flavours of windows XP - all with the same result.

      Thanks for any ideas.

        • 1. Re: Large list memory problem
          Level 7
          Tested, and I can verify that you've found a bug. And it's probably worst
          than it seems.

          First of all, it has nothing to do with using globals. You can replicate the
          leak by publishing a movie containing the following frame script:
          on beginsprite me
          the debugplaybackenabled=true
          repeat while not the shiftdown
          nArray = []
          repeat with i=1 to 30000
          nArray.add( "text " &i )
          end repeat
          put the milliseconds
          end repeat
          end

          Second, it's not a list issue - not releasing elements on clearup.
          I tried appending lists instead of strings : nArray.add( [] ) : and the
          issue remained.
          Then I tried using xtrema's strings, _a("myString"&i), and other
          non-director native values, and everything was ok - no leaks.
          And finally, I tried using xLists, containing director strings. And the leak
          occurred again.

          Based on the above, I'd say that the leak is caused by director's failure to
          release the allocated memory of native values that require allocated buffers
          for storing their data.
          And now to the 'probably worst' part.
          When adding 'just' 20000 instead of 30000 strings, there was no leak. So, I
          guessed that the problem occurred when a large, yet fixed, number of
          allocations was involved. But then I tried using a larger string
          ("textAAAAAAAAAA"&"i), and there was the leak again.
          So, the leak depends not only to the number of unique allocations, but to
          the size of the allocated buffers as well.

          Seems that the issue is fixed on Dir11. However, this bug, along with the,
          also fixed in 11, legacy memory allocating issue (a pre v11 director windows
          projector allocates aprox 10% of the physical ram!!) is something that I
          strongly believe justify a dir 10.x update. I bet it won't happen, but, in
          my book, bug fixes=update, new features=upgrade/new version.


          "TJW-dev" <webforumsuser@macromedia.com> wrote in message
          news:g6v2l9$o0c$1@forums.macromedia.com...
          > Hi,
          >
          > I am using MX2004 (10.1), I am finding that when I am working with large
          > lists, there seems to be a memory leak when the memory should be returned
          > when
          > the list is finished with. Projector is being run on Windows XP.
          >
          > This only seems to happen in a projector, it does not happen in authoring.
          > Please see the attached code for a test sample I made.
          > My actual application creates a list of property lists that is about 1500
          > evements x 10 properties, but the attached example has the same effect.
          >
          > The sample basically repopulates an array with 30000 text elements, every
          > 5
          > seconds.
          >
          > If you make this into a projector, you will see (if the problem is not
          > limited
          > to the 5 machines I am using) that every 5 seconds, the memory in use will
          > increment, and never go down, despite the fact that the list is VOID at
          > the end
          > of each calculation.
          >
          > Has anybody got any explanation for this, a work around or can at least
          > replicate this so I know I am not going mad.
          > I have tested creating the projector on several machines in our office,
          > andon
          > several flavours of windows XP - all with the same result.
          >
          > Thanks for any ideas.
          >
          >
          >
          > global nArray
          >
          > on prepareMovie
          > nArray = []
          > updateTimer = timeout("restartTimer").new(5000, #popArray)
          >
          > end prepareMovie
          >
          > on popArray
          > nArray = []
          > repeat with i=1 to 30000
          > nArray.add("Text " & i)
          > end repeat
          > nArray = VOID
          > end popArray
          >


          • 2. Re: Large list memory problem
            pete.h
            I agree about the need for a 10.2 update. Upgrading to D11 is not always an option, given that legacy xtras may not be D11 compatible.
            • 3. Re: Large list memory problem
              Level 7
              Especially for the two bugs mentioned in the previous post, and given the
              fact that the solution is already known and projector-only related, we are
              talking about a very small -both in size and coding time required- update.
              If releasing such an update was decided, it would probably be a matter of
              couple of hours for the dev team to fix. Unfortunately, seems it would
              require many -and probably loud- voices for such a request to be heard.

              "pete.h" <webforumsuser@macromedia.com> wrote in message
              news:g70e23$9as$1@forums.macromedia.com...
              >I agree about the need for a 10.2 update. Upgrading to D11 is not always an
              >option, given that legacy xtras may not be D11 compatible.


              • 4. Re: Large list memory problem
                TJW-dev Level 1
                Thanks guys for confirming my suspicions. This is a very bad thing it seems. I also find it strange that I can't find any existing documentation of the problem.

                An upgrade to director 11 might be possible in my case, most of the xtras I use have D11 compatible versions, or suitable alternatives available. But it is a shame that they almost won't certainly won't patch a bug thatmay cause some developers a real issue.