clipka <nomail@nomail> wrote:
> I have no experience whatsoever with that tool. What does it do? Is it easy to
> use? I'm not developing on Linux, I just compile and run my code on it for
> performance and render quality evaluation

  valgrind works best if you compile with debug information (-g) and
without optimizations, because then if a problem happens it can tell
you the exact line where it did. Without debug information it can only
tell you the place with more or less accuracy, depending on how the
compiler generated the code. Optimizations can also mess things up
(because optimizations tend to remove code, inline code, move code
around, and all sort of stuff which is not nice when debugging).

  OTOH sometimes such an error does not happen in debug mode but only
when full optimizations are used. Sometimes it's the optimizations which
make the problem reveal itself. (It's not like the debug version is
bug-free. It's just that the code happens to be generated in such way
that the error doesn't manifest itself as a segfault.)

  So first try to compile with debug information and without optimizations,
and try to find the fastest possible way of causing the segfault. Then
just run valgrind giving it your command as parameter.

  As you probably noticed, valgrind makes the program run very slow,
which is why you should try to find the fastest possible situation
which causes the segfault, unless you want to wait a few days for
valgrind to do its job.

-- 
                                                          - Warp

Post a reply to this message