Profiling a C or C++ based application that never exits [closed] - c++

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have a small doubt regarding profiling applications which never exit until we manually reboot the machine.
I used tools like valgrind which talks about memory leaks or bloating of any application which exits after sometime.
But is there any tool which can be used to tell about memory consumption, bloating, overhead created by the application at various stages if possible?
NOTE: I am more intrested to know about apps which dont exit ... If an app exits I can use tools like valgrind ..

I'd consider adding a graceful exit from the program.

dtrosset's point is well put but apparently misunderstood. Add a means to terminate the program so you can perform a clean analysis. This can be something as simple as adding a signal handler for SIGUSR1, for example, that terminates the program at a point in time you decide. There are a variety of methods at your disposal depending on your OS.
There's a big difference between an application which never exits (embedded, daemons, etc) and one that cannot be exited. The prior is normal, the latter is bad design.
If anything, that application can be forcibly aborted (SIGKILL on *nix, terminate on win32) and you'd get your analysis. That method doesn't give your application the opportunity to clean up before it's destroyed so there will be very likely be retained memory reported.

Profiling is intrusive, so you don't want to deploy the app with the profiler attached, anyway. Therefore, include some #ifdef PROFILE_MODE-code that exits the app after an appropriate amount of time. Compile with -DPROFLILE_MODE, profile. Deploy without PROFILE_MODE.

