VC crashes in 'Start without debugging' mode

Started by
15 comments, last by tieuvodanh 15 years, 2 months ago
That's what I was thinking of doing from the beginning, but as I said, it works fine in the debugger. I'll examine the array sizes a little more.
Advertisement
There's a simple way to debug this:

- Put a message box or something at the start of main, to delay the bug (you only need this if the bug normally happens without user interaction).

- Run the program without debugging.

- Connect the debugger to the program (Attach in the Debug menu).

- Press ok on that message box and reproduce the bug.
Thanks, that was helpful.
It now tells me this line is giving me an exception:
material_t *material = malloc(sizeof(*material));

The only reason I can think of for such a line causing a crash is a lack of memory, am I right?
Lack of memory should make malloc() return NULL. A crash suggests that some of the bookkeeping information that gets stored before and after the memory you've allocated has been corrupted.

I'd start looking for problems between that call to malloc and the previous one, although it could be anywhere before that point. The first thing I'd look for is an uninitialized (or otherwise out of range) variable used for an array index.
Sorry, I completely forgot about the idea of attaching the debugger after it's running, though I myself use this all the time.

Yep, okay it sounds like memory corruption. It's possible that you're overrunning an array, but only due to a certain variable being uninitialised and hence having a value greater than zero at times, or something like that.

Incidentally, here's a shorter way of writing one of your functions:
template <typename T>vector<T> convertArrayToVector(const T *array, int size){    vector<T> newVec(size);    std::copy(array, array+size, newVec.begin());    return newVec;}
You'll find it's slightly faster too due to not having to grow during the push_back operations. I also added the missing 'const'.

Note that you'll probably get a speed increase out of it if your compiler performs NRVO too. That would mean you'd have it running much slower in a debug build. Consider returning the vector as an out parameter instead. Even better would be to have the original data in a vector to begin with, if possible [cool].
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
Oh that's great, thanks :) And yeah I should've put a const there..
Apparently the bug is in my obj loader (which I didn't write), and figured my time's better spent getting another loader..could've written one from scratch, but then there's that 'time better spent' issue again.

About NRVO, I'm using VC++ 2005, I believe it does perform that.
And about having the original data in a vector, I tried that, but reading from the vectors reduced my FPS quite a bit, which was kinda odd..

Again, thanks for the help :)
Hi,

I also got the same kind of problem: run well with F5 but not with Clt+F5.
Could you help me know how to : ?

-put a message box to delay the bug (Some lines of code as example is very appreciated)
- connect the debugger to the program (I change the Attach in Debug menu from No to Yes...but it seems there 's nothing special when I press Clt+F5 (start without debugging). Is it the right way ?


Thank you very much for your help!

I tried to follow the advice of Adam as in previous posts (below):

There's a simple way to debug this:

- Put a message box or something at the start of main, to delay the bug (you only need this if the bug normally happens without user interaction).

- Run the program without debugging.

- Connect the debugger to the program (Attach in the Debug menu).

- Press ok on that message box and reproduce the bug.

This topic is closed to new replies.

Advertisement