Arrays/Lists Crashing my program?

Started by
14 comments, last by Justice LeprechauN 17 years, 6 months ago
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.
Advertisement
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?
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. (?)
We're not psychic. Show the relevant code, please.
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?
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,

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?
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.
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.
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.

My Blog

This topic is closed to new replies.

Advertisement