Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
I have a big project, compiles fine, but sometimes when I run in terminal(sometimes not)
./run
it gives bad_alloc exception, so i think it might be helpful to backtrace using gdb, so I do
gdb ./run
run
and it weirdly exit normally, nothing wrong shows up, even though I tried a lot of times.
Has someone met similar issues before?
See this answer for what may be different "inside" vs. "outside" of GDB, and what to do about it.
If you can enable core dumps (ulimit -c unlimited), that should give you another way to get the stack trace.
In my experience, most bad_allocs result from one of two root causes:
Uninitialized size:
int size;
if (something) {
// assign to size here
}
std::vector v(size); // Oops: size may be unintialized.
Arithmetic underflow:
std::vector v(other_vector.size() - 20);
Here, if other_vector.size() < 20, you'll get humongous value.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 months ago.
Improve this question
Let's say I have an object MyObject and it has an attribute double MyObject::a. When I initialize a I set it to 0.05, but at some point when I run my code I notice that a is 1.something e-316, even though my code is never supposed to change its value. If I knew an exact place in memory that a occupies, is there a tool that will tell me when exactly this place is overwritten?
As others have already noted, you could use a debugger for this. Most reasonably recent debuggers have some capability to break when a value is written to a particular variable (e.g., Visual Studio calls this a "watchpoint" or "data breakpoint" (depending on what age of IDE you're looking at), if memory serves.
Depending on the situation, you might be able to get some useful information by changing your double to a const double:
const double value { 0.05 };
Then any code that tries to assign a new value to this variable simply won't compile.
If, however, the problem arises from some code doing an out of bounds write, rather than assigning to the value that's getting overwritten, this won't help find that.
gdb watchpoints
VS data breakpoints
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I have this in my code in my main function.
{
int buncha_ints[] = { 0, 0, 0, 0, 0 };
}
when its not there my program works fine, and when it is there my program doesn't work. My question is, shouldn't this have absolutely no affect? A new scope is opened and then closed right away. This array is allocated, initialized and then cleaned off the stack. This has to be a compiler error if this is affecting the rest of my program right?
That's really my question but if more specifics are requested, This is a fairly simple DirectX11 Win32 program. I'm just rendering 2 squares to screen and when I put the above code in it doesn't render anymore. I wasn't able to render a third square and after experimenting I found a couple of oddities that boil down to the problem above, whenever something more than 4 bytes was allocated, no matter where it was, even if it is never called, my program stops rendering. Which seems notable sense my target platform is 32-bit.
This is a typical sign of accessing wrong memory location. i.e. some where in some other part of your program you are doing a beyond range access. When you define that array you are just shifting your memory blocks around. Just simply use valgrind to check that.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I have met a stack overflow in a program compiled using vc++ 2010. I open a debugger and attached it to the process.
Then I force the program to continue after the stack overflow error, every time there would be an access violation error.
My question is: is the access violation error caused by the stack overflow?
Yes. In Windows, stack overflow is detected by having an unreadable page of memory past the end of the stack. The first fault in this page raises a stack overflow exception. The next one raises an access violation.
But, to get to the core of the problem: don't do that. Stack overflows are not recoverable. Once you've had a stack overflow, your program is in an indeterminate state and you should just let it die.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I got a segmentation fault when trying to use one cpp file and tried to locate the error using Valgrind, but I'm confused.
Since the code is very large, I will only post a short portion of it below:
It looks like you are running valgrind on the compiler. Unless you are trying to debug the compiler, you should be running valgrind on your application instead:
valgrind --leak-check=yes ./MyApp
(replace ./MyApp with the appropriate executable name and arguments, of course)
(Explanation: valgrind is a run-time analysis tool; it takes your application as input. It is not a compiler tool like some of the other debugging tools that are out there)
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I have tried searching for this online, but I haven't had any luck. I'm hoping there are some theories here. We were able to get our code to crash on this line:
pipe = popen(cmd, "w");
cmd has recently been allocated, but the allocation was checked to verify that it wasn't null and inspecting the core file reveals that it is indeed a valid string. I'm curious what else would cause popen to segfault if the parameters passed in are valid ? Will popen segfault if there are no more available file descriptors on the system? Are there any other things I can look into for why this might've failed?
Thanks.