[erlang-questions] Tracking memory leaks in NIF/Linkedin drivers with Valgrind (or anything else)

[Zabrane Mickael]

I'm getting this error when trying with the Valgrind suppresion file shipped with Erlang R16B:

[..]
--91449-- Scheduler: using generic scheduler lock implementation.
--91449-- Reading suppressions file: /opt/otp_src_R16B/erts/emulator/valgrind/suppress.patched.3.6.0
location should be "...", or should start with "fun:" or "obj:"
==91449== FATAL: in suppressions file "/opt/otp_src_R16B/erts/emulator/valgrind/suppress.patched.3.6.0" near line 95:
==91449==    location should be "...", or should start with "fun:" or "obj:"
==91449== exiting now.


Regards,
Zabrane

On Mar 18, 2013, at 4:45 PM, Lukas Larsson wrote:

> Hello,
> 
> use the suppress file in erts/emulator/valgrind/suppress.standard to remove many of the false positive errors. It will not remove all, but many of the extra errors you see. To remove all you have to use erts/emulator/valgrind/suppress.patched.3.6.0, but this requires a patched version of valgrind as the normal suppression syntax was not expressive enough for our needs.
> 
> Lukas
> 
> 
> On Sun, Mar 17, 2013 at 10:35 AM, Zabrane Mickael <zabrane3@REDACTED> wrote:
> Hi guys,
> 
> I'm trying to use Valgrind to track memory leaks in C NIF/Linkedin drivers.
> For this, I've built a "Debug  Enabled" ERTS with Valgrind and SMP flavor:
> http://www.erlang.org/doc/installation_guide/INSTALL.html
> 
> 1/ First attempt: start an Erlang node and turn it off immediately:
> 
> $ cerl -valgrind
> [...]
> 
> 1> init:stop().
> 
> [...]
> ==61127==    at 0xC713: malloc (vg_replace_malloc.c:274)
> ==61127==    by 0x1002C25F0: erts_sys_alloc (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==61127==    by 0x10000B6B3: erts_alloc (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==61127==    by 0x10000B5AC: erts_alloc_permanent_cache_aligned (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==61127==    by 0x1001053E7: init_db (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==61127==    by 0x10002884B: erl_init (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==61127==    by 0x10002D273: erl_start (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==61127==    by 0x10000191F: main (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==61127== 
> ==61127== ERROR SUMMARY: 420 errors from 13 contexts (suppressed: 0 from 0)
> 
> 420 errors reported.
> 
> Rickard Green explained why Valgrind reported these (false) numbers at:
> http://erlang.org/pipermail/erlang-questions/2010-February/049591.html
> 
> 
> 2/ Second attempt: simply load "crypto" module and stop it:
> 
> $ cerl -valgrind
> [...]
> 
> 1> crypto:start().
> 2> crypto:stop(). 
> ok
> 3> 
> =INFO REPORT==== 17-Mar-2013::10:18:26 ===
>     application: crypto
>     exited: stopped
>     type: temporar
> 4> init:stop().
> 
> [...]
> ==59400==    at 0xC713: malloc (vg_replace_malloc.c:274)
> ==59400==    by 0x1002C25F0: erts_sys_alloc (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==59400==    by 0x10000B6B3: erts_alloc (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==59400==    by 0x10000B5AC: erts_alloc_permanent_cache_aligned (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==59400==    by 0x1001053E7: init_db (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==59400==    by 0x10002884B: erl_init (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==59400==    by 0x10002D273: erl_start (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==59400==    by 0x10000191F: main (in /opt/r16b/usr/lib/erlang/erts-5.10.1/bin/beam.valgrind.smp)
> ==59400== 
> ==59400== ERROR SUMMARY: 460 errors from 15 contexts (suppressed: 0 from 0)
> 
> Valgrind now reorts 460 errors instead of 420 (see above).
> 
> I know, there's no memory leak in "crypto" ... but this doesn't help at all. Completely useless.
> 
> So, my question is very simple: 
> How Valgrind can help me to track memory leaks in my own NIF/linked-in drivers then?
> How can I distinguish between these falsy reported numbers and the real ones?
> 
> Finally, is there any other way than Valgrind?
> 
> Regards,
> Zabrane
> 
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130318/900e578d/attachment.htm>