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 > "dirnext" corrupts stack!

#161417 - Dwedit - Sun Aug 03, 2008 3:34 am

When I call "dirnext" using the FCSR dldi driver, memory on the stack gets corrupted, and a block of data gets written to address 0.

More specifically:
Code:

int find_next_file(char filename[])
{
   if (dir_global==NULL)
   {
      return find_first_file(filename);
   }
   struct stat st;
   int type;

   int err=dirnext(dir_global,filename,&st);

   if (err==-1)
   {
      free_dir_iterator();
      return 0;
   }
   else
   {
      type = (st.st_mode & S_IFDIR) ? 2 : 1;
   }
   return type;
}

If I allocate a big dummy array on the stack before calling dirnext, I get no bad effects. If I don't, I get a corrupted stack.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Last edited by Dwedit on Sun Aug 03, 2008 8:54 pm; edited 1 time in total

#161441 - Dwedit - Sun Aug 03, 2008 8:17 pm

I think I have more insight here...

"Sizeof (stat)" is 64, but more than 64 bytes get overwritten when you call dirnext.

So far, I've seen the 4 bytes AFTER the 64 byte struct getting zeroed out. This is a major bug.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#161469 - preussie - Mon Aug 04, 2008 5:11 pm

I can confirm the problem ( r23b ). I had the same here. After I inserted some dummy bytes after the stat struct it worked...
_________________
My NDS Homebrew projects...

#161470 - cheesethulhu - Mon Aug 04, 2008 5:55 pm

The latest NDS binary of libfat, libfat-nds-20070127, was built with 32-bit dev_t, but devkitARM r23b (and maybe other releases) has 16-bit dev_t. Two members of struct stat are of type dev_t, so four bytes after get zeroed and data within the struct is at the wrong location.

A couple quick workarounds include rebuilding libfat from source, downgrading to an old devkitARM, or using a custom struct stat. A real fix will probably involve a new release of devkitARM, since libfat uses st_dev for a 4 byte device ID, and is therefore "correct".

#161502 - CmdrKrool - Tue Aug 05, 2008 7:01 am

I ran into this as well today. It's a happy coincidence that you folks are here discussing this just now otherwise I might still be pulling my hair out.

I'm also seeing (ie. just from practical tests and printf) 4 bytes getting zeroed after the stat struct.

#165695 - ritz - Sun Jan 04, 2009 3:43 am

I updated to devkitARM 24 recently and have discovered this exact same behaviour when calling dirnext() within EFS lib's SearchDirectory(). I've tried the precompiled libfat and compiled my own from source (1.0.3 and 1.0.4)... no luck. This worked fine for me in 23b. Anything else I can do or try?

#165710 - elhobbs - Sun Jan 04, 2009 11:58 pm

I ran into the same problem. I had to change to opendir and readdir - which is used in the libfat example code.

#165727 - ritz - Mon Jan 05, 2009 4:34 pm

Cool, thanks for the helpful info.