Hi all, I've built an executable that I've had working but someone at work went to use it and it crashed on them. I checked what they were using it for and it did the same for me (and on a previously good test case) so I'm not sure what's happening here. When it crashes and I go into debug, at first it was crashing on :
ostringstream.str("") on the 18th iteration. I thought maybe something was getting set and clear() didn't prevent it so I changed my variable to be declared inside the loop so it was destroyed/remade each iteration. That moved the crash to another function:
vector.clear() (also on the 18th iteration). I'm fairly new to C++ so I'm not sure where else to look at what's going on. The debug tree is showing the crash occuring in the dbg functions way down from my source. Any ideas?
I'll post some relevant snippets. It's pretty big and contains a lot of stuff that's not relevant (calling different programs to iterate between and building up arrays of gathered info from files).
vector<float> tube_maxr;
vector<float> tube_minr;
string filename;
ifstream infile;
ostringstream out;
int iteration_count;
float convergence;
float conv_tgt;
intfor (iteration_count = 0; fabs(convergence)>cong_tgt; iteration_count++)
{
tube_maxr.clear();
tube_minr.clear();
//Do a bunch of stuff
for (i=0; i<19; i++)
{
for (j=0; j < 3; j++)
{
/*Both of these have more complicated values but it's irrelevant*/
tube_maxr.push_back(i*1.0/j);
tube_minr.push_back(i*1.5/j);
}
}
out.str("");
out << i+1;
filename = "hole" + out.str() + ".txt";
infile.open(filename.c_str());
//Write some stuff to file
infile.close();
infile.clear();
}
At first, it was crashing at out.str("").
But when I changed that to have ostringstream out1 defined inside the i for loop it stopped crashing there and moved to the tube_maxr.clear(). This is all according to .NET 2003. I haven't figured out how to launch my app from debug with the breakpoints to really follow it and see what's going wrong. Visual C++ wants some dll's to do that that it can't find apparently. I just ran it to try and quote the error the debugger is telling me and here's what it quotes:
Debug Error!
Program:...myprog.exe
DAMAGE: before Normal block (#20107) AT 0X004c02ao.
(Press Retry to debug the application)
Then when I hit retry and go into .net it's saying User breakpoint (except I don't have one in there...I had tried yesterday but removed and recompiled). Ugh...what is going on? If I continue past whereever it thinks I'm breaking it it still crashes due to:
Unhandled exception at 0x7c910a19 in myprog.exe: 0xC0000005: Access violation reading location 0x3d864b70.
In the debug tree, it's showing the calling function as one of the vector.clear() calls and goes all the way down to ntdll.dll.
I would not expect out.str(""); to compile. I don't undertand what you mean when you say you put it in the loop.
If all you want to do is generate a numbered filename, and you're using the std::ostringstream to format the numbers for you, you need to declare it and use it in the loop.
So I'm not sure what else to post. That was the only instance of my using those vectors. I can't post the whole code (and wouldn't want anyone to see my poor style anyway). I changed it to declare inside the for loop its used in (similar to the ostringstream) and now it crashes on the vector declaration:
vector<double> tube_maxr;
Looking at the call stack:
The last function it calls before crashing is operator delete(...) and then _free_dbg
So it looks like for some reason it's having trouble just deleting this from memory. I have no idea where to go from here. Is there anything stupid I could do with the vectors that would make them crash the destructor function?
In a vector of floats? No. You must be doing something that's corrupting the heap. There's really not much we can do without seeing code. If you can compile for Linux, you could try running the program through Valgrind.
EDIT: See if you're doing stupid things, like deleting things twice, or writing past the end of arrays.
I've managed to get rid of that crash by looking for anything that could possibly be going outside of its range. But I've just moved the crash to a push_back on another iteration. I tried to post the code in its entirety but there's not enough space possible. What do people usually do for that?
That time it looks like it was just a really stupid mistake. I think I managed to fix it. Thanks a lot for your help on tracking it down. I appreciate it.