Sign in to follow this  
Justice LeprechauN

Arrays/Lists Crashing my program?

Recommended Posts

First of all, I will not post any of the code that is crashing my program, because it's a lot (!) of code, and I can't single out where the crash occurs. What I'm doing is that I'm reading a Maya .obj file, and insert the data into lists/arrays. While doing this, the program crashes. When I was developing the function to read and store the data, I simple stored the data in arrays: float vX[100], vY[100], vZ[100], nX[100], nY[100], nZ[100], uvU[100], uvV[100]; short faceVerts[250][3], faceNormals[250][3], faceUV[250],[3]; With these arrays, the program worked without crashing. However, these arrays are way too small to be acceptable. They need to be quite huge, actually. Maybe 10-50 times as big. So, I tried increasing the size of them, but then my program crashed. I playaed around to see how big I could have them without the program crashing, and found that they can't be made much bigger at all without crashing the program. So, instead of using arrays, I changed to using pointers. short *faceVerts, *faceNormals, *faceUV; faceVerts = new short[500*3]; faceNormals = new short[500*3]; faceUV = new short[500*3]; Still, my program crashed. So, I changed the 500*3 to 5*3 in all the "new short". Program still crashes. Ok, since there's so much code, I'm aware that somewhere there might be a "dumb" use of the pointers, causing it to crash. But I've come across this problem before, while using big bi-dimensional arrays. So, can anyone help me? 1. Why does the program crash when using large arrays? 2. Why doesn't the "new" operator cure the problem? 3. Is there a different way to go about this, if I want to store large amout of data in variables? Thanks a lot! /Desperate for help.

Share this post


Link to post
Share on other sites
I don't see a problem with the way you are declaring your pointers and allocating with new, so I'd suggest it is not the declaration but the accessing of these arrays that is causing the crash.

Can you step through your program with a debugger and find out exactly where the crash occurs?

Share this post


Link to post
Share on other sites
Thanks for the reply.


No, the debugger is not helping. The code is valid, but the program crashes.

I've tried including <iostream.h>, and using a cout << "BLEH!", and putting that in different places, to see how far the program goes before it crashes.

I've gotten strange results with that. Sometimes, it crashes at the "{" in the beginning of the function (which is a class constructor).
But it's not consistant. It crashes at "about" the same place. (?)

Share this post


Link to post
Share on other sites
Oh, I'm sry... well, I think I might have found the problem. *embarrassed*

I had copy-pasted...

float vX[3], vY[3], vZ[3], // 3 points in 3D space, for vertice placement.
nX[3], nY[3], nZ[3], // 3 points in 3D space, for normals vector.
uvU[3], uvV[3]; // 3 U's and V's for texture placement.

...from a struct I have. Well, that struct is supposed to be declared as an array, and...

Well, to get to the point, I screwed up. array[3] is way too small. My code is attempting to fill it with way more than that, so it's an obvious crash.

However, the problem still exist. When I make my arrays larger, they crash the program.

However, it might be because I run out of system RAM, I'm not sure. It just sounds very unlikely, since I'm not using more RAM than it takes to hold the verts+normals+UV's of a simple 3D cube!


I just want to know if there's a difference between:

float my_array[500];

and...

float* my_array = new float[500];


is there a real difference to this, in the way the memory is handled/reserved? Or is memory being reserved in the exact same way in both cases?

Share this post


Link to post
Share on other sites
Quote:
Original post by Justice LeprechauN
I just want to know if there's a difference between:

float my_array[500];

and...

float* my_array = new float[500];

is there a real difference to this, in the way the memory is handled/reserved? Or is memory being reserved in the exact same way in both cases?


Yes, there is a huge difference.
void f()
{
// reserve data on the stack; automatically freed when it goes
// out of scope
int array[10000];

// allocate data on the heap. need to be delete[]ed
int *mem = new int[10000];

// allocate data on the heap; automatically freed when it goes
// out of scope
std::vector<int> ivect(10000);
}

The stack is typically limited to 1MB, while the heap is virtually unlimited (well, on most Windows versions, you might only gains access to 2 or 3GB). Reserving memory space on the stack increase the stack usage and might lead to a stack overflow. As a consequence, you should only declare small variables on the stack, and you should store larger memory blocks on the heap.

