forums.ps2dev.org

ragnarok2040 · Joined: 09 Aug 2006 Posts: 230

I ran across a bug that kind of worries me, but I haven't been able to reproduce it in a test case. I wrote some browsing code for a larger project, for browsing directories. It had been working, but, all of a sudden, I was unable to use strcat() to append a "/" to a folder with twin characters at the end, e.g. 123466, FOLDRR. I'm not sure if the problem lies in the strcpy() of fio_dirent_t member "name" copying an invalid character at the end or if it's actually strcat()'s fault. Replacing strcat() with sprintf() fixed the problem I was having, though, so it makes me think the strcpy() is fine. I appended the code of what exactly happens when browsing directories. This code works though, so I commented the parts that were giving me the trouble. I used the same optimization flags as well, thinking it might have been an optimization error.

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

ragnarok2040 · Joined: 09 Aug 2006 Posts: 230

It seems to be alright, someone was able to browse more than a thousand or so files on his usb drive with it like that without any problems. I'd originally had it defined as entries *FileEntry = (entries*)malloc(sizeof(entries)*2048); but changed it recently to that as a local variable since malloc wasn't having any trouble allocating the memory, but calling free(FileEntry) kept randomly crashing the program.

Two instances of the function is all that's called at any one time... maybe I should just define it globally so it doesn't take up more than a megabyte of memory... Thanks for the heads up :D.

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

The malloc is a much better idea. Just because malloc can allocate it doesn't mean there's enough room on the stack for the same sized object - you probably need to tell the linker or the C runtime startup that you need such a huge stack - I don't know what the default is on PS2SDK, but I bet it's more like 64Kb than 1Mb.
If your stack overflowed, it could easily cause the problem you are having.

Jim
_________________
http://www.dbfinteractive.com

ragnarok2040 · Joined: 09 Aug 2006 Posts: 230

Looks like the stack size for ps2sdk is 128 Kb. I am overflowing the stack so I changed my code back, heh.

What I don't understand is why would it only affects double character ending strings only. It doesn't affect directories with 32 characters in the name or browsing multiple levels up or down. Compiling with -fstack-check didn't cause it to exit the program either. But I think that only works on Linux... and if not, I don't think I was browsing enough entries to overflow the stack, heh. Maybe that guy was using an older version :/.

Oh yeah, the bug still happens whether I'm malloc'ing FileEntry or relying on the stack.

I checked the disassembly and I think I came across something strange...
The first one is from the program using strcat with the bug and the second with sprintf().

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

You can't tell anything from that.

You can easily check strcat. Right at the beginning of main() just do something like

ragnarok2040 · Joined: 09 Aug 2006 Posts: 230

I did post in my first post that I couldn't reproduce it outside of the program. That last copy & paste of assembly was from a program just like the one you posted, except I used a string length of 256. You're right that the assembly code didn't say anything, heh. I'm not sure exactly what else I can be doing with strcpy and strcat that would make it go wrong only on specific strings with double character non-numeral endings, anyway.

The exact behavior of the bug with "1234MM" being the string inside the array of directory names is:

path[4096];

(output from my program is intermixed)
strcpy(path,"mc0:/");
path = mc0:/
strcat(path,"1234MM");
path = mc0:/1234MM
strcat(path,"/");
path = mc0:/1234MM
strcat(path,"filename.fil");
path = mc0:/1234MM
.. selected
there is a /
there is no /
strcpy(path,"path");
path = path

Edit:
It disappears if I use word, doubleword or quadword alignments (pretty much anything 16 bytes and over), so I'm guessing strcat tries to strcpy the second string to the first string at the wrong byte for some reason, maybe the byte after the null terminator... since I think if the position were earlier it would cut into the first string's characters or maybe the strcpy there is incrementing a spot prior to copying the string for some reason.

Edit2:
I am able to reproduce the exact behavior I'm getting by setting the first character of the src string to a null terminator prior to using strcat to append it to the dest string.

Edit3:
Having the dest string aligned to 16 bytes caused my program to start producing random crashes every once in a while when entering those specific directories...