#152423 - Rajveer - Sat Mar 15, 2008 7:41 pm
If libfat isn't interrupt safe, does this mean I should disable ALL interrupts before reading/writing files, even IRQ_VBLANK? The threads already talking about libfat and interrupts talk about doing file reading/writing during a function called by an interrupt, however I'm reading in my main function.
Last edited by Rajveer on Sat Mar 15, 2008 8:26 pm; edited 1 time in total
#152424 - Dwedit - Sat Mar 15, 2008 7:57 pm
I had asked Chishm about that ealier, he said it was okay to have the IO functions interrupted. Just as long as you don't try to do more than one IO operation at the same time.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#152430 - Rajveer - Sat Mar 15, 2008 8:29 pm
Just in case I wrapped my functions with irqDisable/Enables but still doesn't do anything, so I renamed the thread.
I'm getting some really weird behaviour in my code, like having more printfs freezes my level loading and stuff. At the moment, I wrapped my main loop in an if statement so I could check whats going on frame by frame by pressing R, then I modified some collision code till it was right. Now getting rid of the if statement causes my level not to load properly again and keeping it there works fine...!
I then commented out the if statement and the function I think was causing problems, but before the program crashed it printed a statement from that function as if it was called anyways. Maybe a memory error?
#152468 - Rajveer - Sun Mar 16, 2008 2:12 pm
This is really weird. When I comment out the if statement, around half way through building the octree for my level and I get a malloc/calloc fail. If I leave the statement, everything gets allocated fine. Same if I disable the octree code, the level models get screwed up unless I leave it there. I'm really at a loss here, I have NO idea where the problem is, how would I go about debugging a problem like this?
#152483 - wintermute - Sun Mar 16, 2008 5:23 pm
It's almost impossible to offer much help without seeing some code. It might help a bit if you did some sanity checking on the sizes you're trying to malloc, perhaps using some asserts.
Since devkitARM is built without thread support you need to be quite careful about the things you do in an interrupt context - nothing in stdio should be considered interrupt safe.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#152505 - Rajveer - Sun Mar 16, 2008 10:21 pm
I appreciate that not much help can be given without some code, it's not much help me saying its a random problem and I need some help! Atm though my source is over 7000 lines and the problem could be within a few different areas so it would probably make more sense to send, and go though my code, with somebody willing to debug it with me.
Also, to whoever that person may be, you'll get a look at the early stages of my project! And some chocolate-chip cookies.
#152583 - silent_code - Mon Mar 17, 2008 11:45 pm
just in case: have you tried a full recompile?
it's really weird, but as usual, it'll be some typo size (complexity) error that causes this strange behaviour. i sometimes have them, too, like anyone.
good luck!
#152592 - elhobbs - Tue Mar 18, 2008 1:22 am
I have been having a similiar problem. I seam to particularly have problems when I print floats using sprintf. it usually end ups with a stack overflow and lr usually points at localeconv. it took me a while to figure out as I was using sprintf to format floats in my debugging messages that I was printing to the console. the more prints I put in the worse the problem got. I removed the calls to sprintf and I stopped having problems.
#152673 - HyperHacker - Wed Mar 19, 2008 6:20 am
You can use siprintf() to avoid bringing in the big float library if you're not using floats. Either way *printf() shouldn't be breaking anything. However if you have memory corruption (writing past the end of a buffer even one byte, re-using a pointer after freeing/realloc()ing it, etc) you'll get all sorts of weird effects, and things like printf() and especially the file I/O routines will break seemingly at random.
_________________
I'm a PSP hacker now, but I still <3 DS.
#152683 - elhobbs - Wed Mar 19, 2008 2:29 pm
I do not think that it malloc/free/realloc issue as I only make one call to malloc and no calls to free or realloc. I am not having any problems with file i/o. I only have problems with sprintf when I print floats. I even moved the buffer to a global and made it absurdly large (256 bytes) for printing a single formated float. I still get random stack overflows. I am calling this from a recursive function but tracking the lowest sp goes shows that I am not coming close to using the stack up myself. however when it crashes sp is usually something like 0x0afffffe. there are other threads pointing problems with floats and *printf so I just wanted to point this out as a possible cause of problems
#152741 - HyperHacker - Thu Mar 20, 2008 9:05 am
Possibly an interrupt problem? Does it crash if you use sprintf() while interrupts are disabled?
_________________
I'm a PSP hacker now, but I still <3 DS.