Re: valgrind on 5.3BETA1

2004-08-24 Thread Simon Barner 
 --- coregrind/vg_proxylwp.c~  Mon Aug 23 15:47:33 2004
 +++ coregrind/vg_proxylwp.c   Mon Aug 23 15:48:42 2004
 @@ -596,6 +596,8 @@
 static const vki_kstack_t ss = { .ss_flags = VKI_SS_DISABLE };
  
  #if __FreeBSD__ == 5
 +   VG_(message)(Vg_UserMsg, Locking#1 mutex %p/%p, px-mutex, px-mutex.u_owner);
 VG_(do_syscall)(__NR__umtx_lock, px-mutex);
 +   VG_(message)(Vg_UserMsg, Done %p/%p, px-mutex, px-mutex.u_owner);
 px-mutex.u_owner |= UMTX_CONTESTED;
 VG_(do_syscall)(__NR_thr_self, px-lwp);
 @@ -943,6 +944,8 @@
 px-exitcode = ret;
  
  #if __FreeBSD__ == 5
 +   VG_(message)(Vg_UserMsg, Unlocking mutex %p/%p, px-mutex, px-mutex.u_owner);
 ret = VG_(do_syscall)(__NR__umtx_unlock, px-mutex);
 +   VG_(message)(Vg_UserMsg, Done %p/%p, px-mutex, px-mutex.u_owner);
 if (use_rfork)
VG_(do_syscall)(__NR_exit, 0);
 @@ -1171,7 +1173,11 @@
  #if __FreeBSD__ == 5
 if (block) {
 if(proxy-lwp != 0)
 +   {
 +VG_(message)(Vg_UserMsg, Locking#2 mutex %p/%p, proxy-mutex, 
 proxy-mutex.u_owner);
  VG_(do_syscall)(__NR__umtx_lock, proxy-mutex);
   
   Commenting out this lock operation works for me. Did you
   notice that there are two places where the lock is acquired,
   and only one, where it is released?

   Perhaps the right solution would be to add another unlock
   operation...?
   
   Of course, I have no idea of valgrind internals, threading
   implementation on FreeBSD, umtx, etc. ;-D

 +VG_(message)(Vg_UserMsg, Done %p/%p, proxy-mutex, proxy-mutex.u_owner);
 +   }
  
 if (status)
  *status = proxy-exitcode;



pgpEiQAEcbHxN.pgp
Description: PGP signature

Re: valgrind on 5.3BETA1

2004-08-23 Thread Simon Barner 
Miguel Mendez wrote:
 Hi all,
 
 Is anybody using valgrind on 5.3BETA1 or newer? I've been using it for a
 while on 5.2.1 without any problems, until I upgraded my system to
 RELENG_5. The program works but it never exits after running your
 program, it gets stuck into `umtx' state indefinitely. This is happening
 with both plain jane valgrind and valgrind-snapshot ports. Is this
 already a known issue? 

Hi,

there is a closed problem report in the database:
http://www.freebsd.org/cgi/query-pr.cgi?pr=68992

At the end of that PR, there is a patch that seems to work around
the problem. Could you please test it?

Simon



pgpd7SuzloyGj.pgp
Description: PGP signature

Re: valgrind on 5.3BETA1

2004-08-23 Thread Miguel Mendez 
On Mon, 23 Aug 2004 22:03:39 +0200
Simon Barner [EMAIL PROTECTED] wrote:

Hi,
 
 there is a closed problem report in the database:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=68992
 
 At the end of that PR, there is a patch that seems to work around
 the problem. Could you please test it?

Interesting. However, it looks like that patch was already incorporated
into valgrind (the patch is for version 337, the port has 352), but it
can be a good start to get an idea of what to look for.

Cheers,
-- 
Miguel Mendez [EMAIL PROTECTED]
http://www.energyhq.es.eu.org
PGP Key: 0xDC8514F1
Note: All HTML and non-english mail goes to /dev/null


pgprJhsgL3TcK.pgp
Description: PGP signature

Re: valgrind on 5.3BETA1

2004-08-23 Thread Dan Nelson 
In the last episode (Aug 23), Simon Barner said:
 Miguel Mendez wrote:
  Is anybody using valgrind on 5.3BETA1 or newer? I've been using it
  for a while on 5.2.1 without any problems, until I upgraded my
  system to RELENG_5. The program works but it never exits after
  running your program, it gets stuck into `umtx' state indefinitely.
  This is happening with both plain jane valgrind and
  valgrind-snapshot ports. Is this already a known issue?
 
 Hi,
 
 there is a closed problem report in the database:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=68992
 
 At the end of that PR, there is a patch that seems to work around the
 problem. Could you please test it?

That patch looks like it's already in the valgrind-snapshot-352 port,
and it still hangs on me.  Adding some debugging to the code that calls
the umtx syscalls give me:

$ valgrind --skin=memcheck date
==14620== Memcheck, a memory error detector for x86-linux.
==14620== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==14620== Using valgrind-2.1.2.CVS, a program supervision framework for x86-linux.
==14620== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==14620== Locking#1 mutex 0x0/0x0
==14620== Done 0x187B8/0x187B8
==14620== For more details, rerun with: -v
==14620==
Mon Aug 23 16:17:01 CDT 2004
==14620==
==14620== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14620== malloc/free: in use at exit: 4096 bytes in 1 blocks.
==14620== malloc/free: 1 allocs, 0 frees, 4096 bytes allocated.
==14620== For a detailed leak analysis,  rerun with: --leak-check=yes
==14620== For counts of detected errors, rerun with: -v
==14620== Unlocking mutex 0x187B9/0x187B9
==14620== Done 0x187B9/0x187B9
==14620== Locking#2 mutex 0x187B9/0x187B9
( send SIGKILL from another vty here )
zsh: 14620 killed valgrind --skin=memcheck date

There doesn't seem to be any docs on these umtx syscalls so I don't
know what the expected behaviour is supposed to be.  I printed the
pointer and the contents of the u_owner member before and after the
syscall.

-- 
Dan Nelson
[EMAIL PROTECTED]
--- coregrind/vg_proxylwp.c~Mon Aug 23 15:47:33 2004
+++ coregrind/vg_proxylwp.c Mon Aug 23 15:48:42 2004
@@ -596,6 +596,8 @@
static const vki_kstack_t ss = { .ss_flags = VKI_SS_DISABLE };
 
 #if __FreeBSD__ == 5
+   VG_(message)(Vg_UserMsg, Locking#1 mutex %p/%p, px-mutex, px-mutex.u_owner);
VG_(do_syscall)(__NR__umtx_lock, px-mutex);
+   VG_(message)(Vg_UserMsg, Done %p/%p, px-mutex, px-mutex.u_owner);
px-mutex.u_owner |= UMTX_CONTESTED;
VG_(do_syscall)(__NR_thr_self, px-lwp);
@@ -943,6 +944,8 @@
px-exitcode = ret;
 
 #if __FreeBSD__ == 5
+   VG_(message)(Vg_UserMsg, Unlocking mutex %p/%p, px-mutex, px-mutex.u_owner);
ret = VG_(do_syscall)(__NR__umtx_unlock, px-mutex);
+   VG_(message)(Vg_UserMsg, Done %p/%p, px-mutex, px-mutex.u_owner);
if (use_rfork)
   VG_(do_syscall)(__NR_exit, 0);
@@ -1171,7 +1173,11 @@
 #if __FreeBSD__ == 5
if (block) {
if(proxy-lwp != 0)
+   {
+  VG_(message)(Vg_UserMsg, Locking#2 mutex %p/%p, proxy-mutex, 
proxy-mutex.u_owner);
   VG_(do_syscall)(__NR__umtx_lock, proxy-mutex);
+  VG_(message)(Vg_UserMsg, Done %p/%p, proxy-mutex, proxy-mutex.u_owner);
+   }
 
if (status)
   *status = proxy-exitcode;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: valgrind on 5.3BETA1

2004-08-23 Thread Dan Nelson 
In the last episode (Aug 23), Dan Nelson said:
 --- coregrind/vg_proxylwp.c~  Mon Aug 23 15:47:33 2004
 +++ coregrind/vg_proxylwp.c   Mon Aug 23 15:48:42 2004

And of course I screwed up the patch.  The first argument of each print
call should be printing px-mutex, not px-mutex.  Here's better
output:

==52845== Memcheck, a memory error detector for x86-linux.
==52845== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==52845== Using valgrind-2.1.2.CVS, a program supervision framework for x86-linux.
==52845== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==52845== Locking#1 mutex 0xB82E4F78/0x0
==52845== Done 0xB82E4F78/0x18820
==52845== For more details, rerun with: -v
==52845==
Mon Aug 23 16:30:27 CDT 2004
==52845==
==52845== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==52845== malloc/free: in use at exit: 4096 bytes in 1 blocks.
==52845== malloc/free: 1 allocs, 0 frees, 4096 bytes allocated.
==52845== For a detailed leak analysis,  rerun with: --leak-check=yes
==52845== For counts of detected errors, rerun with: -v
==52845== Unlocking mutex 0xB82E4F78/0x18821
==52845== Done 0xB82E4F78/0x18821
==52845== Locking#2 mutex 0xB82E4F78/0x18821
( send SIGKILL here )
zsh: 52845 killed valgrind --skin=memcheck date


-- 
Dan Nelson
[EMAIL PROTECTED]
--- coregrind/vg_proxylwp.c~Mon Aug 23 15:47:33 2004
+++ coregrind/vg_proxylwp.c Mon Aug 23 15:48:42 2004
@@ -596,6 +596,8 @@
static const vki_kstack_t ss = { .ss_flags = VKI_SS_DISABLE };
 
 #if __FreeBSD__ == 5
+   VG_(message)(Vg_UserMsg, Locking#1 mutex %p/%p, px-mutex, px-mutex.u_owner);
VG_(do_syscall)(__NR__umtx_lock, px-mutex);
+   VG_(message)(Vg_UserMsg, Done %p/%p, px-mutex, px-mutex.u_owner);
px-mutex.u_owner |= UMTX_CONTESTED;
VG_(do_syscall)(__NR_thr_self, px-lwp);
@@ -943,6 +944,8 @@
px-exitcode = ret;
 
 #if __FreeBSD__ == 5
+   VG_(message)(Vg_UserMsg, Unlocking mutex %p/%p, px-mutex, px-mutex.u_owner);
ret = VG_(do_syscall)(__NR__umtx_unlock, px-mutex);
+   VG_(message)(Vg_UserMsg, Done %p/%p, px-mutex, px-mutex.u_owner);
if (use_rfork)
   VG_(do_syscall)(__NR_exit, 0);
@@ -1171,7 +1173,11 @@
 #if __FreeBSD__ == 5
if (block) {
if(proxy-lwp != 0)
+   {
+  VG_(message)(Vg_UserMsg, Locking#2 mutex %p/%p, proxy-mutex, 
proxy-mutex.u_owner);
   VG_(do_syscall)(__NR__umtx_lock, proxy-mutex);
+  VG_(message)(Vg_UserMsg, Done %p/%p, proxy-mutex, proxy-mutex.u_owner);
+   }
 
if (status)
   *status = proxy-exitcode;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]