gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Malloc sucks, leaks like hell if you do this

#154267 - Dwedit - Sun Apr 13, 2008 10:07 pm

So it appears that I can not:

Use malloc to allocate a bunch of memory to hold a directory listing
Init libfat
Open a file
Close a file
Use free to release the memory from the first malloc

I get a huge memory leak when I do this.
Where's an updated version of "gba_nds_fat" when you need it? At least that library never calls malloc.

Edit:
I'm just making this post because I finished tracking down a memory leak in my program. Malloc sucks because it only frees once everything has been freed, so you get memory leaks otherwise.
Libfat really shouldn't use malloc until this has been straightened out. Or at least, put in big warning messages in libfat:
"WARNING: this code uses malloc. Don't use malloc on your own until you've called fatinit, and you must free everything before you open a file! Otherwise you get memory leaks! Mwahahaha!"
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#154268 - Dwedit - Sun Apr 13, 2008 10:30 pm

Looks like libfat just leaks memory regardless of what you do, because malloc never frees anything unless everything allocated after it is freed.

I guess it's time to switch to gba_nds_fat until malloc's issues get resolved.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#154270 - simonjhall - Sun Apr 13, 2008 10:39 pm

Code example?

Not sure if it's related but I had similar things with Q1. On certain flash cards after fatinit() there was varying amounts of heap space left, which I found very strange... Uh...
_________________
Big thanks to everyone who donated for Quake2

#154271 - Cydrak - Sun Apr 13, 2008 11:27 pm

Yes, example please! If there's some crazy pathological case I want to know about it... but I haven't run into problems thus far. The only heap I'm aware of libfat using is for the partition and a small number of cache entries. Both seem confined to mount time, and should be freed on unmount.
(Ed: Of course I'm forgetting stdio and friends, eesh... :P)

Are you sure it's not just fragmentation, though..? malloc only has about 3MB non-virtual space to work with. And, since it can't exactly move the pointers it returns, the situation you describe (small long-lived allocation between large temporary ones) could cause problems. I had to account for this pulling textures in and out of VRAM, so I imagine it's just a caveat of these small systems...

If the DLDIs are somehow calling malloc then that is more worrisome... eep. o_o


Last edited by Cydrak on Mon Apr 14, 2008 12:20 am; edited 1 time in total

#154276 - Dwedit - Mon Apr 14, 2008 12:01 am

Okay, looks like I just have a memory leak in my code from not closing dir iterators... Apologies for any wild acquisitions.
I realized my mistake when I tried to make an example, and failed to get the leak.

But needing to free temporary buffers before opening a file really sucks. What if the file open returns NULL and I need the temporary buffers back? I just deallocated them!
Not only does memory get fragmented, it makes absolutely no attempt to use freed memory which is behind allocated memory, even if the memory block is the exact same size as before.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#154283 - Doom5 - Mon Apr 14, 2008 2:34 am

Dwedit: Are you still actively working on porting your GBA emulators over to DS, or has that work halted due whatever reasons?

I'm just curious, as Goomba color is excellent, and would be great in native DS mode.

#154286 - M3d10n - Mon Apr 14, 2008 2:56 am

Well, unless libfat leaks memory internally, the solution to avoid it messing your own allocations is to pre-allocate a large chunk of RAM (like 3MBs or so, depending on how large is your binary and how much RAM libfat and other libraries need to work) and have a memory allocator of your own allocate from that chunk instead. This is a good thing to do specially if you port your code to other platforms (like PC), so you don't stay at mercy of the default allocators and their shenanigans.

I have yet to do it myself, but I'm halfway there since I finally got to write an allocator to take care of VRAM banks for me (I can finally delete textures, heh).

#154289 - Dwedit - Mon Apr 14, 2008 3:02 am

Yes, I'm actively working on Goomba Color DS right now.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."