HTH,

Share this post


Link to post
Share on other sites
Quote:
Original post by Justice LeprechauN

Ah, interesting. That was very useful to me, thank you. :)

Just being curious; Is there a way to increase the maximum size of the stack?

...and I assume you mean 1MB is total max, and not just a max for each array?
Yes, total max. And if I were you I wouldn't worry about trying to change the stack size. The sort of allocations you're making should be made on the heap anyway; if the default stack size is insufficent for your program, it may be an indication that there's a problem with the design.

As for the crashes, it could be any number of things, but a good first step would be to switch to std::vector for your array management. Then, make sure you're catching exceptions and performing bounds checking where appropriate, which should go a long way towards catching the bug before your app crashes.

Share this post


Link to post
Share on other sites
Yeh, I did switch to std::vectors.

Right now, I have a different problem. For some strange reason, my program shuts itself off. No errors, no "sorry it crashed". It just shuts off.
I extracted the function and fixed it, but when I put it back into the project, it still does the same.

Suppose the problem has to be somewhere else then. I think I write code way too fast for my own best.

Share this post


Link to post
Share on other sites
You will have to learn using your debugger effeciently.
Start by placing breakpoints at code that looks suspecious and check the variables on each breackpoint, see if they are as you expect them to be.

Share this post


Link to post
Share on other sites
If your program just disappears, then it is either exiting normally through ExitProcess etc, or it is encountering a stack overflow.
For the former, just set breakpoints. For the later, if you use the debugger it will break at the point the stack overflow occurs and you can view the call stack to see your mistake.

Share this post


Link to post
Share on other sites
yeh, you're probably right: It's probably exiting because of stack overflow. Strange that it does say anything.

I'm using Dev-C++. Bad debugger? I know I dislike it, but then again, I've never used any other program. (Except "Quincy", but that doesn't count. (?))

I didn't know about stacks and heaps. I've learnt something here, and I'm grateful. :)


The problem about setting breaks and outputting the variable values, is that it's an openGL program, and I have no code for outputting text on the screen.
That's why I had to extract the file-reading routines, fix it using "cout", and then put it back.
Hard work.

Share this post


Link to post
Share on other sites
You don't need to output any text, just use the debugger.
Look for some tutorials how to use the one you are using.
If you are working on windows, I would suggest getting you the Visual Studio 2005 Express, it has a great Compiler, Debugger and Editor, usually makes programming more comfortable.

Share this post


Link to post
Share on other sites
I don't like the VC++ environment. I donät like that it doesn't "work" the same way. ("erase()" being "remove()", and so on.)
And I want to use minimalistic programs, because I'm a control freak. :P (ehm.)

I suppose I'll check on Dev-C++ debugger... thingy.

Thanks!

Share this post


Link to post
Share on other sites
Quote:
The problem about setting breaks and outputting the variable values, is that it's an openGL program, and I have no code for outputting text on the screen.
That's why I had to extract the file-reading routines, fix it using "cout", and then put it back.

Just because it's an OpenGL program doesn't prevent you from running with a console. The only difference between a console program and a Windows program is that the former starts with a console and the latter does not. It is perfectly possible to create windows from a console program and to allocate a console (at least under Windows) in a Windows program. I often switch my WinMain to a main and recompile as a console program so I can get console output when using a debugger is infeasible. Obviously it's much better if you can use a debugger instead though.

Σnigma

Share this post


Link to post
Share on other sites
Yeh, I know it's possible.

Earlier, I just put a "cout << 'bleh';" in the code, and a console window automatically plopped up and displayed it.

However, suddenly that stopped working. I tried "everything", but it just won't pop up again.

I assume[d] it's because of the way glaux handles windows, but I have no idea whatsoever.

I even tried using only gl.h (removed glaux.h and glut.h), but still no console window.

...am I cursed or what? :P

Anyways, it's probably related to the fact that my program shuts down. (Which I now know is due to stack overload.)

Haven't fixed it yet, though. Been busy.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this