valgrind for WINE
arg at cyberscience.com
Wed Apr 2 07:55:21 CST 2003
At 19:45 01/04/03 -0600, Eric Pouech <pouech-eric at wanadoo.fr> wrote:
>Adam Gundy wrote:
>> a new version of the valgrind patch has been uploaded to sourceforge -
>> the only change is a small fix to the signal handling which should
>> prevent "signal handler frame" uninitialized errors.
>> comments? bug reports? success stories?
>did test it yet.
>As a global note, I think it would be appreciated breaking the patch in
>smaller bits... it makes it easier to track/follow what happens. For
>example, I don't see any reason for including the msvcrtd patches into
the reason msvcrtd is there is that you need to use it for valgrind to do
any checking of the heap - an instrumented malloc (see the changes to ntdll/heap.c)
is required to tell valgrind that freshly allocated blocks are uninitialized,
and the freed blocks are now invalid.
If you build a debug executable using MSVC you have to use MSVCRTD.DLL, hence
the new spec file for msvcrtd.dll.so
>I think that Alexandre is currently integrating (bit per bit) your
>changes into wine. look for the patch about zeroing the request zones
>(which is another implementation of your structure packing), as well as
>local availability of the thread PID
haven't seen these yet
>on a more minor side of things, I would keep the VALGRIND prefix in heap.c
not sure what you mean here, but the heap.c stuff appears to have been committed
(slightly rewritten by the look of it...). To be of ANY use you need the MSVCRTD
stuff as well though!
>last point, using the .vg extension to the wine script may not be
>optimal. it won't work (as it is written) for winelib programs (which
>got started also thru the wine script)
>one solution would be (to follow your idea) to link (for a winelib app
>called foo) foo.vg to script wine (and change your rule something like
>*.vg|*/*.vg). another option would be to embed this support as an option
>to the wine script (like --valgrind)
maybe, this was just a hack to make it easier to use "in tree". not sure people
would want a "--valgrind" switch in a (presumably) production winelib piece of
software - it would show the world all your bugs ;-)
>how are your patches doing on the "other side" (I mean valgrind's) ?
just starting to make progress into CVS commits - there appear to be several other
patches which overlap with mine, so there will probably be some ordering and
Real Programmers don't comment their code. If it was hard to write,
it should be hard to read, and even harder to modify.
These are all my own opinions.
More information about the wine-devel