Modify your program slightly so that you can request a Valgrind leak check at any point - when the command to do that is recieved, your program should use VALGRIND_DO_LEAK_CHECK from memcheck.h (this will have no effect if the program isn't running under Valgrind).

You can use GNU gprof, but it has also the problem that it requires an exit of the program.
You can overcom this by calling internal functions of gprof. (see below) It may be a real "dirty" hack, depending on the version of gcc and, and, and,... but it works.
#include "sys/gmon.h"
extern "C" //the internal functions and vars of gprof
{
void moncontrol (int mode);
void monstartup (unsigned long lowpc, unsigned long highpc);
void _mcleanup (void);
extern void _start(void), etext(void);
extern int __libc_enable_secure;
}
// call this whenever you want to write profiling information to file
void WriteProfilingInformation(char* Name)
{
setenv("GMON_OUT_PREFIX",Name,1); // set file name
int old = __libc_enable_secure; // save old value
__libc_enable_secure = 0; // has to be zero to change profile file name
_mcleanup();
__libc_enable_secure = old; // reset to old value
monstartup(lowpc, highpc); // restart profiler
moncontrol(1); // enable profiler
}

Rational Purify can do that, at least on windows. There seem to be a linux version but I don't know if it can do the same.

Some tools allow you to force a memory analysis at any point during the program's execution. This method is not as reliable as checking on exit, but it gives you a starting point.
Here's a Windows example using LeakDiag.

Have you tried GNU Gprof?
Note that in this document, "cc" and "gcc" are interchangeable. ("cc" is assumed as an alias for "gcc.")
http://www.cs.utah.edu/dept/old/texinfo/as/gprof_toc.html

Your question reads as if you were looking for top. It nicely displays (among other things) the current memory consumption of all running processes. (Limited to one page in the terminal.) On Linux, hit “M” to sort by memory usage. The man page shows more options for sorting and filtering.

I have used rational purify API's to check incremental leaks. Haven't used the API's in linux. I found the VALGRIND_DO_LEAK_CHECK option in Valgrind User Manual, I think this would suffice your requirement.

For windows, DebugDiag does that.
Generates a report in the end with probable memory leaks.
Also has memory pressure analysis.
And it's available for free # microsoft. Download it from here

You need stackshots. Either use pstack or lsstack, or just run it under a debugger or IDE and pause it (Ctrl-C) at random. It will not tell you about memory leaks, but it will give you a good idea of how the time is being used and why.
If time is being used because of memory leaks, you will see a good percent of samples ending in memory management routines. If they are in malloc or new, higher up the stack you will see what objects are being allocated and why, and you can consider how to do that less often.

Work of program that profiling memory leaks is based on detecting memory that was freed by OS not by program.

Related

C++ detect memory allocation

I am trying to improve the performance of my C++ program and I found that converting memory allocations (mallocs) into object pool is giving great results.
The problem is detecting the places from which malloc is called, since the code base is quite large. I can't use simple gdb with break points because there are many timers and signal handlers running in parallel.
Is there a way in gdb using which I can print the entire stack trace whenever malloc is called without having to do it manually each time.
OR
Can you suggest any other tool which will help me do the same.
You can script gdb using Python.
You can also implement your own malloc function and link with that. The return address will be on the stack, which will give you the caller.
The valgrind suite of tools contains massif which you can use for precisely this purpose:
valgrind --tool=massif ./mybinary
This collects details of all allocations including stack traces that you can examine after the program has finished executing. Please see the massif documentation for more details on the output: http://valgrind.org/docs/manual/ms-manual.html. Hope that helps.
P.S. Also checkout the TCMalloc library - it already possibly already does what you want, although you can do better depending on your specific application. The best thing is that no source code changes are needed - you simply replace the malloc function from glibc using a linker directive.

Memory allocation crashes the OS. Who's to blame beside the OS [closed]

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 7 years ago.
Improve this question
This short snippet
#include <new>
int main(){
while(true){
try{
new char[0x10000000];
}catch(std::bad_alloc bac){
}
}
}
apparently crashes the entire operating system when compiled as a 64 bit application and run on a 64 bit Windows system.
This is a valid c++ program. How can this happen? Isn't the msvc compiler at fault here too?
All other compiler/system combinations left the system sluggish at worst.
Don't try this at home. user Christophe tried this on his system and it crashed.
To commenters: I'm not interested in debugging. This is a valid c++ program. My code is not at fault. I'm curious what might induce this behaviour.
One quite plausible scenario for "blue screen when an application is using a lot of memory" is a driver that crashes. There are two common problems here:
Driver that can't allocate memory and doesn't detect the NULL returned by allocation function when it couldn't allocate memory", resulting in a NULL [or close to NULL] memory access.
Driver doesn't properly "lock" it's memory buffers, leading to pages that the driver "needs" being swapped out when it comes to use the page - this leads to "IRQL Not Less or Equal" blue-screen, which is caused by OS detecting that a page-in request happens when the driver is in a mode where the scheduler is "locked". In other words, the driver asked for "no other task must run until I finish this", and then a page-fault happens that is a request to page in a page from the swap, which indeed requires a different task [the swapper process] to run - can't have the cake and eat it, so OS says "No can do" - can't continue at that point, since the driver is not able to access memory, can't switch to another task, so we can't do anything other than "report error and stop".
A third alternative is that the driver detects that it can't allocate memory, but decides that it can not continue and then issues its own blue-screen by calling the "I want to bluescreen now" function in Windows. Drivers that are well written should not do this, but like some driver writers still decide that this is a "good idea".
Sorry, it's been about 11 years since I wrote windows drivers, so the exact error codes one can expect here have gone missing. I think 7B for IRQLNotLessOrEqual, and 0xC00000005 for the access of unmapped memory (NULL access etc).
The fact that several different machines behave the same can easily be explained by many machines having either similar hardware (e.g. same printer, USB [mouse or keyboard?] or CD-ROM drive that is flaky), or by having the same antivirus software - AV software always has a driver component to "hook" into other processes and such.
Given that "really running out of memory" is not so common these days, not so skilled/experienced/conscientious developers may well not test properly with either fake out of memory or real out of memory situations, and thus not detect that their driver fails in this situation.
To give more details, we'd need to know at least the blue-screen "code" (four to five hex-numbers at the top of the screen)
Assuming there is some point to debugging this sort of failure, you can either set up windows to store a a dump (or mini-dump) when it crashes, or use a second PC to connect WinDBG as a remote debugger [or some other remote debugger] to the machine that is crashing - when a machine blue-screens, it will stop in the debugger before restarting, so you can see what the state of the system is, including looking at the callstack of the code that caused the crash - which typically will show what component is actually causing the problem. However, unless you actually have a good contact with the driver developers (at the very least an email address to the relevant support people), it's unlikely much can be achieved to solve this.

How to crash a system programmatically [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
If I could write a user program that would crash my OS (not my application), how would I do it?
I was thinking somehow switch my usermode program to kernel mode and cause a memory corruption. Is it possible?
Note: I am not creating a virus. Just curiosity.
KeBugCheck on Windows is the documented way to get a BSOD.
You can also try deleting the root registry key (\REGISTRY) in Windows XP, using the native NT API.
Write and load a kernel module that calls panic() or implement equivalent thereof.
Or simply exec the shutdown or halt command or the syscall that implements it.
If the OS happens to be windows, create a fake driver that dereferences a NULL pointer. Crash!
The whole idea of an operating system is that a user program can't crash it under normal conditions. Of course you could still do something like exhaust the disk space on a partition that is used for a swap file and that would impair many operating systems or you could find a known vulnerability but there's no very easy way to reliably crash it.
In Linux, Alt-SysRq-C will crash/restart your kernel.
In Windows, see: https://web.archive.org/web/20110513143420/http://www.dailygyan.com/2008/09/some-methods-to-crash-your-windows.html
[Ed: March 8, 2021 - Switch to Archive.org link due to site going down.]
For Windows one possibility is to write a kernel mode driver which locks some memory pages owned by a process and then terminate that process. Will result in a BSOD "Process has locked pages".
Linux: Even though not strictly crashing the OS, you can quite easily make it unusable by allocating lots of memory (and read/writing it for the allocation to actually become effective and make the OS swap a lot) and by forking lots of processes. "Fork bomb" is the keyword and can even be done in shell script.
I think the reason why you want to crash the OS is relevant here. Are you trying to simulate a condition for testing, or are you just plain curious?
Here are two options if you wish to recreate, and automate, crashing, for the purpose of fault tolerance.
Run insider a virtual machine (vmware, VirtualBox) and simply kill the VM process. Alternately you can give it very low priority, drop devices, or otherwise simulate bad things.
Use servers that have a management console. This will have an API that can simply turn off the device.
The other numerous suggestions are good if you wish to crash from within the OS itself. These software crashes can help reproduce a miscreant process. A similar set of hardware related crashes could also work (such as reducing speed on a programmable fan and overheating the CPU).
The reason behind your request is actually quite important since all the different faults will yield a slightly different result.
Try allocating chunks of memory until you have no free memory:
int alloced = 0;
for(;;)
{
char *alloc = malloc(10*1024*1024); // alloc 10 MB
if(alloc != NULL)
{
alloced += 10;
// edit: you have to memset the memory otherwise the system will give it back to you next time
memset(alloc, 0xab, 10*1024*1024);
printf(" alloced %d MB\n", alloced);
}
}
edit:
I actually tried just right now on a 64 bits linux with 2GB of ram and 3.3GB of swap: the screen has frozen, I could allocate 4950MB of ram, but then the process was killed by the system, and linux fell back on its feet gracefully, so, no, this doesnt work :=)
Crash an OS using pure user-mode application means the kernel is vulnerable.
If the OS is well tested, then this should not occur.
You can try BSoD Windows by attacking bugous 3rd-party drivers via sending garbage IO-CONTROLs to them.
DeviceIoControl Function (Windows)
http://msdn.microsoft.com/en-us/library/aa363216(VS.85).aspx

C++: Where to start when my application crashes at random places?

I'm developing a game and when I do a specific action in the game, it crashes.
So I went debugging and I saw my application crashed at simple C++ statements like if, return, ... Each time when I re-run, it crashes randomly at one of 3 lines and it never succeeds.
line 1:
if (dynamic) { ... } // dynamic is a bool member of my class
line 2:
return m_Fixture; // a line of the Box2D physical engine. m_Fixture is a pointer.
line 3:
return m_Density; // The body of a simple getter for an integer.
I get no errors from the app nor the OS...
Are there hints, tips or tricks to debug more efficient and get known what is going on?
That's why I love Java...
Thanks
Random crashes like this are usually caused by stack corruption, since these are branching instructions and thus are sensitive to the condition of the stack. These are somewhat hard to track down, but you should run valgrind and examine the call stack on each crash to try and identify common functions that might be the root cause of the error.
Are there hints, tips or tricks to debug more efficient and get known what is going on?
Run game in debugger, on the point of crash, check values of all arguments. Either using visual studio watch window or using gdb. Using "call stack" check parent routines, try to think what could go wrong.
In suspicious(potentially related to crash) routines, consider dumping all arguments to stderr (if you're using libsdl or on *nixlike systems), or write a logfile, or send dupilcates of all error messages using (on Windows) OutputDebugString. This will make them visible in "output" window in visual studio or debugger. You can also write "traces" (log("function %s was called", __FUNCTION__))
If you can't debug immediately, produce core dumps on crash. On windows it can be done using MiniDumpWriteDump, on linux it is set somewhere in configuration variables. core dumps can be handled by debugger. I'm not sure if VS express can deal with them on Windows, but you still can debug them using WinDBG.
if crash happens within class, check *this argument. It could be invalid or zero.
If the bug is truly evil (elusive stack corruption in multithreaded app that leads to delayed crash), write custom memory manager, that will override new/delete, provide alternative to malloc(if your app for some reason uses it, which may be possible), AND that locks all unused memory memory using VirtualProtect (windows) or OS-specific alternative. In this case all potentially dangerous operation will crash app instantly, which will allow you to debug the problem (if you have Just-In-Time debugger) and instantly find dangerous routine. I prefer such "custom memory manager" to boundschecker and such - since in my experience it was more useful. As an alternative you could try to use valgrind, which is available on linux only. Note, that if your app very frequently allocates memory, you'll need a large amount of RAM in order to be able to lock every unused memory block (because in order to be locked, block should be PAGE_SIZE bytes big).
In areas where you need sanity check either use ASSERT, or (IMO better solution) write a routine that will crash the application (by throwing an std::exception with a meaningful message) if some condition isn't met.
If you've identified a problematic routine, walk through it using debugger's step into/step over. Watch the arguments.
If you've identified a problematic routine, but can't directly debug it for whatever reason, after every statement within that routine, dump all variables into stderr or logfile (fprintf or iostreams - your choice). Then analyze outputs and think how it could have happened. Make sure to flush logfile after every write, or you might miss the data right before the crash.
In general you should be happy that app crashes somewhere. Crash means a bug you can quickly find using debugger and exterminate. Bugs that don't crash the program are much more difficult (example of truly complex bug: given 100000 values of input, after few hundreds of manipulations with values, among thousands of outputs, app produces 1 absolutely incorrect result, which shouldn't have happened at all)
That's why I love Java...
Excuse me, if you can't deal with language, it is entirely your fault. If you can't handle the tool, either pick another one or improve your skill. It is possible to make game in java, by the way.
These are mostly due to stack corruption, but heap corruption can also affect programs in this way.
stack corruption occurs most of the time because of "off by one errors".
heap corruption occurs because of new/delete not being handled carefully, like double delete.
Basically what happens is that the overflow/corruption overwrites an important instruction, then much much later on, when you try to execute the instruction, it will crash.
I generally like to take a second to step back and think through the code, trying to catch any logic errors.
You might try commenting out different parts of the code and seeing if it affects how the program is compiled.
Besides those two things you could try using a debugger like Visual Studio or Eclipse etc...
Lastly you could try to post your code and the error you are getting on a website with a community that knows programming and could help you work through the error (read: stackoverflow)
Crashes / Seg faults usually happen when you access a memory location that it is not allowed to access, or you attempt to access a memory location in a way that is not allowed (for example, attempting to write to a read-only location).
There are many memory analyzer tools, for example I use Valgrind which is really great in telling what the issue is (not only the line number, but also what's causing the crash).
There are no simple C++ statements. An if is only as simple as the condition you evaluate. A return is only as simple as the expression you return.
You should use a debugger and/or post some of the crashing code. Can't be of much use with "my app crashed" as information.
I had problems like this before. I was trying to refresh the GUI from different threads.
If the if statements involve dereferencing pointers, you're almost certainly corrupting the stack (this explains why an innocent return 0 would crash...)
This can happen, for instance, by going out of bounds in an array (you should be using std::vector!), trying to strcpy a char[]-based string missing the ending '\0' (you should be using std::string!), passing a bad size to memcpy (you should be using copy-constructors!), etc.
Try to figure out a way to reproduce it reliably, then place a watch on the corrupted pointer. Run through the code line-by-line until you find the very line that corrupts the pointer.
Look at the disassembly. Almost any C/C++ debugger will be happy to show you the machine code and the registers where the program crashed. The registers include the Instruction Pointer (EIP or RIP on x86/x64) which is where the program was when it stopped. The other registers usually have memory addresses or data. If the memory address is 0 or a bad pointer, there is your problem.
Then you just have to work backward to find out how it got that way. Hardware breakpoints on memory changes are very helpful here.
On a Linux/BSD/Mac, using GDB's scripting features can help a lot here. You can script things so that after the breakpoint is hit 20 times it enables a hardware watch on the address of array element 17. Etc.
You can also write debugging into your program. Use the assert() function. Everywhere!
Use assert to check the arguments to every function. Use assert to check the state of every object before you exit the function. In a game, assert that the player is on the map, that the player has health between 0 and 100, assert everything that you can think of. For complicated objects write verify() or validate() functions into the object itself that checks everything about it and then call those from an assert().
Another way to write in debugging is to have the program use signal() in Linux or asm int 3 in Windows to break into the debugger from the program. Then you can write temporary code into the program to check if it is on iteration 1117321 of the main loop. That can be useful if the bug always happens at 1117322. The program will execute much faster this way than to use a debugger breakpoint.
some tips :
- run your application under a debugger, with the symbol files (PDB) together.
- How to set Visual Studio as the default post-mortem debugger?
- set default debugger for WinDbg Just-in-time Debugging
- check memory allocations Overriding new and delete, and Overriding malloc and free
One other trick: turn off code optimization and see if the crash points make more sense. Optimization is allowed to float little bits of your code to surprising places; mapping that back to source code lines can be less than perfect.
Check pointers. At a guess, you're dereferencing a null pointer.
I've found 'random' crashes when there are some reference to a deleted object. As the memory is not necessarily overwritten, in many cases you don't notice it and the program works correctly, and than crashes after the memory was updated and is not valid anymore.
JUST FOR DEBUGGING PURPOSES, try commenting out some suspicious 'deletes'. Then, if it doesn't crash anymore, there you are.
use the GNU Debugger
Refactoring.
Scan all the code, make it clearer if not clear at first read, try to understand what you wrote and immediately fix what seems incorrect.
You'll certainly discover the problem(s) this way and fix a lot of other problems too.

How to debug heap corruption errors?

I am debugging a (native) multi-threaded C++ application under Visual Studio 2008. On seemingly random occasions, I get a "Windows has triggered a break point..." error with a note that this might be due to a corruption in the heap. These errors won't always crash the application right away, although it is likely to crash short after.
The big problem with these errors is that they pop up only after the corruption has actually taken place, which makes them very hard to track and debug, especially on a multi-threaded application.
What sort of things can cause these errors?
How do I debug them?
Tips, tools, methods, enlightments... are welcome.
Application Verifier combined with Debugging Tools for Windows is an amazing setup. You can get both as a part of the Windows Driver Kit or the lighter Windows SDK. (Found out about Application Verifier when researching an earlier question about a heap corruption issue.) I've used BoundsChecker and Insure++ (mentioned in other answers) in the past too, although I was surprised how much functionality was in Application Verifier.
Electric Fence (aka "efence"), dmalloc, valgrind, and so forth are all worth mentioning, but most of these are much easier to get running under *nix than Windows. Valgrind is ridiculously flexible: I've debugged large server software with many heap issues using it.
When all else fails, you can provide your own global operator new/delete and malloc/calloc/realloc overloads -- how to do so will vary a bit depending on compiler and platform -- and this will be a bit of an investment -- but it may pay off over the long run. The desirable feature list should look familiar from dmalloc and electricfence, and the surprisingly excellent book Writing Solid Code:
sentry values: allow a little more space before and after each alloc, respecting maximum alignment requirement; fill with magic numbers (helps catch buffer overflows and underflows, and the occasional "wild" pointer)
alloc fill: fill new allocations with a magic non-0 value -- Visual C++ will already do this for you in Debug builds (helps catch use of uninitialized vars)
free fill: fill in freed memory with a magic non-0 value, designed to trigger a segfault if it's dereferenced in most cases (helps catch dangling pointers)
delayed free: don't return freed memory to the heap for a while, keep it free filled but not available (helps catch more dangling pointers, catches proximate double-frees)
tracking: being able to record where an allocation was made can sometimes be useful
Note that in our local homebrew system (for an embedded target) we keep the tracking separate from most of the other stuff, because the run-time overhead is much higher.
If you're interested in more reasons to overload these allocation functions/operators, take a look at my answer to "Any reason to overload global operator new and delete?"; shameless self-promotion aside, it lists other techniques that are helpful in tracking heap corruption errors, as well as other applicable tools.
Because I keep finding my own answer here when searching for alloc/free/fence values MS uses, here's another answer that covers Microsoft dbgheap fill values.
You can detect a lot of heap corruption problems by enabling Page Heap for your application . To do this you need to use gflags.exe that comes as a part of Debugging Tools For Windows
Run Gflags.exe and in the Image file options for your executable, check "Enable Page Heap" option.
Now restart your exe and attach to a debugger. With Page Heap enabled, the application will break into debugger whenever any heap corruption occurs.
To really slow things down and perform a lot of runtime checking, try adding the following at the top of your main() or equivalent in Microsoft Visual Studio C++
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF | _CRTDBG_CHECK_ALWAYS_DF );
A very relevant article is Debugging Heap corruption with Application Verifier and Debugdiag.
What sort of things can cause these errors?
Doing naughty things with memory, e.g. writing after the end of a buffer, or writing to a buffer after it's been freed back to the heap.
How do I debug them?
Use an instrument which adds automated bounds-checking to your executable: i.e. valgrind on Unix, or a tool like BoundsChecker (Wikipedia suggests also Purify and Insure++) on Windows.
Beware that these will slow your application, so they may be unusable if yours is a soft-real-time application.
Another possible debugging aid/tool might be MicroQuill's HeapAgent.
One quick tip, that I got from Detecting access to freed memory is this:
If you want to locate the error
quickly, without checking every
statement that accesses the memory
block, you can set the memory pointer
to an invalid value after freeing the
block:
#ifdef _DEBUG // detect the access to freed memory
#undef free
#define free(p) _free_dbg(p, _NORMAL_BLOCK); *(int*)&p = 0x666;
#endif
The best tool I found useful and worked every time is code review (with good code reviewers).
Other than code review, I'd first try Page Heap. Page Heap takes a few seconds to set up and with luck it might pinpoint your problem.
If no luck with Page Heap, download Debugging Tools for Windows from Microsoft and learn to use the WinDbg. Sorry couldn't give you more specific help, but debuging multi-threaded heap corruption is more an art than science. Google for "WinDbg heap corruption" and you should find many articles on the subject.
What type of allocation functions are you using? I recently hit a similar error using the Heap* style allocation functions.
It turned out that I was mistakenly creating the heap with the HEAP_NO_SERIALIZE option. This essentially makes the Heap functions run without thread safety. It's a performance improvement if used properly but shouldn't ever be used if you are using HeapAlloc in a multi-threaded program [1]. I only mention this because your post mentions you have a multi-threaded app. If you are using HEAP_NO_SERIALIZE anywhere, delete that and it will likely fix your problem.
[1] There are certain situations where this is legal, but it requires you to serialize calls to Heap* and is typically not the case for multi-threaded programs.
If these errors occur randomly, there is high probability that you encountered data-races. Please, check: do you modify shared memory pointers from different threads? Intel Thread Checker may help to detect such issues in multithreaded program.
You may also want to check to see whether you're linking against the dynamic or static C runtime library. If your DLL files are linking against the static C runtime library, then the DLL files have separate heaps.
Hence, if you were to create an object in one DLL and try to free it in another DLL, you would get the same message you're seeing above. This problem is referenced in another Stack Overflow question, Freeing memory allocated in a different DLL.
In addition to looking for tools, consider looking for a likely culprit. Is there any component you're using, perhaps not written by you, which may not have been designed and tested to run in a multithreaded environment? Or simply one which you do not know has run in such an environment.
The last time it happened to me, it was a native package which had been successfully used from batch jobs for years. But it was the first time at this company that it had been used from a .NET web service (which is multithreaded). That was it - they had lied about the code being thread safe.
You can use VC CRT Heap-Check macros for _CrtSetDbgFlag: _CRTDBG_CHECK_ALWAYS_DF or _CRTDBG_CHECK_EVERY_16_DF.._CRTDBG_CHECK_EVERY_1024_DF.
I'd like to add my experience. In the last few days, I solved an instance of this error in my application. In my particular case, the errors in the code were:
Removing elements from an STL collection while iterating over it (I believe there are debug flags in Visual Studio to catch these things; I caught it during code review)
This one is more complex, I'll divide it in steps:
From a native C++ thread, call back into managed code
In managed land, call Control.Invoke and dispose a managed object which wraps the native object to which the callback belongs.
Since the object is still alive inside the native thread (it will remain blocked in the callback call until Control.Invoke ends). I should clarify that I use boost::thread, so I use a member function as the thread function.
Solution: Use Control.BeginInvoke (my GUI is made with Winforms) instead so that the native thread can end before the object is destroyed (the callback's purpose is precisely notifying that the thread ended and the object can be destroyed).
I had a similar problem - and it popped up quite randomly. Perhaps something was corrupt in the build files, but I ended up fixing it by cleaning the project first then rebuilding.
So in addition to the other responses given:
What sort of things can cause these errors?
Something corrupt in the build file.
How do I debug them?
Cleaning the project and rebuilding. If it's fixed, this was likely the problem.
I have also faced this issue. In my case, I allocated for x size memory and appended the data for x+n size. So, when freeing it shown heap overflow. Just make sure your allocated memory sufficient and check for how many bytes added in the memory.