|
From: Dirk M. <dm...@gm...> - 2006-09-08 18:18:07
|
On Wednesday 06 September 2006 19:51, Tom Hughes wrote:
> I'm not sure this is anything to worry about - it has crashed
> trying to run the glibc cleanup code but if glibc has already
> corrupted it's state then it's not entirely surprising if that
> fails.
I don't think so - I see it too everywhere even for clean applications. and=
=20
looking at the code its not a surprise:=20
VALGRIND_DO_CLIENT_REQUEST(res, 0 /* default */,
VG_USERREQ__LIBC_FREERES_DONE,=B7
0, 0, 0, 0, 0);
/*NOTREACHED*/
*(int *)0 =3D 'x';
}
The NOTREACHED part is executed for me. Julian said that it might be becaus=
e=20
the compiler optimizes the DO_CLIENT_REQUEST away, but I haven't checked=20
that.=20
Dirk
|
|
From: Julian S. <js...@ac...> - 2006-09-10 08:23:19
|
> I don't think so - I see it too everywhere even for clean applications. a= nd > looking at the code its not a surprise: > > VALGRIND_DO_CLIENT_REQUEST(res, 0 /* default */, > VG_USERREQ__LIBC_FREERES_DONE,=B7 > 0, 0, 0, 0, 0); > /*NOTREACHED*/ > *(int *)0 =3D 'x'; > } > > The NOTREACHED part is executed for me. Julian said that it might be > because the compiler optimizes the DO_CLIENT_REQUEST away, but I haven't > checked that. Ah, you mentioned this a couple of weeks ago. I installed openSuse 10.2=20 alpha 3 for x86 on vmware, but couldn't reproduce this problem with the=20 svn trunk - all the regression tests looked ok. Are you sure you don't=20 have some confusion with header files, such as accidentally picking up=20 the header files (valgrind.h, memcheck.h) from a 3.1.X install? The client request implementation changed from 3.1.X to 3.2.X in such a way that code compiled against a 3.1.X header will not be recognised at run time by 3.2.X as a client request. J |
|
From: Dirk M. <dm...@gm...> - 2006-09-10 18:24:52
|
On Sunday, 10. September 2006 10:23, Julian Seward wrote: > Ah, you mentioned this a couple of weeks ago. I installed openSuse 10.2 > alpha 3 for x86 on vmware, but couldn't reproduce this problem with the > svn trunk - all the regression tests looked ok. Are you sure you don't > have some confusion with header files, such as accidentally picking up > the header files (valgrind.h, memcheck.h) from a 3.1.X install? I found out that it was caused by the DRD patch. No client request besides the drd ones seemed to work anymore. Dirk |
|
From: Bart V. A. <bar...@gm...> - 2006-09-13 19:13:59
|
Confirmed: I get the same issue with memcheck when the drd patch is there. It's not clear to me however why the client request is ignored. bart@pc-100:~/software/valgrind-svn> inst/bin/valgrind --tool=memcheck /bin/date ==5325== Memcheck, a memory error detector. ==5325== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==5325== Using LibVEX rev 1579, a library for dynamic binary translation. ==5325== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==5325== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==5325== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==5325== For more details, rerun with: -v ==5325== Wed Sep 13 21:03:35 CEST 2006 ==5325== Invalid write of size 4 ==5325== at 0x401CBA9: _vgnU_freeres (vg_preloaded.c:66) ==5325== by 0x40D32A7: _Exit (in /lib/libc-2.4.so) ==5325== by 0x8049C3A: (within /bin/date) ==5325== by 0x405D87B: (below main) (in /lib/libc-2.4.so) ==5325== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==5325== ==5325== Process terminating with default action of signal 11 (SIGSEGV) ==5325== Access not within mapped region at address 0x0 ==5325== at 0x401CBA9: _vgnU_freeres (vg_preloaded.c:66) ==5325== by 0x40D32A7: _Exit (in /lib/libc-2.4.so) ==5325== by 0x8049C3A: (within /bin/date) ==5325== by 0x405D87B: (below main) (in /lib/libc-2.4.so) ==5325== ==5325== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 1) ==5325== malloc/free: in use at exit: 0 bytes in 0 blocks. ==5325== malloc/free: 424 allocs, 424 frees, 19,912 bytes allocated. ==5325== For counts of detected errors, rerun with: -v ==5325== All heap blocks were freed -- no leaks are possible. On 9/10/06, Dirk Mueller <dm...@gm...> wrote: > > On Sunday, 10. September 2006 10:23, Julian Seward wrote: > > > Ah, you mentioned this a couple of weeks ago. I installed openSuse 10.2 > > alpha 3 for x86 on vmware, but couldn't reproduce this problem with the > > svn trunk - all the regression tests looked ok. Are you sure you don't > > have some confusion with header files, such as accidentally picking up > > the header files (valgrind.h, memcheck.h) from a 3.1.X install? > > I found out that it was caused by the DRD patch. No client request besides > the > drd ones seemed to work anymore. > |
|
From: Bart V. A. <bar...@gm...> - 2006-09-10 19:07:41
|
Hello Dirk,
Can you provide me a reproducible test case ? I'd like to have a look at
this and fix this.
On 9/10/06, Dirk Mueller <dm...@gm...> wrote:
>
> On Sunday, 10. September 2006 10:23, Julian Seward wrote:
>
> > Ah, you mentioned this a couple of weeks ago. I installed openSuse 10.2
> > alpha 3 for x86 on vmware, but couldn't reproduce this problem with the
> > svn trunk - all the regression tests looked ok. Are you sure you don't
> > have some confusion with header files, such as accidentally picking up
> > the header files (valgrind.h, memcheck.h) from a 3.1.X install?
>
> I found out that it was caused by the DRD patch. No client request besides
> the
> drd ones seemed to work anymore.
>
>
> Dirk
|
|
From: Dirk M. <dm...@gm...> - 2006-09-10 20:51:30
|
On Sunday, 10. September 2006 21:07, Bart Van Assche wrote: > Can you provide me a reproducible test case ? I'd like to have a look > at this and fix this. well, its just a valgrind patched with your DRD patches, and it happens on any application, e.g. /bin/false. if thats not reproduceable for you, then I have to look further.. Dirk |
|
From: Bart V. A. <bar...@gm...> - 2006-09-12 19:23:44
|
Hello Dirk, drd still runs fine for me, whether I use it to run /bin/false, /bin/true or /bin/date (SuSE 10.1, Valgrind revision 6053): bart@pc-100:~/software/valgrind-svn> inst/bin/valgrind --tool=drd /bin/date ==11882== drd, a data race detector. ==11882== Copyright (C) 2006, and GNU GPL'd, by Bart Van Assche. THIS SOFTWARE IS A PROTOTYPE, AND IS NOT YET RELEASED ==11882== Using LibVEX rev 1579, a library for dynamic binary translation. ==11882== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==11882== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==11882== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==11882== For more details, rerun with: -v ==11882== Tue Sep 12 21:10:36 CEST 2006 ==11882== ==11882== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) On 9/10/06, Dirk Mueller <dm...@gm...> wrote: > > On Sunday, 10. September 2006 21:07, Bart Van Assche wrote: > > > Can you provide me a reproducible test case ? I'd like to have a > look > > at this and fix this. > > well, its just a valgrind patched with your DRD patches, and it happens on > any > application, e.g. /bin/false. if thats not reproduceable for you, then I > have > to look further.. > > Dirk > |
|
From: Julian S. <js...@ac...> - 2006-09-12 20:03:51
|
Bart, maybe I misunderstood, but what I thought Dirk meant was, in your modified tree, memcheck no longer works correctly. J On Tuesday 12 September 2006 20:23, Bart Van Assche wrote: > Hello Dirk, > > drd still runs fine for me, whether I use it to run /bin/false, /bin/true > or /bin/date (SuSE 10.1, Valgrind revision 6053): > > bart@pc-100:~/software/valgrind-svn> inst/bin/valgrind --tool=drd /bin/date > ==11882== drd, a data race detector. > ==11882== Copyright (C) 2006, and GNU GPL'd, by Bart Van Assche. > THIS SOFTWARE IS A PROTOTYPE, AND IS NOT YET RELEASED > ==11882== Using LibVEX rev 1579, a library for dynamic binary translation. > ==11882== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > ==11882== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation > framework. > ==11882== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. > ==11882== For more details, rerun with: -v > ==11882== > Tue Sep 12 21:10:36 CEST 2006 > ==11882== > ==11882== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > On 9/10/06, Dirk Mueller <dm...@gm...> wrote: > > On Sunday, 10. September 2006 21:07, Bart Van Assche wrote: > > > Can you provide me a reproducible test case ? I'd like to have a > > > > look > > > > > at this and fix this. > > > > well, its just a valgrind patched with your DRD patches, and it happens > > on any > > application, e.g. /bin/false. if thats not reproduceable for you, then I > > have > > to look further.. > > > > Dirk |
|
From: Dirk M. <dm...@gm...> - 2006-09-12 20:09:07
|
On Tuesday, 12. September 2006 22:03, Julian Seward wrote: > Bart, maybe I misunderstood, but what I thought Dirk meant was, in your > modified tree, memcheck no longer works correctly. Exactly, DRD works as far as it is concerned. The crash happens in memcheck. Dirk |