fread weirdness with larger files

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
PeterM
Posts: 125
Joined: Sat Dec 31, 2005 7:25 pm
Location: Edinburgh, UK
Contact:

fread weirdness with larger files

Post by PeterM »

Hello,

I'm attempting to port a game to PSP, and for some reason, the fread function has problems with large files. With a file on the memory stick which is around 2MB in size, the following call:

FILE* file = fopen("./myfile.dat", "rb");
int read = fread(buffer, 1, 65536, file);

returns 16384 instead of 65536. Subsequent calls return 0. Has anyone seen this problem before?

I'm not sure where to look for the source for fread, apologies if I'm doing something stupid...

Peter
PeterM
Posts: 125
Joined: Sat Dec 31, 2005 7:25 pm
Location: Edinburgh, UK
Contact:

Post by PeterM »

This may actually be a memory card corruption problem for me only - copying files onto the PSP via USB in a different order moves the problem to a different file.

On some files the PSP locks up completely.
CyberBill
Posts: 86
Joined: Tue Jul 26, 2005 3:53 pm
Location: Redmond, WA

Post by CyberBill »

Have the PSP do a format on the memory stick and give it another go

I have had VERY strange problems with a memory stick that have been solved this way, due to corruption.
PeterM
Posts: 125
Joined: Sat Dec 31, 2005 7:25 pm
Location: Edinburgh, UK
Contact:

Post by PeterM »

Thanks for the tip. I tried it out earlier (backing up my game saves, formatting the card, then restoring the saves) and it seems to have helped.

I still get the occasional problem though - e.g. files refusing to delete from the memory stick - I think my memory stick is knackered...

Thanks again for the advice.
CyberBill
Posts: 86
Joined: Tue Jul 26, 2005 3:53 pm
Location: Redmond, WA

Post by CyberBill »

The PSP is really... strange... in the way it handles file IO.

For instance, when doing any disk IO you can pass in a 'repeat' factor that says how many times to retry something, because it doesnt always work.

So, I say you call it until it does what you want. But thats just me :)
av
Posts: 7
Joined: Sun Jan 01, 2006 11:15 am

Post by av »

I just spent 4 hours working through other file read related hang problems. You may want to try changing your Makefile to compile with -O1 instead of -O2. -O1 will do less optimization. However, -O2 seems to cause my app to hang the PSP if I change a line of code from time to time (I think gcc's optimizations are a little busted on the PSP). With -O1 everything seems to work as expected.
mrbrown
Site Admin
Posts: 1537
Joined: Sat Jan 17, 2004 11:24 am

Post by mrbrown »

av wrote:I just spent 4 hours working through other file read related hang problems. You may want to try changing your Makefile to compile with -O1 instead of -O2. -O1 will do less optimization. However, -O2 seems to cause my app to hang the PSP if I change a line of code from time to time (I think gcc's optimizations are a little busted on the PSP). With -O1 everything seems to work as expected.
Careful there - we don't see reports of anything breaking at -O2. Can you submit a valid repro for the hang?

A lot of time folks want to blame the compiler when they see weirdness caused by other bugs in their software.
av
Posts: 7
Joined: Sun Jan 01, 2006 11:15 am

Post by av »

mrbrown wrote:A lot of time folks want to blame the compiler when they see weirdness caused by other bugs in their software.
Unfortunately, while I can definitely repro it 100% of the time, it's in a code base that belongs to my company...and it's a pretty large code base with a full game level worth of data. So submitting a repro isn't possible.

The code has run fine for months in Windows for D3D. I've run BoundsChecker on it many, many times and while BoundsChecker isn't perfect, I've had no problems in the Windows build. The PSP build with -O1 runs without problems like the Windows build...the -O2 build hangs whenever I make completely safe changes like the following:

If I compile a for loop with a variable like:
for (int32 i=0; i<numLoops; i++)

That works fine. But when I change it to a constant:
for (int32 i=0; i<2; i++)

This hangs on the PSP right after the PSP loading screen fades away. Recompiling with -O1 causes it to work perfectly. Definitely looks like a compiler bug to me. This won't happen with all for loops, just certain ones that cause the compiler to crap the bed.

Thanks.
User avatar
Jim
Posts: 476
Joined: Sat Jul 02, 2005 10:06 pm
Location: Sydney
Contact:

Post by Jim »

Looks more like a stack overflow/corruption.
Jim
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

av wrote:it's a pretty large code base with a full game level worth of data. So submitting a repro isn't possible.
If you can't give us a way to reproduce this "compiler bug", I'm afraid you're going to have no luck convincing any of us that it exists.
User avatar
groepaz
Posts: 305
Joined: Thu Sep 01, 2005 7:44 am
Contact:

Post by groepaz »

the fact that it works on windows isnt really proof either, windows can be very forgiving when it comes to broken code (how else would it even boot? :=D)
Post Reply