Fixups of memory leaks, double frees, etc

[hlkline]

Several class objects are now explicitly deleted at the end of SU2_CFD, which provides a check that their deconstructors are properly implemented.
Some memory leaks may still exist, and future work will be needed for postprocessing routines implemented, but not currently called, in driver->Postprocessing.

For future development reference some common problems:

• pointer not initialized to NULL, causing a segfault when delete [] is called in the deconstructor. (When set to NULL an if statement avoids this segfault).
• pointers owned by a parent class deleted in the child class. An exception could be when only the child class has information about the size of pointers to pointers, but otherwise risks double-frees (a segfault) and creates duplicated code.
• FYI, although it does not seem to cause any error, Classname.~Classname() does not have defined behavior, and will do nothing.

[talbring]

Thanks Heather for dealing with this. This is especially helpful to find future memory leaks for example with valgrind.

[economon]

Agreed. This looks great, and thank you for the improvements (I know they were hard-earned). Merging in now...

Things are really starting to look better on the memory front. Keep up the good work!

[hlkline]

Thanks for your comments!
Have a good weekend

[aeroamit]

Hi,
I tried the latest developer version for a large problem of 31 million cells. With SST model, initialization of jacobian is continuing for a long time (I terminated job in between).
This is not the issue with latest stable release and it goes fine.
Actually I was curious to see if memory usage cones down in the latest developer version.

Thanks and Regards

---

From: Thomas D. Economon [email protected]
Sent: Saturday, April 16, 2016 4:28:49 AM
To: su2code/SU2
Subject: Re: [su2code/SU2] Fixups of memory leaks, double frees, etc (#265)

Agreed. This looks great, and thank you for the improvements (I know they were hard-earned). Merging in now...

Things are really starting to look better on the memory front. Keep up the good work!

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com//pull/265#issuecomment-210675678

[hlkline]

Thanks for your post, it is good to know about this as our regression tests use relatively small sized problems.
I have looked through some of the past regression test history, the regression tests took a bit more time after adding additional tests, but other than that have been fairly consistent - up or down by a minute or two, which seems to be well within the usual variance. Although the most recent release wasn't that long ago, there have been several changes to the develop branch, so if you continue to see these problems please feel free to open an issue.