|
From: Jenny L. <jli...@pi...> - 2003-07-31 01:11:56
|
Hello, Hopefully someone can help me sort out this problem... I used to be able to run valgrind on my program in a reasonable time = period - 5 to 10 times slower than the program runs without it. Then, = some new code was introduced into the program. After this, valgrind = runs excruciatingly slow and when it finishes it claims "0 errors from 0 = contexts" and "0 bytes lost in 0 blocks". Before this new code was = introduced, there were numerous errors reported by valgrind. What I am running is a CppUnit test that isolates the newly introduced = code. When not under valgrind, the test completes in 4 seconds. When = running under valgrind it takes 13 minutes 54 seconds. Into this test I = intentionally created a string variable on the heap and never deleted = it. The valgrind output did catch this leak, but reported no memory = errors - which I really don't believe. Could this be because my program is doing something not supported by = valgrind? Any ideas for figuring out where it is getting hung up? I am running the valgrind-20030716 with Red Hat kernel 2.4.20-18.8. I = compiled valgrind on this machine. Thanks, Jenny Lighthart |
|
From: Nicholas N. <nj...@ca...> - 2003-07-31 07:35:50
|
On Wed, 30 Jul 2003, Jenny Lighthart wrote: > I used to be able to run valgrind on my program in a reasonable time > period - 5 to 10 times slower than the program runs without it. Then, > some new code was introduced into the program. After this, valgrind > runs excruciatingly slow and when it finishes it claims "0 errors from 0 > contexts" and "0 bytes lost in 0 blocks". Before this new code was > introduced, there were numerous errors reported by valgrind. > > What I am running is a CppUnit test that isolates the newly introduced > code. When not under valgrind, the test completes in 4 seconds. When > running under valgrind it takes 13 minutes 54 seconds. Into this test I > intentionally created a string variable on the heap and never deleted > it. The valgrind output did catch this leak, but reported no memory > errors - which I really don't believe. > > Could this be because my program is doing something not supported by > valgrind? Any ideas for figuring out where it is getting hung up? Generally if a program does something Valgrind can't handle, Valgrind aborts immediately. Valgrind doesn't run some kinds of code very well; I don't know the details much, but I think the way the scheduler handles syscalls, particularly blocking ones, can sometimes cause programs to run excessively slowly. Others know more about this than I do. If you can give some more details about what the added code is doing, that might be useful, although it's hard to say exactly what information would be relevant, since I don't understand this too well. N |
|
From: Julian S. <js...@ac...> - 2003-07-31 07:49:58
|
> > Could this be because my program is doing something not supported by > > valgrind? Any ideas for figuring out where it is getting hung up? Best of all, can you supply us with a test case to reproduce this with? Realistically that's the only way we can get to the bottom of this kind of problem. J |