Weird crash

jpspe · Post by **jpspe** » Thu Apr 10, 2008 8:34 am

My codebase has now grown quite large and I am facing a weird crash. Let me describe the crash first. The screen is appearing instead of full screen it is appearing as a small screen, thats not all, its actually displaying two seperate identical small screens (this is not coming from my code), I guess its some sort of memory error or some other issue.

This 'crash' appears on the first displayed image on screen.

It actually does not depend on my code running but depends of a line of code, let me repeat this line of code doesn't even run!

So I have my c file Test.c and in it I have:

------includes section-------- with a bunch of includes

--------bunch of code---------

LineXYZ();

--------bunch of code---------

Now if the line "LineXYZ()" is commented the app runs normal. If I uncomment this line (which should not make a difference as this line is not executed), then the crash will occur. This function comes from a c object included from header Lines.h and I am currently not using any other function from Lines.h in this file. So, I think it has something to do with the code growing too much?

Also, the Lines.h file is included in a different file and does use some functions from the Lines.h code object without a problem. The problem arises when I uncomment the LineXYZ() line as specified above.

What kind of problem is this? What do I have to do? Perhaps break up the large c file Test.c?

Thanks for your time

Insert_witty_name · Post by **Insert_witty_name** » Thu Apr 10, 2008 8:43 am

I've only seen the 'dual screen' effect appear from three things:

1. Drawing outside of sceGuStart/sceGuFinish blocks.
2. Incorrect alignment.
3. Overflowing the display list.

I'd recommend checking for all the above, in that order.

jpspe · Post by **jpspe** » Thu Apr 10, 2008 8:47 am

I'm sure its not:
1. Drawing outside of sceGuStart/sceGuFinish blocks.

and

3. Overflowing the display list.

As the line of code that makes the difference is not executed...

So, its probably: 2. Incorrect alignment.

I'm not sure what alignment is and how to fix it ... any tips?

Thanks

Wally · Post by **Wally** » Thu Apr 10, 2008 1:23 pm

wait i had this with duke 3d (while porting to slim), make sure you don't have too much memory in your heap, it could just be that.

Wally

Insert_witty_name · Post by **Insert_witty_name** » Thu Apr 10, 2008 6:07 pm

Well, how is your display list declared, how are you allocating your vertices in each drawing function?

jpspe · Post by **jpspe** » Fri Apr 11, 2008 1:55 am

Insert_witty_name:

Well, how is your display list declared, how are you allocating your vertices in each drawing function?

The line of code (a call to another function) that makes the difference whether this crash happens or not is not even executed... so I don't think it has anything to do with this.

So the actual code that is executed stays exactly the same in both cases. Only in the case that is crashing I have a call to a function later on in the program, i.e. it has not been reached yet.

Wally4000:
If the code has not been run yet why should the heap make a difference?[/quote]

jpspe · Post by **jpspe** » Fri Apr 11, 2008 2:23 am

I removed all code in the LineXYZ function so that it appears as follows:

int LineXYZ()
{
return 0;
}

so my code is now as below:

--------------code----------------
-------wait for user input-------
LineXYZ();

Now, when LineXYZ(); is commented the code works fine.

When LineXYZ() is uncommented it crashes as specified above. It crashes however before it has reached the LineXYZ(), i.e. still waiting for user input...

Any thoughts?

Insert_witty_name · Post by **Insert_witty_name** » Fri Apr 11, 2008 2:29 am

Yeah, your smashing your stack somehow.

Instead of dismissing our ideas maybe try listening.

LineXYZ() is un-related to this.

jpspe · Post by **jpspe** » Fri Apr 11, 2008 2:43 am

Yes I can definitely see this to be an issue... sorry I didn't acknowledge this Wally4000. My application does store alot of images in memory for fast performance... looks like I'll have to cut down on the memory usage and perhaps create a caching system of some sort for the memory images in question.

Thanks

J.F. · Post by **J.F.** » Fri Apr 11, 2008 2:59 am

Remember if you're using the LoadImage() function from graphics.c, it allocates memory to the next power of two dimension. A 480x272 image actually allocates a 512x512 pixel block, not 480x272.

jimparis · Post by **jimparis** » Fri Apr 11, 2008 4:22 am

It's not memory usage. Listen to Insert_witty_name. It is an alignment issue or memory corruption.

J.F. · Post by **J.F.** » Fri Apr 11, 2008 5:20 am

Probably one of the most missed corruption issues is making strings in character arrays on the stack (a local array). The last three bugs I found for folks posting here were all buffer overflows from building text strings in char arrays on the stack. The last guy never even noticed since the string he was building to print was for debugging the very problem it was creating. :)

So go back through your program and double-check all your char arrays and strings. Then check any other arrays you use locally in functions. Odds are one of them is too small.