For all you developers out there who haven't tried valgrinding WINE yet (it's fun - honest!) there is now a pre-patched tarball of the latest valgrind 1.9.6 for WINE available from the valgrind website:
http://developer.kde.org/~sewardj/
no patching needed to WINE or valgrind. Just get the latest snapshot of WINE (or a CVS checkout), build for debugging, get the pre-patched valgrind and use it!
there are still plenty of bugs in WINE which need fixing - most are simple 1 line edits..
Seeya, Adam -- 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.
On May 12, 2003 05:54 am, Adam Gundy wrote:
For all you developers out there who haven't tried valgrinding WINE yet (it's fun - honest!) there is now a pre-patched tarball of the latest valgrind 1.9.6 for WINE available from the valgrind website:
Nice! Will this be merged into the mainline Valgrind? Any particular reason it's delivered as a variant?
At 23:05 12/05/2003 -0400, Dimitrie O. Paun wrote:
On May 12, 2003 05:54 am, Adam Gundy wrote:
For all you developers out there who haven't tried valgrinding WINE yet (it's fun - honest!) there is now a pre-patched tarball of the latest valgrind 1.9.6 for WINE available from the valgrind website:
Nice! Will this be merged into the mainline Valgrind? Any particular reason it's delivered as a variant?
the main reason it is currently a variant instead of part of the normal distribution is stability - ie it hasn't been tested enough. It's not fair to break valgrind for all the people who aren't using WINE...
if we can get some of the WINE developers to use it a bit (hint hint) then we can sort out any bugs and hopefully get a full merge into valgrind.
I suspect what will actually happen is that the generic parts of the patch will get merged into the main valgrind tree first, then the WINE specific stuff will be a no-brainer at some point.
Seeya, Adam -- 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.
if we can get some of the WINE developers to use it a bit (hint hint) then we can sort out any bugs and hopefully get a full merge into valgrind.
To whom should we report bugs :-) ?
On my box (a hopelessly out of date one with glibc2.1.3), I get this :
$ valgrind `which wine` ==221== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==221== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==221== Using valgrind-1.9.6-wine, a program instrumentation system for x86-linux. ==221== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==221== Estimated CPU clock rate is 334 MHz ==221== For more details, rerun with: -v ==221== ==221== Warning: segment-override prefix encountered, but thread has no LDT ==221== Warning: segment access: virtual addr 24 exceeds segment limit of 0 ==221== Invalid read of size 4 ==221== at 0x4029FCC4: __pthread_getspecific (../../include/winnt.h:1619) ==221== by 0x403035DF: dlopen_dll (loader.c:156) ==221== by 0x40303E02: wine_init (loader.c:427) ==221== by 0x3C000612: main (main.c:32) ==221== Address 0x18 is not stack'd, malloc'd or free'd Segmentation fault
I already fixed a long time ago some bugs in Valgrind, but well, this only happens in the Wine case (I tested some small shell tools and they seem to work properly).
Lionel
At 19:31 13/05/2003 +0200, Lionel Ulmer wrote:
if we can get some of the WINE developers to use it a bit (hint hint) then we can sort out any bugs and hopefully get a full merge into valgrind.
To whom should we report bugs :-) ?
On my box (a hopelessly out of date one with glibc2.1.3), I get this :
$ valgrind `which wine` ==221== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==221== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==221== Using valgrind-1.9.6-wine, a program instrumentation system for x86-linux. ==221== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==221== Estimated CPU clock rate is 334 MHz ==221== For more details, rerun with: -v ==221== ==221== Warning: segment-override prefix encountered, but thread has no LDT ==221== Warning: segment access: virtual addr 24 exceeds segment limit of 0 ==221== Invalid read of size 4 ==221== at 0x4029FCC4: __pthread_getspecific (../../include/winnt.h:1619) ==221== by 0x403035DF: dlopen_dll (loader.c:156) ==221== by 0x40303E02: wine_init (loader.c:427) ==221== by 0x3C000612: main (main.c:32) ==221== Address 0x18 is not stack'd, malloc'd or free'd Segmentation fault
can you send me an strace of this ("strace wine" NOT "strace valgrind wine") - don't post it to the list though ;-)
from a quick session with GDB this looks like WINE bug - it looks like dlopen() or maybe dlerror() is calling WINE's version of __pthread_getspecific() which uses NTCurrentTeb() before we have set up the TEB area.
On my RedHat 7.3 and 8.0 boxes it looks like glibc is calling the modify_ldt() system call before main(), which explains why valgrind is OK...
Seeya, Adam -- 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.
At 19:31 13/05/2003 +0200, Lionel Ulmer wrote:
if we can get some of the WINE developers to use it a bit (hint hint) then we can sort out any bugs and hopefully get a full merge into valgrind.
To whom should we report bugs :-) ?
On my box (a hopelessly out of date one with glibc2.1.3), I get this :
$ valgrind `which wine` ==221== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==221== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==221== Using valgrind-1.9.6-wine, a program instrumentation system for x86-linux. ==221== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==221== Estimated CPU clock rate is 334 MHz ==221== For more details, rerun with: -v ==221== ==221== Warning: segment-override prefix encountered, but thread has no LDT ==221== Warning: segment access: virtual addr 24 exceeds segment limit of 0 ==221== Invalid read of size 4 ==221== at 0x4029FCC4: __pthread_getspecific (../../include/winnt.h:1619) ==221== by 0x403035DF: dlopen_dll (loader.c:156) ==221== by 0x40303E02: wine_init (loader.c:427) ==221== by 0x3C000612: main (main.c:32) ==221== Address 0x18 is not stack'd, malloc'd or free'd Segmentation fault
just an update about this since it fell off list - it appears that Lionel has a buggy (or maybe just old) dynamic linker which doesn't support "-z initfirst" (which valgrind relies on).
so to sum up, there's nothing wrong with valgrind or WINE, but you may need a glibc newer than 2.1.3 for success...
Seeya, Adam -- 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.
-
Adam Gundy -
Dimitrie O. Paun -
Lionel Ulmer