|
From: vicky l. <vic...@gm...> - 2010-01-27 09:06:41
|
Hi, all,
There was something strange happened when I used valgrind.
I run my linux program written in c++ and it threw a "segment fault",
but when I tried " valgrind --tool=memcheck -v ./mycode ", the program
did't throw segment fault and continued to run and returned the experimental
results.
I felt puzzled because segment fault means my code is not *correct*,
but why it could continue to run and get the results under valgrind
environment. Are the results got from running under valgrind environment
valid?
Thank you for your patience!
Best Wishes!
^_^
vicky
|
|
From: tom f. <tf...@al...> - 2010-01-27 21:25:43
|
vicky lin <vic...@gm...> writes: > There was something strange happened when I used valgrind. I run > my linux program written in c++ and it threw a "segment fault", but > when I tried " valgrind --tool=memcheck -v ./mycode ", the program > did't throw segment fault and continued to run and returned the > experimental results. [snip] > Are the results got from running under valgrind environment valid? Well, your program is buggy, but valgrind is doing the best it can under the circumstances. In that sense, the results are "valid". Your code almost definitely has some statement: *x = 42; in it, where `x' points to memory you do not own. In your normal environment, `x' probably points to either memory you don't own, or read-only memory, etc., and thus you get lucky and your program crashes. Under valgrind, that memory is memory that the process owns. This is most likely because valgrind allocates a lot of memory behind your back, and you're happily writing into that "extra" memory. This is basically the same reason that you'll get a segmentation fault on one machine and the program would run to completion on others. The good news is that the "invalid write"s that valgrind reports are almost assuredly the reason for your segfault. That said, if you've got a reproducible case, you're much better off fixing that segfault using gdb before running valgrind. Valgrind tends to be more useful in finding those invalid writes that *don't* cause your program to crash, because those are less visible under normal execution. Cheers, -tom |
|
From: Dave G. <go...@mc...> - 2010-01-27 22:24:21
|
On Jan 27, 2010, at 3:28 PM, tom fogal wrote: > vicky lin <vic...@gm...> writes: >> There was something strange happened when I used valgrind. I run >> my linux program written in c++ and it threw a "segment fault", but >> when I tried " valgrind --tool=memcheck -v ./mycode ", the program >> did't throw segment fault and continued to run and returned the >> experimental results. > [snip] >> Are the results got from running under valgrind environment valid? > > Well, your program is buggy, but valgrind is doing the best it can > under the circumstances. In that sense, the results are "valid". > > Your code almost definitely has some statement: > > *x = 42; [snip] You could also get this sort of behavior if your program is multithreaded and has a race condition in it. Thread scheduling running under valgrind is different than when running natively on the OS: http://valgrind.org/docs/manual/manual-core.html#manual-core.pthreads > That said, if you've > got a reproducible case, you're much better off fixing that segfault > using gdb before running valgrind. Agreed. If it doesn't happen when running under the debugger (perhaps because of the threading mentioned above), you can usually figure out what happened using gdb on the core dump after the fact. -Dave |