memory-corruption

I had this nasty bug that disappeared in the past but now after quite some time it returned. I have two TSam objects (derived from TPersistent) created and loaded into an TAsmJob object (derived from TObjectList). At runtime, a form creates a TStringGrid and then the AsmJob which creates those two SAM objects (and load some data from disk in each of them). The AsmJob is also assigned to the grid. When the form is destroyed, the Grid takes care of the AsmJob by freeing it, which frees the TSam objects. Here is the problem: the first object is freed withot problems but the second one dies when

I have a large code base that can use boost::any or boost::spirit::hold_any (depending on a macro definition). hold_any seems to be compatible with boost::any (e.g. How to print boost::any to a stream? or Type erasure - Part IV ) and faster ( Why you shouldn’t use boost::any ) but I'm experiencing several segmentation fault errors using hold_any (Boost v1.55 / 1.54 / 1.53). This is a minimal working example that exhibits the same problem as the original code: #include <iostream> #include <string> #include <vector> #include <boost/spirit/home/support/detail/hold_any.hpp> typedef boost::spirit:

I recently encountered my first battle (solved) with heap corruption. On my linux machine at home the culprit code exits without error using valgrind and electric-fence(with gdb). Yet on the windows machine in our lab, I consistently get the heap corruption related error message from VS described in my referenced post. Is it surprising (or at least uncommon) that valgrind and electric fence wouldn't detect such a problem? Someone else mentioned a possibly similar bug that eluded valgrind in a answer here . What might be some reasons why this problem wouldn't be detected by these tools? Is

We have a complex program that is working well on heavy duty input (any input actually) with no multithreading implemented. We've implemented multithreading with a threadpool, and given these input parameters I get these results: ( Note : Where I say no errors , it means I've tested with valgrind -v and when I say no memory leaks , it means I've tested it with valgrind --leak-check=full -v ). small_file: Runs successfully with more than 1 workers (threads), no valgrind errors, no memory leaks medium_file: With 1 worker it runs successfully, no errors/memory leaks. With > 1 workers, I get: a.

when I try the code below it works fine. Am I missing something? main() { int *p; p=malloc(sizeof(int)); printf("size of p=%d\n",sizeof(p)); p[500]=999999; printf("p[0]=%d",p[500]); return 0; } I tried it with malloc(0*sizeof(int)) or anything but it works just fine. The program only crashes when I don't use malloc at all. So even if I allocate 0 memory for the array p, it still stores values properly. So why am I even bothering with malloc then? It might appear to work fine, but it isn't very safe at all. By writing data outside the allocated block of memory you are overwriting some data you