Re: [Valgrind-users] Valgrind for Windows update

[Christoph S. <chr...@gm...>]

On 13/08/2012 2:54 PM, Julian Seward wrote:
>
> Hi Christoph,
>
> Thanks for the update.  It's great to hear this is being worked on.
Hi Julian, nice to hear from you. I've been working on this project for 
about a year now, and I am 100% sure that there can be a working 
Valgrind for Windows one day. There are no unsolvable problems, it's 
only a matter of effort. However my time is limited so the reason for 
posting is to raise awareness about this project and hopefully attract 
more developers.

>> Simple applications can be run, compiled with MSVC or GCC, even GUI ones
>> ("MessageBox"). Memory errors (buffer overruns, uninitialized memory,
>> memory leaks) are detected for 32 bit apps. The instrumentation, system
>> calls -including callbacks from system calls-, function redirection,
>> work in principle.
>>
>> The biggest issues right now are stability and making progress in the
>> following areas:
>> 1. debug information parsing, especially PDB, especially 64 bit
>> 2. stack walking, both 32 and 64 bit
>> 3. function redirection on 64 bit (32 bit seems to work)
>
> How well does it run GUI apps with --tool=none?  I ask because 'none'
> does not require any debuginfor reading to work, and so it is a good test
> for how well your basic control-flow, memory management, etc, stuff works.
--tool=none works much better than --tool=memcheck. I basically test 
with a simple "MessageBox" test program. I got the box pop up on Win32 
and Win64 but not under Wow64. I can drag the box around and close it by 
clicking the button.
I also tried to run Windows calculator. On Win32, the calculator 
displays and I can open the menu bar. However, if I click any menu item 
or button, the program stops abruptly.
Win64 calculator stopped because of a misaligned memory access before 
displaying its window.
I have not looked into those issues as my focus is on non-GUI applications.

>
> What are the problems with stack walking?
Basically incomplete call stacks (displaying only one frame) or 
incorrect location information. I filed several tickets on V4Ws tracker 
describing the issues in detail.
The current implementation uses dbghelp's StackWalk function, however I 
would prefer a solution that does not rely on this DLL but rather uses 
its own implementation, like Linux.

Chris