I did not find the proper way to upload source and test data on the github site, so I am doing that here.

The test case is in the first file I will try to attach:  Away3D_21.as.

The version of MemoryTracker will be in the second file attachment.

Unfortunately our forum does not properly handle attachment with “uncommon” file name suffixes. Please create a zip file with the two files in it.

I hope it will accept this archive.

Evidently not.

Hi all,

Got a similar issue when I create and destroy scene

I fixed some memory leak in my code, that’s ok but I have a memory leak when dealing with 3D. ( I’m using the same process to dispose than you and null all possible data ).

I don’t understand AwayStats Memory information vs Windows Task Manager. On AwayStats RAM usage looks good after scene destroy / recreate, I can see on the ram graph the GC working very well but on Windows Task Manager memory continue to increase until everything crash.

Look like Flash is fine but the hardware keep data ... strange ...

Any idea ?

regards,

Jeff

From what I have been able to apprehend about the issue, addChild/removeChild, whether applied to some ObjectContainer3D that you might be trying to use to manage content, or applied directly to the scene [which, in fact is just another descendant of ObjectContainer3D], can leave your application open to a problem with memory leak.  I recommend you follow/track the issue on GitHub where you will see that a subsequent issue has been opened that is very likely another aspect of the same problem.  So, it’s good to see that Dave will be working on both of them.

The only other thing I can offer is that in order to trouble shoot the problem I created a LocalMemoryTracker class following the good suggestions on the web.  It has helped me isolate this type of problem.  If you would like a copy just take this offline by sending me an email.

I’ve suggested this before and it has worked for some. Weak referencing in the listeners can really help clean up memory issues. Here’s a good article on it:

http://gskinner.com/blog/archives/2006/07/as3_weakly_refe.html

Thanks for the link, changed all my event listener to use weak ref, better result

I find out my problem ... mainly in my code ... Well, It was the opportunity to study and learn about GC.

Find this wonderfull profiler that’s help me a lot to track

http://jpauclair.net/flashpreloadprofiler/

This post was helpfull too ( to solve error message on MaterialLibrary )

http://away3d.com/forum/viewthread/504/

Cheers,

Jeff

cool, glad it helped some. So that flash preload profiler gives good info on Away3D code? Could you explain a bit more how you used it? Looks like a good tool

I checked for a fact that ideally : ( SO = sigma objects )

( SO_maincode ) + ( SOcreated - SOdeleted ) = SO_maincode

and so SOcreated - SOdeleted = 0

I took a snapshot of my objects in _maincode before any creation and then compare after a create / delete, the difference is the leak. The profiler list all objects in real time, which is perfect for a snapshot.

The difficulty is to track down where objects came from, here a trace or console is really helpful. ( In my case I have a console that display messages by class ).

I had some objects not disposed and eventlisteners, I forgot to delete some references to them. My system works since some hours now, with different scene creation / destruction involving all kinds of data and memory is under control .

I used end september build, I had a very good memory print. I just update to latest build, memory explode !

Something has change in October that have a very bad impact on memory management ....

EDIT :

Here’s a way to do not use any texture ( so no cache ) using Max3DSParser ( I do not want any texture just my meshes )

protected override function proceedParsing():Boolean {
...
case 0xAFFF: // MATERIAL
  _cur_mat_end = end;
  //_cur_mat = parseMaterial();
break;
...

private function constructObject(obj : ObjectVO, pivot : Vector3D = null) : ObjectContainer3D {
...
//if (obj.materials.length>0) {
//  var mname : String;
//  mname = obj.materials[0];
//  mat = _materials[mname].material;
//  }
...

Memory print is now back to normal in my application ,

Seems a news user-controlled memory management is under construction
https://github.com/away3d/away3d-core-fp11/issues/157

Cheers

I solved most of memory leaks by not using the actual AssetLibrary.

The good news is the engine is well done regarding memory management, but there is a leak on ShaderRegisterElement & String objects

my application run perfectly since hours ( with full scene deletion / creation every 20s ).

Thanks Richard Olsson for the latest Max3DSParser.as, I extract it and use it independently to handle my meshes.

Performing diffs to read all the changes between Master and Dev after the December 27 commits, there was little done to attempt to address the many problems that I documented in October—memory leak problems that are ultimately at the heart of at least half a dozen key Issues that were posted before mine and have been posted subsequently.

The hundreds of lines of code change to the score of classes otherwise known as the ‘texture refactor’ constitute some nice enhancements going forward, and did include the elimination of the concept of ‘deep disposal’.  Until, however, there is a clear set of documentation concerning which dispose methods must be called in which order, in order to be guaranteed that the framework will not retain references that will prevent Garbage Collection, the memory leaks will remain.

For the twenty-some-odd folks who downloaded the previous test harness code that I developed to hone in on the memory leak problems as best as I can, I am attaching the version updated for regression testing against the Dev branch.  It relies on the nicely upgraded profiling facility now renamed TheMiner, which JP Auclair still graciously makes available at no charge for working on these complex issues.