Basically the code crashes when it tries to store some data to a varialbe which is in stack. At least that is my hypothesis. All the data is fine, if I just loop through the list and print the numbers on screen everything is just fine. The call stack is no more than 4-5 functions deep.
My question is... how should I start debugging this thing? Is there some stuff which I can use to keep track of my stack & heap usage? Or any other educated guesses what might cause that even if the amount of information is very limited here?
And the crash... it just hangs and eventually psp shutsdown itself.
Yep, it returns correct results on my pc version and comparison operators have higher precedense (executed first) than logic ops. http://www.cppreference.com/operator_precedence.html
The place where the C operator precedense usually gets hairy when you need to mask and shift, since shift has higher precedence than bitwise and and or. Example:
int a = b & 0xff << 8;
vs.
int a = (b & 0xff) << 8;
Anyway... that should not cause the crash, though. Actually if I just comment out the contents of the if block it does not crash.
And any further use of the result from that function is not used at the moment. That is, the program returns back to main menu. And that works if I comment out the block of code that stores the result.
size_t i;
for(i = 0; i < m_edges.size(); i++)
um, because the first is the cleaner and accepted way to do loops in c++ when you don't need the loop variable later on? that part is perfectly fine.
with weird crash bugs like these, for me, it's usually some other part of the code with messy pointer handling or a buffer overrun or somesuch, screwing up the memory enough to have it crash in unexpected locations, your code looks fine.
The code is indeed C++ (I think that const reference would have been a good clue ;)). The Vec3 is a class and that code works well under VC7 and GCC. The same vector class is used in code which I can verify working.
I suspected bad pointers at first too. I have douple checked a lot of code to make sure that does not happen (cannot be 100% sure of course). I use STL containers alot so there should not be that much the normal pointer mishaps. Bad pointers usually make the stuff to crash when trying to read or write beyond valid range, but this thing just hangs which makes me think that it might be something else.
Still, I would like to first verify the heap and stack usage. Any pointers to that stuff?
Maybe you're accidentally declaring some brutally huge variables on the stack in the function tree that is calling this function? Maybe you passed in a too small value for stack size when you created the thread that's running this?
ector, Where do I define the stack size? I tried to look around but could not really found anything. My entrypoint of the code is pretty much based on the cube sample. I dont create any extra threads in my program.
The another thing is how do I keep track of my stack? Is there some variable or function I can use to get the current stack size?
Is the crash precisely where that comment is (Either during or just after the square root test block) or is it somewhere within that block? I'm assuming the latter at the moment.
Although I'm fairly sure I'm wrong about this, I have my eye on the int cast you're doing there. I've had troubles before when casting between types of different sizes (I'm not too sure how big a size_t is on the PSP, it may be 8 bytes or it might be 4), but in my experience that's only ever been when trying to cast pointers that aren't aligned properly, so it's a long shot at best.
Still, humor both me and you and try commenting out that line (And, one by one, the ones surrounding it) to see if you can get it to pass that section.
Finally, do you have any copy consructors or overloaded assignment operators for Vec3? If so, the problem might be occuring in there.
Thanks for the replies. After a bit a twiddling yesterday I got another crash. This time it was floating point exception. I think it is time to install that psplink :)
I think I will still try to check that stack usage too. The code crashed if I had any assignment inside the if.
Anyways, you get the idea. ;) On the PSP that'll pretty much always crash... you might want to put checks for NAN in intToFloat() to instead return 0 in those cases.... just a thought! :)
Its more complicated and a bigger pain in the ass to worry about your game objects having #INF or #NAN values than it is to just fix the algorithms that make them creep in in the first place.
I think I'll try to keep them enabled then. Any pointers to articles of good floating point practices? The new features in psplink sound promising too regarding my debugging needs... I think it's going to be interesting weekend then :)
If you prefer to do your debugging on PC, you can just enable floating point exceptions on the PC instead (they're disabled by default) and do your debugging there...