|
From: chenping19850429 <che...@16...> - 2009-04-13 09:09:16
|
Hi all,
I want to instrument the .NET program. I find Valgrind can only run in Linux.
Anyone knows if there any Valgrind like tool on Windows, which can instrument the .NET program?
Thanks.
Ping Chen
|
|
From: Bart V. A. <bar...@gm...> - 2009-04-13 09:21:40
|
2009/4/13 chenping19850429 <che...@16...>: > I want to instrument the .NET program. I find Valgrind can only run in > Linux. > Anyone knows if there any Valgrind like tool on Windows, which can > instrument the .NET program? It has already been considered to port Valgrind to Windows, but as far as I know nobody is working on a port of Valgrind for Windows. Have you already considered to run your .NET program under Mono on a Linux system ? Bart. |
|
From: Tor L. <tm...@ik...> - 2009-04-13 09:46:08
|
> It has already been considered to port Valgrind to Windows, but as far > as I know nobody is working on a port of Valgrind for Windows. I am, "in my copious spare time" (well, the ongoing Easter holidays has offered some nice hacking time, with the wife having to work and the daughter visiting her cousin;). It's not at the stage yet where it would be useful to offer diffs so interested parties could help the effort, sorry, as there will presumably be much rework of design decisions from scratch, or maybe I'll even end up abandoning up the attempt. But it compiles (with lots of stuff ifdeffed out, of course), and in some months or a year, I might have something vaguely useful. --tml |
|
From: Tor L. <tm...@ik...> - 2009-04-13 09:35:02
|
> I want to instrument the .NET program. What do you mean with "the" .NET program? The Microsoft .NET Framework CLR implementation, i.e. their virtual machine that runs .NET programs? Or just *a* .NET program, i.e. presumably some C# (or other .NET language) code you have written yourself? I assume that is what you mean. In a managed environment with garbage collection, I can't really see much need for a tool like memcheck, for instance, as there by definition can be no buffer overruns, no access to "freed" memory, and no undefined memory. That doesn't mean that instrumentation wouldn't be useful for other kinds of tools, like tracking large objects that references are kept to but never used, i.e. effectively "leaks". > Anyone knows if there any Valgrind like tool on Windows, which can > instrument the .NET program? Try googling for relevant keywords like "instrumenting", "managed", ".net", "assemblies." You are not likely to see many experts in this area on this list I think.. As such, instrumenting .net assemblies is probably rather easy, given that it is well-documented virtual machine bytecode (CIL) that one would be instrumenting, and there (presumably) are nice class libraries built in that can be used to load the CIL from assemblies, modify that CIL, construct new assemblies dynamically, etc. (My terminology is probably off here, sorry.) I assume a tool that does such instrumentation would be platform-independent unless written carelessly, i.e. it could be used as well on Windows (running under the MS .NET Framework), or on some Unix running under Mono. It would have very little in common with what Valgrind does, except from a very high-level executive summary point of view. --tml |
|
From: chenping19850429 <che...@16...> - 2009-04-13 11:10:12
|
Thanks for your help, I think program running under Windows (such as .NET program) often need to be tainted for further program analysis or bug detection. Unfortunately, I find little binary-level instrumented tools which can achieves the goal. Is there anybody knows it? BTW, CIL is a very efficient and robust tools for instrumenting the program with source code available. But it seems that it can not instrument the binary code, right? Thanks. Ping Chen 在2009-04-13,"Tor Lillqvist" <tm...@ik...> 写道: >> ??? I want to instrument the .NET program. > >What do you mean with "the" .NET program? The Microsoft .NET Framework >CLR implementation, i.e. their virtual machine that runs .NET >programs? > >Or just *a* .NET program, i.e. presumably some C# (or other .NET >language) code you have written yourself? I assume that is what you >mean. > >In a managed environment with garbage collection, I can't really see >much need for a tool like memcheck, for instance, as there by >definition can be no buffer overruns, no access to "freed" memory, and >no undefined memory. That doesn't mean that instrumentation wouldn't >be useful for other kinds of tools, like tracking large objects that >references are kept to but never used, i.e. effectively "leaks". > >> Anyone knows if there any Valgrind like tool on Windows, which can >> instrument the .NET program? > >Try googling for relevant keywords like "instrumenting", "managed", >".net", "assemblies." You are not likely to see many experts in this >area on this list I think.. > >As such, instrumenting .net assemblies is probably rather easy, given >that it is well-documented virtual machine bytecode (CIL) that one >would be instrumenting, and there (presumably) are nice class >libraries built in that can be used to load the CIL from assemblies, >modify that CIL, construct new assemblies dynamically, etc. (My >terminology is probably off here, sorry.) > >I assume a tool that does such instrumentation would be >platform-independent unless written carelessly, i.e. it could be used >as well on Windows (running under the MS .NET Framework), or on some >Unix running under Mono. It would have very little in common with what >Valgrind does, except from a very high-level executive summary point >of view. > >--tml |
|
From: Tor L. <tm...@ik...> - 2009-04-13 11:31:30
|
> Thanks for your help, I think program running under Windows (such as .NET > program) often need to be tainted for further program analysis or bug > detection. I think you are misguided here when generalizing .NET applications and traditional Windows applications. After all, .NET applications (as long as we are talking about ones that contain only managed code and not tons of unsafe (native) code) are safe, by definition, from many types of errors. Just like Java code. > Unfortunately, I find little binary-level instrumented tools > which can achieves the goal. Is there anybody knows it? BoundsChecker, Purify, etc. There are lots of tools. They cost money, though, but many of them are worth their price. (And many, presumably, nowadays also support .NET, although surely internally the mechanisms they use for that are very different from the ones used for traditional machine code). > BTW, CIL is a very efficient and robust tools for instrumenting the program > with source code available. Huh? CIL is not a tool, it means "Common Intermediate Language", i.e. it is the "bytecode" that managed .NET assemblies consist of. (Apparently the term "CIL" can mean either the actual binary bytecode, or its (one-to-one) "human-readable" textual representation, which I find a bit confusing. Or maybe I misunderstand something.) > But it seems that it can not instrument the binary code, right? What "it"? And what "binary code", the .NET CIL "bytecode" or x86 machine code? Obviously very different tools are used to manipulate CIL and machine code. To inspect and instrument CIL code one would most naturally write such a tool in .NET itself and use functionality provided by classes in the System.Reflection and System.Reflection.Emit namespaces. To instrument machine code, something like Valgrind, Purify, Dynamo/RIO etc would be used. --tml |
|
From: Bart V. A. <bar...@gm...> - 2009-04-13 11:37:06
|
2009/4/13 chenping19850429 <che...@16...>: > I want to instrument the .NET program. I find Valgrind can only run in > Linux. > Anyone knows if there any Valgrind like tool on Windows, which can > instrument the .NET program? It would help if you could tell us why you want to instrument .NET programs at the binary level, Do you want to analyze .NET programs with one of the existing Valgrind tools, or do you want to develop a new Valgrind tool yourself ? Bart. |
|
From: Konstantin S. <kon...@gm...> - 2009-04-13 12:06:43
|
On Mon, Apr 13, 2009 at 3:31 PM, Tor Lillqvist <tm...@ik...> wrote: >> Thanks for your help, I think program running under Windows (such as .NET >> program) often need to be tainted for further program analysis or bug >> detection. > > I think you are misguided here when generalizing .NET applications and > traditional Windows applications. After all, .NET applications (as > long as we are talking about ones that contain only managed code and > not tons of unsafe (native) code) are safe, by definition, from many > types of errors. Just like Java code. > >> Unfortunately, I find little binary-level instrumented tools >> which can achieves the goal. Is there anybody knows it? > > BoundsChecker, Purify, etc. Add http://software.intel.com/en-us/intel-parallel-studio-home/ to this list. A PIN-based hybrid of Memcheck and Helgrind, works on windows. Beta is free. --kcc > There are lots of tools. They cost money, > though, but many of them are worth their price. (And many, presumably, > nowadays also support .NET, although surely internally the mechanisms > they use for that are very different from the ones used for > traditional machine code). > >> BTW, CIL is a very efficient and robust tools for instrumenting the program >> with source code available. > > Huh? CIL is not a tool, it means "Common Intermediate Language", i.e. > it is the "bytecode" that managed .NET assemblies consist of. > (Apparently the term "CIL" can mean either the actual binary bytecode, > or its (one-to-one) "human-readable" textual representation, which I > find a bit confusing. Or maybe I misunderstand something.) > >> But it seems that it can not instrument the binary code, right? > > What "it"? And what "binary code", the .NET CIL "bytecode" or x86 machine code? > > Obviously very different tools are used to manipulate CIL and machine > code. To inspect and instrument CIL code one would most naturally > write such a tool in .NET itself and use functionality provided by > classes in the System.Reflection and System.Reflection.Emit > namespaces. To instrument machine code, something like Valgrind, > Purify, Dynamo/RIO etc would be used. > > --tml > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Tor L. <tm...@ik...> - 2009-04-13 13:44:38
|
> Beta is free. The first hit is free. That is a well-known and successful business model! --tml |
|
From: Nicholas N. <n.n...@gm...> - 2009-04-13 22:14:40
|
On Mon, Apr 13, 2009 at 10:06 PM, Konstantin Serebryany > > Add http://software.intel.com/en-us/intel-parallel-studio-home/ to this list. > A PIN-based hybrid of Memcheck and Helgrind, works on windows. Beta is free. On the Memcheck side, it looks like it's just a leak detector. Nick |
|
From: Konstantin S. <kon...@gm...> - 2009-04-14 04:33:05
|
On Tue, Apr 14, 2009 at 2:14 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Mon, Apr 13, 2009 at 10:06 PM, Konstantin Serebryany > >> Add http://software.intel.com/en-us/intel-parallel-studio-home/ to this list. >> A PIN-based hybrid of Memcheck and Helgrind, works on windows. Beta is free. > > On the Memcheck side, it looks like it's just a leak detector. Not only. We tried it on windows. It detects uninitialized accesses as well. Probably, the rest too. --kcc > > Nick > |
|
From: Bart V. A. <bar...@gm...> - 2009-04-14 09:11:18
|
On Tue, Apr 14, 2009 at 12:14 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Mon, Apr 13, 2009 at 10:06 PM, Konstantin Serebryany > >> Add http://software.intel.com/en-us/intel-parallel-studio-home/ to this list. >> A PIN-based hybrid of Memcheck and Helgrind, works on windows. Beta is free. > > On the Memcheck side, it looks like it's just a leak detector. When starting Intel's Parallel Inspector, one must choose between memory checking and thread checking. For memory checking, there is a choice between four different levels: * memory leak detection only. * memory access checking with call stack depth limit 1. * memory access checking with call stack depth limit 12. * enable all checks supported by the tool. My experience with beta 2 of Intel's Parallel Inspector is that it is considerably slower than Purify or BoundsChecker, and that it reports too much false positive reads of uninitialized variables (about hundred for a program where Purify reported zero occurrences). This tool e.g. already complains when copying a struct that contains uninitialized padding bytes. Bart. |