Valgrind for WINE tarball now available
arg at cyberscience.com
Wed May 14 05:39:06 CDT 2003
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== 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
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...
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