What is the difference between valgrind and regular c++ run

I'm trying to identify a bug in I have in my code where I get seg. fault while trying to assign value to a pointer from a vector (it is descri开发者_开发百科be better in the link). When I run the code using valgrind I don't get the seg.fault.

What does valgrind do differently. I think that I need to consider the memory management differences between valgrind session and regular c++ session but I don't really know

---

From Valgrind FAQ:

4.4. My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening?

When a program runs under Valgrind, its environment is slightly different to when it runs natively. For example, the memory layout is different, and the way that threads are scheduled is different.

Most of the time this doesn't make any difference, but it can, particularly if your program is buggy. For example, if your program crashes because it erroneously accesses memory that is unaddressable, it's possible that this memory will not be unaddressable when run under Valgrind. Alternatively, if your program has data races, these may not manifest under Valgrind.

There isn't anything you can do to change this, it's just the nature of the way Valgrind works that it cannot exactly replicate a native execution environment. In the case where your program crashes due to a memory error when run natively but not when run under Valgrind, in most cases Memcheck should identify the bad memory operation.

So you can nothing to do with it. Actually you need not worry that you program not crashes under Valgrind. You should read error messages from it and fix them. Start with Invalid read/Invalid write errors. They are almost always indicate the bug in code. In this particular case you can also run your code in infinite loop from simple bash script utill it produces error message. Most likely you are working with invalid iterators and it is Undefined Behaviour in C++.

---

Maybe the issue might be timing dependent, When you run your code with valgrind it runs a little slower because valgrind collects and diagnoses your code at run time.

---

Valgrind keeps track of your programs memory usage. This is how it tells you about leaks. What this means is that it hijacks the malloc and such and uses its own so that it can achieve this. This means that probably when you run your code normally you read/write to some data you have freed accidentally causing segfault whereas it could be that valgrind is keeping this memory around to see if it is truly lost etc thereby meaning by (un)luck the memory is still valid. Just a guess.

---

Valgrind runs you program on a virtual CPU, that is, it executes every assembly instruction in software (apart from kernel calls). Multi-threaded programs get serialized, i.e. only one thread of execution is making progress at one time.

If your application is multi-threaded, when it is executed under valgrind race condition and the lack of synchronization may be masked by the thread serialization, so that the effects of such bugs are not observed.