A new tarball of valgrind modified to work with WINE is available from the valgrind home page:
http://developer.kde.org/~sewardj/ http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2
this is based on the latest stable valgrind release.
use a current CVS or the latest snapshot of WINE.
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 October 29, 2003 08:44 am, Adam Gundy wrote:
A new tarball of valgrind modified to work with WINE is available from the valgrind home page:
http://developer.kde.org/~sewardj/ http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2
this is based on the latest stable valgrind release.
Any chance this will be merge into mainline valgrind?
At 23:26 29/10/2003 -0500, Dimitrie O. Paun wrote:
On October 29, 2003 08:44 am, Adam Gundy wrote:
A new tarball of valgrind modified to work with WINE is available from the valgrind home page:
http://developer.kde.org/~sewardj/ http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2
this is based on the latest stable valgrind release.
Any chance this will be merge into mainline valgrind?
that looks unlikely at the moment :-(
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 October 31, 2003 05:38 am, Adam Gundy wrote:
that looks unlikely at the moment :-(
Darn. Even if we have to provide a switch (like --wine) to valgrind? That would be so much better than a different binary. What's the problem, BTW?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Adam
A new tarball of valgrind modified to work with WINE is available from the valgrind home page:
http://developer.kde.org/~sewardj/ http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2
this is based on the latest stable valgrind release.
use a current CVS or the latest snapshot of WINE.
Seeya, Adam
Trying to run valgrind on wine directx (running Unreal2 with nvidia openGL drivers)
- -> valgrind --workaround-gcc296-bugs=yes wine -- Unreal2.exe
<snip> ==13022== Conditional jump or move depends on uninitialised value(s) ==13022== at 0x40008BCA: _dl_relocate_object_internal (do-rel.h:117) ==13022== by 0x4038244E: (within /lib/i686/libc-2.3.2.so) ==13022== by 0x4000ABD7: _dl_catch_error_internal (dl-error.c:162) ==13022== by 0x4038212D: _dl_open (in /lib/i686/libc-2.3.2.so) ==13022== Warning: noted but unhandled ioctl 0x30B with no size/direction hints ==13022== This could cause spurious value errors to appear. ==13022== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. <snip> ==13022== ==13022== Conditional jump or move depends on uninitialised value(s) ==13022== at 0x4000F6E9: strlen (strlen.S:112) ==13022== by 0x40382223: _dl_open (in /lib/i686/libc-2.3.2.so) ==13022== by 0x403A8000: (within /lib/libdl-2.3.2.so) ==13022== by 0x4000ABD7: _dl_catch_error_internal (dl-error.c:162) ==13022== discard syms in /etc/ld.so.cache due to munmap() ==13022== valgrind's libpthread.so: UNIMPLEMENTED FUNCTION: pthread_attr_setstack ==13022==
after it exit :( How to get it working ?
Regards, Raphael
Trying to run valgrind on wine directx (running Unreal2 with nvidia openGL drivers)
I think it's best to use software GL when using Valgrind... It is reported to make the DRI crash and not support all syscalls needed by the NVIDIA GL drivers.
Anyway, I have a different issue :
valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion (seg_selector & 7) == 7' failed.
Lionel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le Monday 03 November 2003 23:06, Lionel Ulmer a écrit :
Trying to run valgrind on wine directx (running Unreal2 with nvidia openGL drivers)
I think it's best to use software GL when using Valgrind... It is reported to make the DRI crash and not support all syscalls needed by the NVIDIA GL drivers.
well it seems NTPL-related (only one real reference of pthread_attr_setstack, in ntdll):
int SYSDEPS_SpawnThread( void (*func)(TEB *), TEB *teb ) { #ifdef HAVE_NPTL pthread_t id; pthread_attr_t attr;
pthread_attr_init( &attr ); pthread_attr_setstack( &attr, teb->DeallocationStack, (char *)teb->Tib.StackBase - (char *)teb->DeallocationStack ); if (pthread_create( &id, &attr, (void * (*)(void *))func, teb )) return - -1; return 0; #elif defined(HAVE_CLONE) <snip>
Implementing it into valgrind is difficult ?
Anyway, I have a different issue :
valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion (seg_selector & 7) == 7' failed.
strange, valgrind love wine :p
Lionel
Regards, Raphael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi again,
With my little patch, valgrind/NTPL wine works like a charm (even with unreal2 and after too many errors) :)
Now going to sleep
Regards, Raphael
Le Monday 03 November 2003 23:14, Raphaël Junqueira a écrit :
Le Monday 03 November 2003 23:06, Lionel Ulmer a écrit :
Trying to run valgrind on wine directx (running Unreal2 with nvidia openGL drivers)
I think it's best to use software GL when using Valgrind... It is reported to make the DRI crash and not support all syscalls needed by the NVIDIA GL drivers.
well it seems NTPL-related (only one real reference of pthread_attr_setstack, in ntdll):
int SYSDEPS_SpawnThread( void (*func)(TEB *), TEB *teb ) { #ifdef HAVE_NPTL pthread_t id; pthread_attr_t attr;
pthread_attr_init( &attr ); pthread_attr_setstack( &attr, teb->DeallocationStack, (char *)teb->Tib.StackBase - (char*)teb->DeallocationStack ); if (pthread_create( &id, &attr, (void * (*)(void *))func, teb )) return -1; return 0; #elif defined(HAVE_CLONE)
<snip>
Implementing it into valgrind is difficult ?
Anyway, I have a different issue :
valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion (seg_selector & 7) == 7' failed.
strange, valgrind love wine :p
LionelRegards, Raphael
At 23:06 03/11/2003 +0100, Lionel Ulmer wrote:
Trying to run valgrind on wine directx (running Unreal2 with nvidia openGL drivers)
I think it's best to use software GL when using Valgrind... It is reported to make the DRI crash and not support all syscalls needed by the NVIDIA GL drivers.
Anyway, I have a different issue :
valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion (seg_selector & 7) == 7' failed.
that looks like an incorrect or corrupt segment selector (thread local storage).
one possibility is that it is trying to use the GDT instead of the LDT - are you using WINE with NPTL? try it with NPTL disabled if you are...
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 Tue, Nov 04, 2003 at 10:57:07AM +0000, Adam Gundy wrote:
that looks like an incorrect or corrupt segment selector (thread local storage).
one possibility is that it is trying to use the GDT instead of the LDT - are you using WINE with NPTL? try it with NPTL disabled if you are...
I am using Wine without NPTL support on a glibc-2.3.2 system but with a stock 2.4 kernel.
Wine works just fine, it's only Wine + Valgrind that fails.
Lionel
At 13:37 04/11/2003 +0100, Lionel Ulmer wrote:
On Tue, Nov 04, 2003 at 10:57:07AM +0000, Adam Gundy wrote:
that looks like an incorrect or corrupt segment selector (thread local storage).
one possibility is that it is trying to use the GDT instead of the LDT - are you using WINE with NPTL? try it with NPTL disabled if you are...
I am using Wine without NPTL support on a glibc-2.3.2 system but with a stock 2.4 kernel.
Wine works just fine, it's only Wine + Valgrind that fails.
sorry for the long delay, very busy at the moment.
can you try setting the environment variable:
LD_ASSUME_KERNEL=2.2.5
before running valgrind - it really doesn't like NPTL. In theory the 'valgrind' shell script should be doing this if you have NPTL, but it may not be detecting things correctly...
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.
can you try setting the environment variable:
LD_ASSUME_KERNEL=2.2.5
Well, when I set this up, none of any of my applications work at all :
$ ls ls: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
Without this set, it works perfectly.
Lionel
-
Adam Gundy -
Dimitrie O. Paun -
Lionel Ulmer -
Raphaël Junqueira