Lack of information using mono with valgrind

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Lack of information using mono with valgrind

Pierre-Louis PREVOST
Dear community members,

I try investigating memory leaks on a program that I wrote in C# which is executed under mono 4.2.4.
To reach that aim:
- I downloaded the valgrind sources (version 3.12) from valgrind.org and successfully compiled & installed it on my platform which is running under OS Linux x86.
- I compiled my C# program using xbuild and "DebugSymbols" property set to true
- I launched the executable using the following commands:

export G_SLICE=always-malloc
export G_DEBUG=gc-friendly
valgrind --tool=memcheck -v --leak-check=full --show-leak-kinds=all --log-file=log.${PID} --smc-check=all --suppressions=mono.supp --main-stacksize=1250000000 mono --debug --runtime=v4.0 --config myProgram.exe.config myProgram.exe

Now I expect to see some valgrind reports in the log file indicating me what function(s) from the source leaks and how much.
But instead of that, I only see memory leaks from mono and not further. It looks like mono is filtering the information from the applicative and only gives me insufficiant details in terms of granularity.

For instance, I get this stack from valgrind:

==30182== Use of uninitialised value of size 4
==30182== at 0x825FC15: GC_base (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825D431: GC_mark_and_push_stack (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825D5A4: GC_push_all_eager (in /opt/myPath/bin/mono-boehm)
==30182== by 0x8265E16: GC_push_all_stacks (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825ED21: GC_mark_some (in /opt/myPath/bin/mono-boehm)
==30182== by 0x8258017: GC_stopped_mark (in /opt/myPath/bin/mono-boehm)
==30182== by 0x8258416: GC_try_to_collect_inner (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825871B: GC_collect_or_expand (in /opt/myPath/bin/mono-boehm)
==30182== by 0x8258BAF: GC_allocobj (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825BDC5: GC_generic_malloc_inner (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825BE79: GC_generic_malloc (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825C07A: GC_malloc (in /opt/myPath/bin/mono-boehm)

This basically tells me that mono uses (4 bytes ??) of uninitialised value right?
Shall I conclude that mono is leaking? (which I doubt). Or shall I conclude that my program is leaking but mono cannot tell me which namespace/function is leaking? (which I most likely presume).
Do I use the right options of valgrind? If not, what should I use instead?
Do I have to recompile valgrind using mcs? If it's the case how?

Thank you in advance,
Pierre.

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Lack of information using mono with valgrind

Rafael Teixeira
Sorry, Pierre, but you are misunderstanding completely what mono is: it is a runtime environment for code expressed in a virtual machine's bytecode, that is compiled on the fly (most of time) to native code, without any possible direct translation of source symbols in the original C# code compiled to bytecodes to the native code it is generating, specially if compiled for release and with optimizations enabled.

You can use the mono debug to try to follow your logic step by step and see if you can pinpoint the problem, you can even debug from inside the MonoDevelop IDE, which is normally easier to deal than the console-base debugger.

Also I remember people discussing using valgrind with mono, but normally to find problems inside mono itself, not in managed programs. Maybe when precompiling the bytecode to native code (using aot) it may be possible to have some tool map the C# source code to the generated code but I don't if such mapping tool exists... Anyway some guidance is found at http://www.mono-project.com/docs/debug+profile/debug/#using-valgrind-on-mono (see the rest of that page for more info on debugging your code)

Valgrind is written in C, and can't be compiled with mcs.

As it seems that your program is pure C#, there are only two ways to leak memory: bugs in mono itself, or the program is not freeing resources that allocate in the native side of things (like forgetting to close/free open files, network channels, etc..)

Also it is important to note that managed programs written in C# (and other languages) have their memory management automated by a garbage collector (the GC_ functions in yours valgring stack are part of it), so a dedicated thread tries to free memory in the background, but if you have tight loops allocating lots of new objects it may pile up and the background GC thread may not be able to free the memory as fast as needed so you'll see memory consumption rise steeply and maybe even causing the program to abort saying there is no more memory. Also allocating objects in the global scope (static fields) make them be kept in memory during all the execution of the program, never freeing the memory they use.

Hope it helps,

Rafael Teixeira
O..:.)oooo

On Tue, Jun 6, 2017 at 5:32 PM, Pierre-Louis PREVOST <[hidden email]> wrote:
Dear community members,

I try investigating memory leaks on a program that I wrote in C# which is executed under mono 4.2.4.
To reach that aim:
- I downloaded the valgrind sources (version 3.12) from valgrind.org and successfully compiled & installed it on my platform which is running under OS Linux x86.
- I compiled my C# program using xbuild and "DebugSymbols" property set to true
- I launched the executable using the following commands:

export G_SLICE=always-malloc
export G_DEBUG=gc-friendly
valgrind --tool=memcheck -v --leak-check=full --show-leak-kinds=all --log-file=log.${PID} --smc-check=all --suppressions=mono.supp --main-stacksize=1250000000 mono --debug --runtime=v4.0 --config myProgram.exe.config myProgram.exe

Now I expect to see some valgrind reports in the log file indicating me what function(s) from the source leaks and how much.
But instead of that, I only see memory leaks from mono and not further. It looks like mono is filtering the information from the applicative and only gives me insufficiant details in terms of granularity.

For instance, I get this stack from valgrind:

==30182== Use of uninitialised value of size 4
==30182== at 0x825FC15: GC_base (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825D431: GC_mark_and_push_stack (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825D5A4: GC_push_all_eager (in /opt/myPath/bin/mono-boehm)
==30182== by 0x8265E16: GC_push_all_stacks (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825ED21: GC_mark_some (in /opt/myPath/bin/mono-boehm)
==30182== by 0x8258017: GC_stopped_mark (in /opt/myPath/bin/mono-boehm)
==30182== by 0x8258416: GC_try_to_collect_inner (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825871B: GC_collect_or_expand (in /opt/myPath/bin/mono-boehm)
==30182== by 0x8258BAF: GC_allocobj (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825BDC5: GC_generic_malloc_inner (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825BE79: GC_generic_malloc (in /opt/myPath/bin/mono-boehm)
==30182== by 0x825C07A: GC_malloc (in /opt/myPath/bin/mono-boehm)

This basically tells me that mono uses (4 bytes ??) of uninitialised value right?
Shall I conclude that mono is leaking? (which I doubt). Or shall I conclude that my program is leaking but mono cannot tell me which namespace/function is leaking? (which I most likely presume).
Do I use the right options of valgrind? If not, what should I use instead?
Do I have to recompile valgrind using mcs? If it's the case how?

Thank you in advance,
Pierre.

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list



_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Loading...