|
From: Nicholas N. <nj...@cs...> - 2005-06-30 00:30:59
|
Hi, For those of you who don't know: the AMD64/Linux development version of Valgrind is working pretty well these days. Hopefully we'll be able to do a release soon. In the meantime, if you want to try it out, follow the instructions for checking the code out of the repository at: http://www.valgrind.org/devel/cvs_svn.html It would be useful to have some more people using it to help iron out remaining bugs. Thanks. Nick |
|
From: Olly B. <ol...@su...> - 2005-06-30 01:08:04
|
On 2005-06-30, Nicholas Nethercote <nj...@cs...> wrote:
> It would be useful to have some more people using it to help iron out
> remaining bugs. Thanks.
I get this failure multiple times with some programs while others run fine:
lt-btreetest: ../nptl/sysdeps/unix/sysv/linux/fork.c:132: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (((size_t) &((struct pthread *)0)->tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (((size_t) &((struct pthread *)0)->tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (((size_t) &((struct pthread *)0)->tid))); } __value; }) != ppid' failed.
According to strace the program doesn't call fork when run normally (not under
valgrind).
The program uses valgrind client requests, and is written in C++. Nothing
particularly unusual about it otherwise. I'm running Ubuntu Linux 5.04
(kernel 2.6.10).
In the (probably likely) event that you need more information, let me know
what.
Or you can download the code yourself to try if you wish - it's the Xapian
search engine library:
http://www.xapian.org/download.php
Download "xapian-core", untar and:
cd xapian-core-0.9.1
./configure
make
cd tests
./runtest ./btreetest
(runtest is just a wrapper shell script to encapsulate the runes required to
run valgrind "through" libtool).
The valgrind client requests are in testsuite/testsuite.cc (from the top
level).
Cheers,
Olly
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 21:32:25
|
On Thu, 30 Jun 2005, Olly Betts wrote:
> On 2005-06-30, Nicholas Nethercote <nj...@cs...> wrote:
>> It would be useful to have some more people using it to help iron out
>> remaining bugs. Thanks.
>
> I get this failure multiple times with some programs while others run fine:
>
> lt-btreetest: ../nptl/sysdeps/unix/sysv/linux/fork.c:132: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (((size_t) &((struct pthread *)0)->tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (((size_t) &((struct pthread *)0)->tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (((size_t) &((struct pthread *)0)->tid))); } __value; }) != ppid' failed.
This is now logged as bug report #109358.
N
> According to strace the program doesn't call fork when run normally (not under
> valgrind).
>
> The program uses valgrind client requests, and is written in C++. Nothing
> particularly unusual about it otherwise. I'm running Ubuntu Linux 5.04
> (kernel 2.6.10).
>
> In the (probably likely) event that you need more information, let me know
> what.
>
> Or you can download the code yourself to try if you wish - it's the Xapian
> search engine library:
>
> http://www.xapian.org/download.php
>
> Download "xapian-core", untar and:
>
> cd xapian-core-0.9.1
> ./configure
> make
> cd tests
> ./runtest ./btreetest
>
> (runtest is just a wrapper shell script to encapsulate the runes required to
> run valgrind "through" libtool).
>
> The valgrind client requests are in testsuite/testsuite.cc (from the top
> level).
>
> Cheers,
> Olly
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Tom H. <to...@co...> - 2005-07-19 23:04:50
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Thu, 30 Jun 2005, Olly Betts wrote:
>=20
> > On 2005-06-30, Nicholas Nethercote <nj...@cs...> wrote:
> >> It would be useful to have some more people using it to help iron ou=
t
> >> remaining bugs. Thanks.
> >
> > I get this failure multiple times with some programs while others run=
fine:
> >
> > lt-btreetest: ../nptl/sysdeps/unix/sysv/linux/fork.c:132: __libc_fork=
: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) =3D=3D=
1) asm volatile ("movb %%fs:%P2,%b0" : "=3Dq" (__value) : "0" (0), "i" (=
((size_t) &((struct pthread *)0)->tid))); else if (sizeof (__value) =3D=3D=
4) asm volatile ("movl %%fs:%P1,%0" : "=3Dr" (__value) : "i" (((size_t) =
&((struct pthread *)0)->tid))); else { if (sizeof (__value) !=3D 8) abort=
(); asm volatile ("movq %%fs:%P1,%q0" : "=3Dr" (__value) : "i" (((size_t=
) &((struct pthread *)0)->tid))); } __value; }) !=3D ppid' failed.
>=20
> This is now logged as bug report #109358.
It should now be fixed - the last two arguments to clone need to be
reversed on amd64 as the kernel expects them the other way round...
> > According to strace the program doesn't call fork when run normally (=
not
> > under valgrind).
It won't do, it will call clone. Modern glibc's use clone (with the
appropriate flags) to implement fork.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Duane G. <d.g...@ps...> - 2005-06-30 12:05:58
|
On Thu, 2005-06-30 at 01:30, Nicholas Nethercote wrote: > Hi, > > For those of you who don't know: the AMD64/Linux development version of > Valgrind is working pretty well these days. Hopefully we'll be able to do > a release soon. In the meantime, if you want to try it out, follow the > instructions for checking the code out of the repository at: > > http://www.valgrind.org/devel/cvs_svn.html > > It would be useful to have some more people using it to help iron out > remaining bugs. Thanks. > > Nick I get the following error when I try it on our code (regardless of the tool): IR-MFence vex: the `impossible' happened: deltaIRStmt vex storage: P 640, T total 762287000 (14322937), T curr 22168 (509) valgrind: the 'impossible' happened: LibVEX called failure_exit(). Let me know if you would like more details. -- Duane Griffin Senior Software Developer Process Systems Enterprise Limited - "The model company" Bridge Studios, 107a Hammersmith Bridge Road, London W6 9DA Call +44 (0)20 8563 0888 or visit us at www.psenterprise.com |
|
From: Julian S. <js...@ac...> - 2005-06-30 12:34:51
|
> I get the following error when I try it on our code (regardless of the
> tool):
>
> IR-MFence
>
> vex: the `impossible' happened:
> deltaIRStmt
Looks like you have a {s,l,m}fence insn in a loop Vex tried to unroll.
Anyway. Try this: in the vex tree, priv/ir/iropt.c, line 2823
(deltaIRStmt): there's a switch which starts thusly:
switch (st->tag) {
case Ist_NoOp:
case Ist_IMark:
break;
...
Add Ist_MFence to the list of stuff which is ignored:
switch (st->tag) {
case Ist_NoOp:
case Ist_IMark:
case Ist_MFence:
break;
...
rebuild all, try again, and LMK if it works better.
J
|
|
From: Duane G. <d.g...@ps...> - 2005-06-30 13:32:31
|
On Thu, 2005-06-30 at 13:34, Julian Seward wrote:
> Anyway. Try this: in the vex tree, priv/ir/iropt.c, line 2823
> (deltaIRStmt): there's a switch which starts thusly:
>
> switch (st->tag) {
> case Ist_NoOp:
> case Ist_IMark:
> break;
> ...
>
> Add Ist_MFence to the list of stuff which is ignored:
>
> switch (st->tag) {
> case Ist_NoOp:
> case Ist_IMark:
> case Ist_MFence:
> break;
> ...
>
> rebuild all, try again, and LMK if it works better.
Yep, that's fixed it. Looks good!
Cheers,
Duane.
--
Duane Griffin
Senior Software Developer
Process Systems Enterprise Limited - "The model company"
Bridge Studios, 107a Hammersmith Bridge Road, London W6 9DA
Call +44 (0)20 8563 0888 or visit us at www.psenterprise.com
|
|
From: Michael P. <md...@tr...> - 2005-07-01 04:44:40
|
Nicholas Nethercote writes:
> It would be useful to have some more people using it to help iron out
> remaining bugs. Thanks.
It's been working well in my testing, but I had to make a change to
(re-)support the epoll_* system calls in m_syswrap; patch below.
Michael Poole
--- coregrind/m_syswrap/syswrap-amd64-linux.c (revision 4073)
+++ coregrind/m_syswrap/syswrap-amd64-linux.c (working copy)
@@ -1325,7 +1325,7 @@
//zz LINXY(__NR_io_cancel, sys_io_cancel), // 210
// (__NR_get_thread_area, sys_ni_syscall), // 211
// (__NR_lookup_dcookie, sys_lookup_dcookie), // 212
-//zz LINXY(__NR_epoll_create, sys_epoll_create), // 213
+ LINXY(__NR_epoll_create, sys_epoll_create), // 213
// (__NR_epoll_ctl_old, sys_ni_syscall), // 214
// (__NR_epoll_wait_old, sys_ni_syscall), // 215
@@ -1348,8 +1348,8 @@
// (__NR_clock_nanosleep, sys_clock_nanosleep),// 230
LINX_(__NR_exit_group, sys_exit_group), // 231
-//zz LINXY(__NR_epoll_wait, sys_epoll_wait), // 232
-//zz LINX_(__NR_epoll_ctl, sys_epoll_ctl), // 233
+ LINXY(__NR_epoll_wait, sys_epoll_wait), // 232
+ LINX_(__NR_epoll_ctl, sys_epoll_ctl), // 233
LINXY(__NR_tgkill, sys_tgkill), // 234
// (__NR_utimes, sys_utimes), // 235
|
|
From: Julian S. <js...@ac...> - 2005-07-01 08:40:39
|
On Friday 01 July 2005 05:44, Michael Poole wrote: > Nicholas Nethercote writes: > > It would be useful to have some more people using it to help iron out > > remaining bugs. Thanks. > > It's been working well in my testing, but I had to make a change to > (re-)support the epoll_* system calls in m_syswrap; patch below. Committed (r4074). Thanks. J |
|
From: <Woe...@on...> - 2005-07-02 13:11:45
|
On Thursday 30 June 2005 02:30, Nicholas Nethercote wrote: > Hi, > > It would be useful to have some more people using it to help iron out > remaining bugs. Thanks. I want to test it but I can't compile valgrind: /usr/bin/ld: __libc_errno: TLS definition in /usr/lib/gcc/x86_64-linux/4.0.= 1/../../../../lib64/libc.a(errno.o) section .tbss mismatches non-TLS refere= nce in /usr/lib/gcc/x86_64-linux/4.0.1/../../../../lib64/libc.a(check_fds.o) /usr/lib/gcc/x86_64-linux/4.0.1/../../../../lib64/libc.a: could not read sy= mbols: Bad value collect2: ld returned 1 exit status gcc -v: gcc version 4.0.1 20050522 (prerelease) (Debian 4.0.0-9) ld -v: GNU ld version 2.16 Debian GNU/Linux glibc-2.3.5-1 (after 2.3.2 failed) Is there a way to dynamic link valgrind or do you've other tips? Cheers, Andr=E9 |
|
From: Nicholas N. <nj...@cs...> - 2005-07-02 15:06:49
|
On Sat, 2 Jul 2005, Andr=E9 W=F6bbeking wrote: > I want to test it but I can't compile valgrind: > > /usr/bin/ld: __libc_errno: TLS definition in /usr/lib/gcc/x86_64-linux/4.= 0.1/../../../../lib64/libc.a(errno.o) section .tbss mismatches non-TLS refe= rence in /usr/lib/gcc/x86_64-linux/4.0.1/../../../../lib64/libc.a(check_fds= =2Eo) > /usr/lib/gcc/x86_64-linux/4.0.1/../../../../lib64/libc.a: could not read = symbols: Bad value > collect2: ld returned 1 exit status > > gcc -v: > > gcc version 4.0.1 20050522 (prerelease) (Debian 4.0.0-9) > > ld -v: > > GNU ld version 2.16 Debian GNU/Linux > > glibc-2.3.5-1 (after 2.3.2 failed) > > Is there a way to dynamic link valgrind or do you've other tips? That looks more like a problem with your system libraries than a problem=20 with Valgrind. Do you have access to another machine you can try it on? N |
|
From: <Woe...@on...> - 2005-07-02 16:14:35
|
On Saturday 02 July 2005 17:06, Nicholas Nethercote wrote: > > That looks more like a problem with your system libraries than a > problem with Valgrind. =20 You're right, but I thought there would be anyone else running Debian on=20 AMD64. > Do you have access to another machine you can try it on? Yes, at work. AMD64 with SuSE 9.3. But it would be nice if valgrind runs=20 on Debian too :-) Cheers, Andr=E9 |
|
From: <Woe...@on...> - 2005-07-21 20:57:57
|
On Saturday 02 July 2005 17:06, Nicholas Nethercote wrote: > On Sat, 2 Jul 2005, Andr=E9 W=F6bbeking wrote: > > GNU ld version 2.16 Debian GNU/Linux > > > > glibc-2.3.5-1 (after 2.3.2 failed) > > > > Is there a way to dynamic link valgrind or do you've other tips? > > That looks more like a problem with your system libraries than a > problem with Valgrind. Do you have access to another machine you can > try it on? =46YI, it works with glibc-2.3.5-2 from Debian experimental. Cheers, Andr=E9 |
|
From: Paul P. <ppl...@gm...> - 2005-07-02 23:39:51
|
Greetings, Today's SVN checkout fails to build on=20 Red Hat Enterprise Linux AS release 3 (Taroon Update 2) x86_64 with gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-39), binutils-2.14.90.0.4-35 $ gcc -pie -m64 ... m_syswrap/libsyswrap.a /home/paul/valgrind-3.0-svn/vex/libvex.a -ldl /usr/bin/ld: /home/paul/valgrind-3.0-svn/vex/libvex.a(irdefs.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /home/paul/valgrind-3.0-svn/vex/libvex.a: could not read symbols: Bad value collect2: ld returned 1 exit status Removing '-pie' solves that, but the resulting valgrind crashes at startup. Adding '-fPIC' to CFLAGS in vex/Makefile also solves this problem and produ= ces a working VG. Every program on this system produces several of these: =3D=3D15027=3D=3D Warning: zero-sized CIE/FDE but not at section end in DWA= RF2 CFI reading Finally, Insure++-instrumented binaries trigger: valgrind: syswrap-amd64-linux.c:718 (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 =3D=3D VKI_ARCH_SET_FS' failed. On FC2-i686 the same test triggers: valgrind: syswrap-main.c:812 (vgPlain_post_syscall): Assertion 'eq_SyscallStatus( &sci->status, &test_status )' failed. The same binary runs fine on FC2-i686 under VG-2.4. This may be a case of 2 memory debugers fighting each other. Regards, |
|
From: Paul P. <ppl...@gm...> - 2005-07-19 17:57:02
|
On 7/18/05, Nicholas Nethercote <nj...@cs...> wrote: > Paul, >=20 > Are you still seeing the problems you reported below? Thanks. > On Sat, 2 Jul 2005, Paul Pluzhnikov wrote: >=20 > > Today's SVN checkout fails to build on > > Red Hat Enterprise Linux AS release 3 (Taroon Update 2) x86_64 with > > gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-39), binutils-2.14.90.0.4= -35 The problem above is gone. > > Every program on this system produces several of these: > > =3D=3D15027=3D=3D Warning: zero-sized CIE/FDE but not at section end in= DWARF2 > > CFI reading The warning(s) above remain. > > Finally, Insure++-instrumented binaries trigger: > > valgrind: syswrap-amd64-linux.c:718 > > (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 =3D=3D > > VKI_ARCH_SET_FS' failed. The same assert still fails, now on line 720. Running 'autogen.sh' on FC2-i686 produces (valgrind svn rev. 4191) $ ./autogen.sh=20 running: aclocal /usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of XIPH_PATH_VORBIS run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20acloc= al /usr/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES /usr/share/aclocal/ogg.m4:8: warning: underquoted definition of XIPH_PATH_O= GG /usr/share/aclocal/libmikmod.m4:11: warning: underquoted definition of AM_PATH_LIBMIKMOD > > On FC2-i686 the same test triggers: > > valgrind: syswrap-main.c:812 (vgPlain_post_syscall): Assertion > > 'eq_SyscallStatus( &sci->status, &test_status )' failed. That assert also fails, now on line 814. Cheers, |
|
From: Paul P. <ppl...@gm...> - 2005-07-19 20:28:50
|
On 7/19/05, Tom Hughes <to...@co...> wrote:
> Can you run with --trace-syscalls=3Dyes so we can see what arguments are
> being given to prctl.
SYSCALL[8307,1](158) arch_prctl ( 4099, 349FDDA8 )
valgrind: syswrap-amd64-linux.c:720
(vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 =3D=3D
VKI_ARCH_SET_FS' failed.
This trivial test reproduces the problem:
--- cut ---
#include <asm/prctl.h>
int main()
{
unsigned long x;
return arch_prctl(ARCH_GET_FS, &x);
}
--- cut ---
> > > > On FC2-i686 the same test triggers:
>=20
> Once again, can you run with --trace-syscalls=3Dyes so we can see what
> the last system call made was as that will be what caused the assertion.
SYSCALL[17749,1](244) sys_get_thread_area ( 0x52BFE984 ) -->
[pre-fail] Failure(0x0)
valgrind: syswrap-main.c:814 (vgPlain_post_syscall): Assertion 'eq_SyscallS=
tatus
( &sci->status, &test_status )' failed.
The test case:
--- cut ---
#include <unistd.h>
#include <syscall.h>
typedef struct {
unsigned int entry_number;
unsigned long int base_addr;
unsigned int limit;
unsigned int seg_32bit:1;
unsigned int contents:2;
unsigned int read_exec_only:1;
unsigned int limit_in_pages:1;
unsigned int seg_not_present:1;
unsigned int useable:1;
unsigned int empty:25;
} LDT;
int main()
{
LDT ldt;
ldt.entry_number =3D 6;
return syscall(SYS_get_thread_area, &ldt);
}
--- cut ---
Cheers,
|
|
From: Rob L. <ro...@te...> - 2005-07-05 20:19:43
|
On Wed, Jun 29, 2005 at 07:30:53PM -0500, Nicholas Nethercote wrote: > It would be useful to have some more people using it to help iron out > remaining bugs. Thanks. Not sure if you consider this a bug or not, but I get quite a few messages about "WARNING: unhandled syscall: 18" (that's __NR_pwrite64) I haven't had much time to implement and contribute the wrapper for pwrite64... ==rob -- Rob Latham Chicago, IL USA |
|
From: Tom H. <to...@co...> - 2005-07-05 23:26:11
|
In message <200...@te...>
Rob Latham <ro...@te...> wrote:
> On Wed, Jun 29, 2005 at 07:30:53PM -0500, Nicholas Nethercote wrote:
> > It would be useful to have some more people using it to help iron out
> > remaining bugs. Thanks.
>
> Not sure if you consider this a bug or not, but I get quite a few
> messages about
> "WARNING: unhandled syscall: 18"
> (that's __NR_pwrite64)
>
> I haven't had much time to implement and contribute the wrapper for
> pwrite64...
Give it a go now as I've just committed a fix for this.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Rob L. <ro...@te...> - 2005-07-06 13:56:17
|
On Wed, Jul 06, 2005 at 12:26:00AM +0100, Tom Hughes wrote: > Give it a go now as I've just committed a fix for this. Thanks. My app runs a-ok now. ==rob -- Rob Latham Chicago, IL USA |
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 03:49:09
|
Paul, Are you still seeing the problems you reported below? Thanks. N On Sat, 2 Jul 2005, Paul Pluzhnikov wrote: > Today's SVN checkout fails to build on > Red Hat Enterprise Linux AS release 3 (Taroon Update 2) x86_64 with > gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-39), binutils-2.14.90.0.4-35 > > $ gcc -pie -m64 ... m_syswrap/libsyswrap.a > /home/paul/valgrind-3.0-svn/vex/libvex.a -ldl > /usr/bin/ld: /home/paul/valgrind-3.0-svn/vex/libvex.a(irdefs.o): > relocation R_X86_64_32S can not be used when making a shared object; > recompile with -fPIC > /home/paul/valgrind-3.0-svn/vex/libvex.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > > Removing '-pie' solves that, but the resulting valgrind crashes at startup. > Adding '-fPIC' to CFLAGS in vex/Makefile also solves this problem and produces a > working VG. > > Every program on this system produces several of these: > ==15027== Warning: zero-sized CIE/FDE but not at section end in DWARF2 > CFI reading > > Finally, Insure++-instrumented binaries trigger: > valgrind: syswrap-amd64-linux.c:718 > (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 == > VKI_ARCH_SET_FS' failed. > > On FC2-i686 the same test triggers: > valgrind: syswrap-main.c:812 (vgPlain_post_syscall): Assertion > 'eq_SyscallStatus( &sci->status, &test_status )' failed. > > The same binary runs fine on FC2-i686 under VG-2.4. This may be a case > of 2 memory debugers fighting each other. > > Regards, > |
|
From: Tom H. <to...@co...> - 2005-07-19 18:06:03
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> > > Finally, Insure++-instrumented binaries trigger:
> > > valgrind: syswrap-amd64-linux.c:718
> > > (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 ==
> > > VKI_ARCH_SET_FS' failed.
>
> The same assert still fails, now on line 720.
Can you run with --trace-syscalls=yes so we can see what arguments are
being given to prctl.
> Running 'autogen.sh' on FC2-i686 produces (valgrind svn rev. 4191)
> $ ./autogen.sh
> running: aclocal
> /usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of
> XIPH_PATH_VORBIS
> run info '(automake)Extending aclocal'
> or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
> /usr/share/aclocal/pkg.m4:5: warning: underquoted definition of
> PKG_CHECK_MODULES
> /usr/share/aclocal/ogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG
> /usr/share/aclocal/libmikmod.m4:11: warning: underquoted definition of
> AM_PATH_LIBMIKMOD
Those don't matter, and they're an issue with your local installation
of the ogg/vorbis development packages.
> > > On FC2-i686 the same test triggers:
> > > valgrind: syswrap-main.c:812 (vgPlain_post_syscall): Assertion
> > > 'eq_SyscallStatus( &sci->status, &test_status )' failed.
>
> That assert also fails, now on line 814.
Once again, can you run with --trace-syscalls=yes so we can see what
the last system call made was as that will be what caused the assertion.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-07-19 22:45:23
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> On 7/19/05, Tom Hughes <to...@co...> wrote:
>
> > Can you run with --trace-syscalls=yes so we can see what arguments are
> > being given to prctl.
>
> SYSCALL[8307,1](158) arch_prctl ( 4099, 349FDDA8 )
> valgrind: syswrap-amd64-linux.c:720
> (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 ==
> VKI_ARCH_SET_FS' failed.
This should be fixed now.
> > > > > On FC2-i686 the same test triggers:
> >
> > Once again, can you run with --trace-syscalls=yes so we can see what
> > the last system call made was as that will be what caused the assertion.
>
> SYSCALL[17749,1](244) sys_get_thread_area ( 0x52BFE984 ) -->
> [pre-fail] Failure(0x0)
>
> valgrind: syswrap-main.c:814 (vgPlain_post_syscall): Assertion 'eq_SyscallStatus
> ( &sci->status, &test_status )' failed.
As should this. Thanks for the traces and test cases.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2005-07-20 05:27:05
|
On 7/19/05, Tom Hughes <to...@co...> wrote: > > valgrind: syswrap-amd64-linux.c:720 > > (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 =3D=3D > > VKI_ARCH_SET_FS' failed. >=20 > This should be fixed now. Confirmed. > > valgrind: syswrap-main.c:814 (vgPlain_post_syscall): Assertion 'eq_Sysc= allStatus > > ( &sci->status, &test_status )' failed. >=20 > As should this.=20 Ditto. Thanks, |