can't find memory leak in Wine, win32 binary executabe file. wine 0.9.42 linux x86.
I think we're going to need a little bit more information than that... Are you looking for leaks in wine itself? or in a Windows program being run under wine? What output are you getting from valgrind, and what is wrong about it - in other words what makes you think there is a leak that isn't being reported? If you're looking for leaks in a program being run under wine then what made you think that was possible? Although there were some patches a few years ago to try and make that work it has never (as far as I know) been something that the core valgrind tree has supported.
Windows program being run under wine. I want to use wine+valgrind, check my windows app for memory check. //the following sourcecode has memory leak,but valgrind 3.3.SVN can't check it on wine 0.9.42. #include "string.h" #include "stdlib.h" #include "stdio.h" int main(int argc, char* argv[]) { char *x; x = (char *)malloc(32); printf("Hello World!\n"); return 0; } [xf@trscluster1 drive_c]$ valgrind --tool=memcheck --trace-children=yes --leak-check=full wine testwine.exe ==28480== Memcheck, a memory error detector. ==28480== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==28480== Using LibVEX rev 1775, a library for dynamic binary translation. ==28480== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==28480== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==28480== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==28480== For more details, rerun with: -v ==28480== ==28480== Memcheck, a memory error detector. ==28480== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==28480== Using LibVEX rev 1775, a library for dynamic binary translation. ==28480== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==28480== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==28480== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==28480== For more details, rerun with: -v ==28480== preloader: Warning: failed to reserve range 00000000-60000000 ==28480== Warning: set address range perms: large range 1040056320 (defined) ==28482== Memcheck, a memory error detector. ==28482== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==28482== Using LibVEX rev 1775, a library for dynamic binary translation. ==28482== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==28482== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==28482== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==28482== For more details, rerun with: -v ==28482== ==28482== ==28482== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 2) ==28482== malloc/free: in use at exit: 103 bytes in 3 blocks. ==28482== malloc/free: 50 allocs, 47 frees, 3,762 bytes allocated. ==28482== For counts of detected errors, rerun with: -v ==28482== searching for pointers to 3 not-freed blocks. ==28482== checked 157,396 bytes. ==28482== ==28482== LEAK SUMMARY: ==28482== definitely lost: 0 bytes in 0 blocks. ==28482== possibly lost: 0 bytes in 0 blocks. ==28482== still reachable: 103 bytes in 3 blocks. ==28482== suppressed: 0 bytes in 0 blocks. ==28482== Reachable blocks (those to which a pointer was found) are not shown. ==28482== To see them, rerun with: --leak-check=full --show-reachable=yes ==28480== Invalid read of size 4 ==28480== at 0x40B7D4: ??? ==28480== Address 0x7f22ec90 is not stack'd, malloc'd or (recently) free'd Hello World! ==28480== ==28480== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 31 from 2) ==28480== malloc/free: in use at exit: 118,538 bytes in 135 blocks. ==28480== malloc/free: 304 allocs, 169 frees, 143,723 bytes allocated. ==28480== For counts of detected errors, rerun with: -v ==28480== searching for pointers to 135 not-freed blocks. ==28480== checked 2,094,968 bytes. ==28480== ==28480== ==28480== 46 bytes in 2 blocks are definitely lost in loss record 10 of 24 ==28480== at 0x43CA24C: RtlAllocateHeap (heap.c:181) ==28480== by 0x43DFCDC: RtlCreateUnicodeString (rtlstr.c:277) ==28480== by 0x43CCF6E: alloc_module (loader.c:690) ==28480== by 0x43CF4CC: load_builtin_callback (loader.c:1306) ==28480== by 0x4024FE0: wine_dll_set_callback (loader.c:478) ==28480== by 0x43CCE45: __wine_process_init (loader.c:2480) ==28480== by 0x4025331: wine_init (loader.c:664) ==28480== by 0x7BF011BB: main (main.c:111) ==28480== ==28480== LEAK SUMMARY: ==28480== definitely lost: 46 bytes in 2 blocks. ==28480== possibly lost: 0 bytes in 0 blocks. ==28480== still reachable: 118,492 bytes in 133 blocks. ==28480== suppressed: 0 bytes in 0 blocks. ==28480== Reachable blocks (those to which a pointer was found) are not shown. ==28480== To see them, rerun with: --leak-check=full --show-reachable=yes [xf@trscluster1 drive_c]$ ==28483== ==28483== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 20 from 3) ==28483== malloc/free: in use at exit: 932 bytes in 11 blocks. ==28483== malloc/free: 14,726 allocs, 14,715 frees, 807,281 bytes allocated. ==28483== For counts of detected errors, rerun with: -v ==28483== searching for pointers to 11 not-freed blocks. ==28483== checked 157,780 bytes. ==28483== ==28483== LEAK SUMMARY: ==28483== definitely lost: 0 bytes in 0 blocks. ==28483== possibly lost: 0 bytes in 0 blocks. ==28483== still reachable: 932 bytes in 11 blocks. ==28483== suppressed: 0 bytes in 0 blocks. ==28483== Reachable blocks (those to which a pointer was found) are not shown. ==28483== To see them, rerun with: --leak-check=full --show-reachable=yes
The problem is that when your Windows program calls malloc that is the Windows malloc that winds up allocating memory from the Windows heap that wine is managing. That operation is therefore invisible to valgrind - all it knows is that wine has grabbed a big chunk of memory from the operating system. The fact that wine then splits that up and parcels it out to the Windows programs running under it is not something valgrind knows anything about so it doesn't know that there are blocks which haven't been freed.
http://wiki.winehq.org/Wine_and_Valgrind It says that valgrind can use under valgrind 3.2.3.
http://www.winehq.org/pipermail/wine-patches/2003-March/005774.html But how to use valgrind check memory for windows app? Thanks.
You might want to talk to the wine guys who have been working on making it work with valgrind - they probably know a lot more about this stuff than we do.
but valgrind cant' read *.pdb,...
I'm well aware of the patch in that email - Adam and I work for the same company and were in next door offices at the time!
http://bugs.winehq.org/show_bug.cgi?id=9157 They say valgrind can use some callback..... How to implement these function. HeapAlloc, HeapFree....
Valgrind now reads PDBs, and I think Wine might use Valgrind client requests for malloc/free. So I'm going to be optimistic and mark this one as fixed. Please reopen if that's incorrect.
It would be interesting to see how wine+valgrind does on memcheck's regression tests. You can try building them with a command like make -k CXX=i586-mingw32msvc-g++ check-am EXEEXT=.exe CC=i586-mingw32msvc-gcc AM_CFLAGS="-g" This acutually builds 72 .exe's. I don't know how easy it is to hijack "make regtest" to run things under wine, but running one test by hand seems to show that valgrind+wine should pass some of the tests already: valgrind --trace-children=yes --workaround-gcc296-bugs=yes -q wine badfree.exe produces exactly the two errors expected in badfree.stderr.exp. Note: anyone trying this should use a clean ~/.wine directory, and should keep some wine app (e.g. winemine) running outside of valgrind so wine's service startup doesn't have to run under valgrind, which would be quite slow.