It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I went through so many topics asking about "Why does release build fail and not debug?", but I'm across a situation where it's reverse.
Here release build works fine but Debug mode build breaks.
What are possible reasons or situations where this can happen?
Any reply is appreciated.
Thanks in advance.
One of our friend gave some direction towards memory freeing issue..
This is the same thing i'm facing...
When I build in release mode it build successfully, but when I try to build in debug mode it fails/breaks at a point where there is statement for freeing up the allocated memory..
code is like: check if buffer is null, and free it if it's not null...
if(buffer){
free(buffer)
}
When I keep breakpoint on that line (inside if loop) and check value in debug mode, it appears as "bad pointer".(0x000000)
but then question remains like why it went inside of if-loop even though buffer has value 0x000000 ?
I don't know the details about your environment, but some debug environments take extra steps to trigger bugs (e.g. filling freed memory with invalid data), whereas the release build does not, giving you more chances to get lucky.
The problem is that your luck tends to run out when you move up from test data into a real environment....
I would suggest that if you are using visual studio, probably you have different configurations (linker, libraries, paths, etc.) for different profiles: Debug, Release. In general this IDE, like Visual Studio, come with this type of GUI configuration for those modes.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Ok so I wrote this minimal C code and complied it to an executable in release mode
1.void main()
2.{ for(;;); } //this is here to make the app hang.
The executable file size itself is 6kb, I didn't include any headers. Even if the entire exe file gets copied to the ram, apparently it shouldn't occupy more than 7 kb, nevertheless the OS allocates 320 kb, why is that? I'm using windows.
It seems like you're confused and mixing a wide variety of concepts. Let me try to explain:
That program is very clearly an infinite loop which explains why it doesn't end (or what you call "hang").
The compiler/linker still need to write a valid executable for your OS, and this involves a bunch of headers and stuff, which could be easily consuming 6kb.
320kb in a mainstream OS at this point in time seems like almost nothing and it can mainly be OS overhead. It is hard to say more without knowing what OS.
I strongly encourage you to disassemble your code. Another option is to play with your compiler options to optimize for executable size. I think the bottom line is that you're expecting that since your program doesn't do anything useful its size should be zero, and this is an unreasonable expectation.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Guys!
I have written a c++ source.
But I find someplace there is a error.
"Segmentation fault: 11"
But I don't know the details about the error and where to fix?
Do you guys knows some commands can show where the error is.
Thanks
With gcc generated code you typically use a gdb-based tool or gdb itself. Just run
gdb <program>
... and then inside gdb:
run <arguments>
... and it will stop where the crash happens.
To get reasonable information about the program location you want to compile with debug information,i.e., using the -g option. To avoid confusion you might want to compile without optimization, i.e., without any -O... option. However, some errors are only triggered when optimization is turned on (note: these are generally still errors in your code and not in the optimizer).
Use the GNU Debugger (GDB). Add break points and run the code. Here is where you can find stuff. http://www.unknownroad.com/rtfm/gdbtut/gdbtoc.html
It sounds like your program is trying to access an invalid (non-existent) address. It is also possible that it's trying to access misaligned data. I've seen this before when attempting to access misaligned structures.
Read up on segmentation faults: http://en.wikipedia.org/wiki/Segmentation_fault
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
It seems like the bugs in my project are evolving. While in the beginning time, causers of program crashes were easily to spot using the debugger (the line it points to after the program crashes), it's different now.
Many bugs cause the program to crash in completely arbitary places not even closely related to them.
How can I spot bugs "hiding" from the debugger in a better way?
(I use Visual Studio 2010)
Profile your code for memory corruption, memory overwrites and memory leaks.
Root cause analysis.
When you find an obvious bug, don't just fix the bug, fix the coding style that allowed it.
If you have any code using raw memory and pointers, replace it by memory allocated using std::vector and its iterators. It will compile to exactly the same speedy code in Release mode, but in Debug mode it will used checked iterators, which will catch some bugs as early as possible.
Use memory corruption checking utilities, like gflags or debug heap. "Floating" crushes almost always come from corrupted memory in C++ programs
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I have a really nasty bug in my program, which grew quite complex over time. It's probably the worst bug I've ever had.
I think that it might be related to a static variable initialization fiasco, but how can I ensure myself of that?
When the bug strikes, the program crashes due to heap corruption at a random point after startup, but far inside the main() function.
To be honest, I don't know what to do.
I'm on Windows 7 using Microsoft Visual Studio 2010
my program, which grew quite complex
over time
Do you keep backups of previous versions?
Find an older version that worked and continue working based on that version...
There is a famous quote out there:
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan
If this program has become more complicated than you can handle then it may be time to think about refactoring.
(This is in no way intended to be demeaning or to be taken as a personal attack...)
Run your program in the debugger, and step through the code until you see what's wrong. Place breakpoints liberally anywhere you think the bug might be caused.
Try debugging your program with gdb.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
This is a further question for my previous one here.
Is there a general solution for this?
Fix all dangling pointers
Fix all buffer overflows
Use pointers only where they are really needed
Reading your original post I'm not 100% you are facing a heap-corruption and you really hope you don't because if you would this is one of the most tricky errors to track down and AFAIK there are no solutions that always work.
However, if you are positive its a heap-corruption and you are on the windows platform you could try out the tool gflags. This advanced debugging tools allow you to install a debug heap manager in order to make it possible to find certain kinds of heap corruptions. One of the neat options it has is to make each allocation in it's own page or to write protect the heap datastructures. This makes it easier to pinpoint the exact location of the heap-corruption. It sucks lots of memory and CPU though.
Another tip if you are using Visual Studio is that if you manage to find that something is corrupting the data after a certain point of time and you wish to find the code that corrupts the data you can use Data Breakpoint to break whenever someone changes the data in question.
I wish you good luck.
Adding to swegi's answer I would check all your C++ constructors and all C initializations. Transform all dynamic C++ constructors (those where you put the init code in the function body) into static ones (where you initialize with the special constructor syntax). And be sure that you init all pointers and pointer members to 0. For C, I would initialize all variables.
Then, on unix I would use valgrind, usually this is quite good in finding all access violations and if you compile with all debugging options on it is able to trace it to the source line. There should be something similar on windows, too.