On Tue, Jun 7, 2016 at 10:41 AM, Gert Doering <g...@greenie.muc.de> wrote:
> On Tue, Jun 07, 2016 at 05:33:07PM +0300, Samuli Seppänen wrote: > > > I played with valgrind a bit > > > > > > https://travis-ci.org/chipitsine/openvpn/jobs/135869065 > > > > > > Looks like there are leaks in openssl code, should we suppress it? > > > > I can't comment on the leaks themselves, but I wonder if it would make > > sense to run OpenVPN under Valgrind in "make check". For example, when > > using the Vagrant test VMs the loss of performance would not be a big > > deal - the tests would just run quite a bit longer. > > Unless you can whitelist certain findings, valgrind output will be LONG > (as can be seen in the URL above), and we can't do anything about memory > lost by OpenSSL etc. - so it's just long output of random numbers, which > nobody will bother to look at. Not everything that valgrind reports is really a leak. Not to say valgrind is not useful -- quite the contrary, and we find it very useful to catch leaks in our number-crunching codes all the time. Running valgrind with --leak-check=full --show-reachable=yes as in the link above would generate too much of not so useful output. In fact the output was longer than the 10K limit of travis. Use --leak-check=summary, leave out --show-reachable=yes, and keep show-leak-kinds at its default (i.e definite and possible leaks only). Then, if there are errors that look real one could locally check with --leak-check=full. In any case, suppress still-reachable warnings. All those "errors" seen in openssl are "still reachable" blocks which is not a leak. Selva
