From: Andy B. <and...@gm...> - 2012-08-22 20:30:55
|
> On Wed, 2012-08-22 at 12:21 +0100, Andy Buckle wrote: >> On 22 August 2012 12:11, dirk <dir...@co...> wrote: >> > Hello all - >> > I'm trying to learn valgrind for oct files... can anyone share a working >> > example I could study? >> > Hope so, thanks >> > - dirk >> >> Invoke octave from the command line of your OS, in a way that calls >> your oct-file function. Run the whole of octave through valgrind. You >> will probably want to generate suppressions by doing this and not >> calling your oct-file. >> >> In the past i have also used pre-processor to change around the code, >> so i can call parts of my code from the OS, instead of from Octave. >> This is much faster than running the whole of Octave through valgrind. >> >> Which bit do you want examples of? On 22 August 2012 20:58, dirk <dir...@co...> wrote: > thanks for the tips Andy. > I suspect my issues are just newbie problems, so any & all advice is > helpful. Here's an example point of confusion: > > $ valgrind octave --eval exit &> octave_grind.txt > > gets me this in the .txt: > > ==17994== LEAK SUMMARY: > ==17994== definitely lost: 3,108 bytes in 116 blocks > ==17994== indirectly lost: 27,994 bytes in 201 blocks > ==17994== possibly lost: 659,439 bytes in 3,101 blocks > ==17994== still reachable: 34,585,196 bytes in 6,407 blocks > ==17994== suppressed: 0 bytes in 0 blocks > > which seems to be telling that I lose 3k by just starting and stopping > octave... hard to believe. > > If it matters, I'm running octave 3.4.2 under linux, installed via > apt-get. > > - dirk (ooops, I forgot to reply-all) It's common to see that. I get the same kind of thing. It is probably Octave (or the libraries it depends on). Run that and make a suppression file to exclude the things that are not your fault. Then run your code through valgrind in a similar way, and you should only see things that are your fault. Write a bit of bad code on purpose to see what you get. Andy -- /* andy buckle */ |