views:

140

answers:

4

Hello! I'm having prblems with my C++/openGL program.

at some point of code, like these(it's a constructor):

MyObject(MyMesh * m, MyTexture* t, float *c=NULL, float *sr=NULL, int sh=100){
texture=t;
mesh=m;
subObjects=NULL;
texCoords=NULL;
if (texture!=NULL){
  texCoords=new float[mesh->numSurfacePoints*2];

the new throws an std::bad_alloc exception. it's the same at another place. is it possible, that i ran out of memory? i dont think so, so if you could help me, i would be glad! bye!

A: 

Are you calling delete[] on texCoords at some point? It certainly seems like you're running out of memory.

Aaron
no, i don't, because i use them until the program exits.
Adam Loska
+2  A: 

You should also check the value of mesh->numSurfacePoints maybe it's bogus or negative, that could be the source of the error, too.

Steffen
it' okay. to specify the problem: I have a MyMesh class, that can tessellate N sided cones and pyramids. it can also generate hollow cones, in that case, theres a hole through the cone. if i generate a hollow cone, it's okay, even if i use 20 sided cones, but is i generate a not hollow one, it generates the MyMesh, but when I pass it to the MyObject constructor, it throws the error.
Adam Loska
+2  A: 

is it possible, that i ran out of memory?

How much memory is your program using when std::bad_alloc is thrown?

What is the value of mesh->numSurfacePoints when it crashes? Are you absolutely sure that the pointer passed in as mesh is a valid pointer? If you have a very fragmented address space, there might not be enough contiguous space to allocate a large array. How long does your program run before std::bad_alloc is thrown?

If you aren't already, you should consider using boost::scoped_array or some other form of smart pointer for arrays so that deletion occurs automatically when heap-allocated objects are no longer needed.

James McNellis
unfortunately, this program has to run on a server at my university, so i can't use smart pointers.thu numSurfacePoints is 36, but it ran fine with greater numbers(see my comment on Steffen's reply). how can i check hjow much memory the program uses, when it crashes?
Adam Loska
That depends on the operating system. However, it's likely that your memory usage is limited by a quota on this university server, which could be causing you to run out of memory _much_ faster than you typically would if you had the benefit of the full address space.
James McNellis
+1  A: 

Actually, with modern operating systems it's rather unlikely you ran out of memory. Before you do that, the machine will swap so heavily, that it becomes more or less unusable - you cannot miss that. Also, when I conducted experiments with Win2k a few years ago, I found that just about every application crashed when my test app allocated as much memory as it could get. (That included the debugger, office applications, the browser, the email app, and even notepad.)

So I would assume you're either trying to allocate an unreasonably large amount or the heap becomes fragmented so badly that it isn't able to serve even reasonable requests.

How about writing your code this way:

// for example
const std::size_t arbitrary_max_size_constant = std::vector<float>::max_size();
// or std::nummeric_traits<std::size_T>.max() / 10; 

if (texture!=NULL){
  assert(mesh->numSurfacePoints < arbitrary_max_size_constant);
  texCoords = new float[mesh->numSurfacePoints*2];
  // ...
}

This will alert you in debug modus if your program has a bug, but won't slow down release code. Another possibility would be that you catch the exception and print the memory the program was trying to allocate:

if (texture!=NULL) {
  try {
    texCoords = new float[mesh->numSurfacePoints*2];
  } catch(const std::bad_alloc& x) {
    std::cerr << "failed to allocate << mesh->numSurfacePoints*2 << " bytes!\n";
    throw;
  }
  // ...
}

This way you'll also see whether the value is unreasonably big. If it is, you've got a bug, if it isn't, you either run out of memory or the heap is too fragmented to allocate the amount the program needs at this place.

sbi
thanks, but it seems okay. only trying to allocate 36 floats, so it shouldn't be a problem. if no other guesses, then I will start debugging from the very begining... duh... wish me luck:)
Adam Loska
How did you find out about that 35?
sbi