Bug 210935 - port valgrind.h (not valgrind) to win32 so apps run under wine can make client requests
Summary: port valgrind.h (not valgrind) to win32 so apps run under wine can make clien...
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-18 05:21 UTC by Dan Kegel
Modified: 2011-03-02 12:46 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Demo showing that current annotations with mingw (3.83 KB, text/plain)
2009-10-18 05:28 UTC, Dan Kegel
Details
updated to use 32 bit opcodes. makes valgrind crash... (3.66 KB, text/x-csrc)
2009-10-18 15:59 UTC, Dan Kegel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Kegel 2009-10-18 05:21:10 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

(This is kind of a continuation of bug 148441, which
was closed prematurely.)

valgrind+wine can indeed already spot leaks in programs
that call the win32 heap directly, but not in programs
which use a higher level heap (e.g. tcmalloc,
jemalloc, hoard, nedmalloc, etc).

To fix this properly, we need to port valgrind.h to win32 
so that client requests can be made from win32 apps. 
The attached demo that shows this works from win32 apps
compiled with gcc, so fixing valgrind.h for that case
shouldn't be hard at all.
Supporting Visual C++ is a bit harder, since its inline
assembly is different.  (The demo tries to support that, 
but I made a mistake somewhere.)
Comment 1 Dan Kegel 2009-10-18 05:28:04 UTC
Created attachment 37643 [details]
Demo showing that current annotations with mingw
Comment 2 Dan Kegel 2009-10-18 15:59:14 UTC
Created attachment 37646 [details]
updated to use 32 bit opcodes.  makes valgrind crash...
Comment 3 Bart Van Assche 2010-08-27 12:03:03 UTC
Should be fixed in r11295. Please test.