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 > Memory leaks with DIR_ITER and fopen [SOLVED]

#176139 - SchmendrickSchmuck - Sat Apr 16, 2011 11:32 am

I'm using DIR_ITER to list all the files in a given folder. However, every time I do so, I noticed that it allocates a lot of memory, and I'm not getting it back. The piece of code below alone takes up 16128 bytes:

Code:

struct stat st;
DIR_ITER* dir;
dir = diropen(levelLocation);
buffer = (u8*)malloc(128);
while (dirnext(dir, (char*)buffer, &st) == 0)
{
}
dirclose(dir);



Changing the while loop to the following ups the memory usage to 114688(!!) bytes:

Code:

char levelName[50][35];
int lastfile = 0;

while (dirnext(dir, (char*)buffer, &st) == 0)
{
   if(tCounter++ > 1)
   {
      memset(levelName[lastfile], 0, sizeof(levelName[lastfile]));
      strcpy(levelName[lastfile], (char*)buffer);

      testRead = fopen (levelName[lastfile], "rb");

      fclose(testRead);

      lastfile++;
   }
}


Any thoughts?

Last edited by SchmendrickSchmuck on Sun Apr 17, 2011 4:25 pm; edited 1 time in total

#176141 - elhobbs - Sat Apr 16, 2011 4:15 pm

how are you determining how much memory is free?

#176142 - SchmendrickSchmuck - Sat Apr 16, 2011 4:54 pm

I don't check the free memory, but the memory in use:

Code:

struct mallinfo info = mallinfo();
iprintf("\x1b[22;0HMemory in use: %d bytes", info.uordblks);
iprintf("\x1b[23;0HTotal heap size: %d bytes", info.arena);


The values I gave earlier are based on the change in info.uordblks.

#176144 - Azenris - Sat Apr 16, 2011 10:07 pm

At the bottom of http://chishm.drunkencoders.com/libfat/ it shows a file listing demo. Not sure on your problem. Btw wheres the free for the malloc
_________________
<Robert Morley>
My Homebrew Games

#176145 - SchmendrickSchmuck - Sun Apr 17, 2011 4:24 pm

Thanks Azenris, I seemed to have overlooked the free command..

I looked some more into libfat, but it doesn't mention anything like this;
It appears that changing the buffer size to libfat's MAXPATHLEN, along with the free command fixed the problem. I had assumed the buffer could be any length as long as it could hold the file name, but that doesn't seem to be the case.

Thanks again!

#176513 - FluBBa - Tue Aug 09, 2011 5:46 pm

Somebody know where diropen, dirnext & dirclose is today?
readdir is so damn slow...
_________________
I probably suck, my not is a programmer.

#176519 - Rajveer - Wed Aug 10, 2011 10:25 am

Yeah I upgraded to the latest devkitARM (from 32 to 34, which includes a new libndsfat, 1.0.10) and can't find those functions anymore.

Last edited by Rajveer on Wed Aug 10, 2011 5:11 pm; edited 2 times in total

#176524 - wintermute - Wed Aug 10, 2011 2:41 pm

I got fed up with people reporting non-existent bugs in those (non standard) functions - they're gone. We should probably have gone with opendir & company right from the off.

readdir isn't slow you're probably just still using stat, sorry, there are a few more pending example changes.

Code:

      pdir=opendir("/");

      if (pdir){

         while ((pent=readdir(pdir))!=NULL) {
             if(strcmp(".", pent->d_name) == 0 || strcmp("..", pent->d_name) == 0)
                 continue;
             if(pent->d_type == DT_DIR)
                 iprintf("[%s]\n", pent->d_name);
             else
                 iprintf("%s\n", pent->d_name);
         }
         closedir(pdir);
      } else {
         iprintf ("opendir() failure; terminating\n");
      }

_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#176531 - FluBBa - Wed Aug 10, 2011 10:18 pm

Thanks a lot, I'll try that tomorrow.

Another quick question, is the card reading done by the ARM7, is there a read-a-head so that it reads data while the ARM9 is doing stuff?
_________________
I probably suck, my not is a programmer.

#176532 - Dwedit - Wed Aug 10, 2011 10:23 pm

The lack of asynchronous reads has been the most annoying thing about the disc_io part of libfat. Seems like all the code for the various cards wants to use 100% CPU usage polling loops instead putting it off for later with a timer interrupt.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#176533 - wintermute - Wed Aug 10, 2011 10:46 pm

card reading is only done by arm7 on the DSi, not sure we can implement async io in any sensible way tbh.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#176534 - FluBBa - Thu Aug 11, 2011 9:35 am

Seems like reading is a bit faster overall with the new devkitARM, thanks.
_________________
I probably suck, my not is a programmer.