To stay on topic: I'm afraid there is no easy solution to find memory leaks in liteC. If you have problematic functions you don't understand, try to rewrite them from scratch to get a better understanding. This will improve your skills AND your code in most cases.

No and no. A8 will not fix faulty code or even damaged files which can lead to crashes too, how would it.

Memory leaks and other related crashes can be caused from of course not freeing allocated memory (i.e. you have to use sys_malloc or malloc in your code for that to happen) or overwriting stuff, for example
for(i = 0; i <= 10; i++) my_array[i] = i;
where
var my_array[10];
does not have a 10th entry. As a result you overwrite the 4 byte that follows the my_array array in your memory and all kind of weird stuff can and usually will happen.

The problem may lie somewhere completely else though too and that is a faulty file which happens more often than one would imagine. Over the years I've experienced that a few times already, and oftentimes I have to strip down my projects completely (make a backup first/ work with a backup copy) which can take a week or two. Preferably, you want to be able to delete as much as possible with the bug still intact so you can try and find its cause. Otherwise, if you only delete or change (as in your case) a little and the bug disappears it's likely you just have postponed the error to reappear at some random point in the future.
I've once had random crashes in a multiplayer skateboarding game with multiple levels, I've checked everything, my whole code over and over, stripped down the whole project only to find (with the help of jcl) that one texture in one of the levels was damaged. Then on loading erroneous stuff would happen and overwrite random areas which would lead to subsequent code crashes.

I have had my share of little memory mistakes too , and also particularly one that caused any change to function names or code to make the application seem to function or suddenly break .

my cause was a structure that was allocated and then freed while on the very next line I was attempting to use it however the pointer wasn't really set empty though .

secondly make sure that you always check any pointer you plan to use , like :

if (entity!=null)
{
its safe to use
printf ("good in function foo line 12");
}
else
{
its unsafe to use
printf ("bad in function foo line 134");
}

then also , never ever run SED in compatibility mode , I had applications run without a single problem from sed in compatibility modes , only to discover memmory issues on release or shared with others wich .

lastly just a mention of something that came up not so long ago, there is apparently a mention by jcl that certain entity data is still accessible as non empty pointers until they are flushed after a certain process , it was recommended to check entity type along with entity! =null to be really sure .

no matter how gamestudio try to make memmory handling easier , in the end lite-c is still an unmanaged language so you still have to be fully aware of using memmory /pointers etc correctly.

Checking for entity = null wont work because the engine doesnt null the pointer when it has been removed. Most annoying thing ever. Had to hook ent_remove and do it myself..

quoted myself:

" lastly just a mention of something that came up not so long ago, there is apparently a mention by jcl that
certain entity data is still accessible as non empty pointers until they are flushed after a certain process , it
was recommended to check entity type along with entity! =null to be really sure ."

^

Thanks for all the help. I will be looking into all these ideas.

One question: Are entities automatically released on a level change?

Memory which got allocated by the engine itself (let's say via WED entities or ent_created entities) does get freed automatically.

However, when you do more fancy stuff such as

my.skill90 = txt_create(...);
my.skill91 = allocate_pathfinding_data(...);

abd so on, you will need to release the memory manually, even on level change. Check out the on_ent_remove event.

For Superku:
How would you determine whether a texture is damaged? I assume that opening it in photoshop would work, but if there's a better(read faster) way, that would be great!

Sadly I'm not aware of any.
That's where the "create copy, strip down project" approach comes into play.

If you use skycubes, try removing them first.

I had a problem where one of my models would cause a crash. Removing the model solved the problem, but the model opened in MED just fine, and it did not cause a crash when running the game through WED. So could this be a symptom of another problem, like memory leak, or some other corrupted file?

Do the damaged textures work in WED? Or is what you're describing only a problem in the published version?