Menu
▾
▴
valgrind-users
|
From: Atalay O. <aoz...@ra...> - 2015-04-09 19:15:21
|
This is essentially the same bug as: https://bugs.kde.org/show_bug.cgi?id=278057 A patch was applied for this bug in version 3.7 and it is considered fixed. I am using version 3.10, I confirmed in the source code that the patch is applied. Valgrind still dread-locks when used to test an application that uses fuse in our environment. We are using 64bit Ubuntu 12.04LTS. Anybody knows if there is an easy fix? Thanks, Atalay |
|
From: Philippe W. <phi...@sk...> - 2015-04-10 21:07:35
|
On Thu, 2015-04-09 at 14:08 -0400, Atalay Ozgovde wrote: > This is essentially the same bug > as:https://bugs.kde.org/show_bug.cgi?id=278057 > > A patch was applied for this bug in version 3.7 and it is considered > fixed. > I am using version 3.10, I confirmed in the source code that the patch > is applied. Valgrind still dread-locks when used to test an > application that uses fuse in our environment. We are using 64bit > Ubuntu 12.04LTS. > > Anybody knows if there is an easy fix? As far as I can see, the 'potentially deadlocking syscall with fuse' have to be marked specially in Valgrind code. If compared to the patch in 3.7, you now have additional syscalls that have to be marked, then that might explain the problem. Maybe you could discover such syscalls by using --trace-syscalls=yes valgrind option and/or using strace -f valgrind .... and see which syscalls are 'on-going' when the whole stuff deadlocks. Philippe |
|
From: Julian S. <js...@ac...> - 2015-04-13 11:07:30
|
On 09/04/15 20:08, Atalay Ozgovde wrote: > This is essentially the same bug as: > https://bugs.kde.org/show_bug.cgi?id=278057 > A patch was applied for this bug in version 3.7 and it is considered fixed. > I am using version 3.10, I confirmed in the source code that the patch is > applied. Valgrind still dread-locks when used to test an application that > uses fuse in our environment. We are using 64bit Ubuntu 12.04LTS. > Anybody knows if there is an easy fix? First you need to find out exactly why it is hanging. If you run with --trace-syscalls=yes, you can infer (indirectly) the state of each thread at the point where the hang happens. Can you do that and post the last 100 lines or so? J |
|
From: Atalay O. <aoz...@ra...> - 2015-04-13 13:45:12
|
Thanks guys for the suggestion. Below I posted the "--trace-syscalls=yes" output after the call to "fusermount". An interesting thing is when using the alternative tracing option ie. "strace -f valgrind ..." the filesystem does not dead-lock, and I get the valgrind report. Here is the strace: SYSCALL[13441,3](59) sys_execve ( 0x8b7da0(/bin/fusermount), 0x8f91620, 0x7502fa0 )SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,2](202) ... [async] --> Failure(0x6e) SYSCALL[13431,2](202) sys_futex ( 0x74f4898, 129, 1, 0x8790c30, 0x74f47f0 ) --> [async] ... SYSCALL[13431,2](202) ... [async] --> Success(0x0:0x0) SYSCALL[13431,2](96) sys_gettimeofday ( 0x8790cd0, 0x0 )[sync] --> Success(0x0:0x0) SYSCALL[13431,2](202) sys_futex ( 0x74f48c4, 393, 11, 0x8790c30, 0x74f4898 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,3](47) ... [async] --> Success(0x0:0x0) SYSCALL[13431,3](3) sys_close ( 6 ) --> [async] ... SYSCALL[13431,3](3) ... [async] --> Success(0x0:0x0) SYSCALL[13431,3](61) sys_wait4 ( 13441, 0x0, 0, 0x0 ) --> [async] ... SYSCALL[13431,3](61) ... [async] --> Success(0x0:0x3481) SYSCALL[13431,3](53) sys_socketpair ( 1, 1, 0, 0x8f91790 )[sync] --> Success(0x0:0x0) SYSCALL[13431,3](56) sys_clone ( 1200011, 0x0, 0x0, 0x8f929d0, 0x3477 ) clone(fork): process 13431 created child 13443 --> [pre-success] Success(0x0:0x3483) SYSCALL[13431,3](3) sys_close ( 5 ) --> [async] ... SYSCALL[13431,3](3) ... [async] --> Success(0x0:0x0) SYSCALL[13431,3](47) sys_recvmsg ( 6, 0x8f91720, 0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,2](202) ... [async] --> Failure(0x6e) SYSCALL[13431,2](202) sys_futex ( 0x74f4898, 129, 1, 0x8790c30, 0x74f47f0 ) --> [async] ... SYSCALL[13431,2](202) ... [async] --> Success(0x0:0x0) SYSCALL[13431,2](96) sys_gettimeofday ( 0x8790cd0, 0x0 )[sync] --> Success(0x0:0x0) SYSCALL[13431,2](202) sys_futex ( 0x74f48c4, 393, 13, 0x8790c30, 0x74f4898 ) --> [async] ... --> [pre-success] Success(0x0:0x0) SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13443,3](273) sys_set_robust_list ( 0x8f929e0, 24 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13443,3](3) sys_close ( 6 ) --> [async] ... SYSCALL[13443,3](3) ... [async] --> Success(0x0:0x0) SYSCALL[13443,3](72) sys_fcntl[ARG3=='arg'] ( 5, 2, 0 )[sync] --> Success(0x0:0x0) --13443-- REDIR: 0x6f131d0 (libc.so.6:setenv) redirected to 0x4c31f50 (setenv) SYSCALL[13431,2](202) ... [async] --> Failure(0x6e) SYSCALL[13431,2](202) sys_futex ( 0x74f4898, 129, 1, 0x8790c30, 0x74f47f0 ) --> [async] ... SYSCALL[13431,2](202) ... [async] --> Success(0x0:0x0) SYSCALL[13431,2](96) sys_gettimeofday ( 0x8790cd0, 0x0 )[sync] --> Success(0x0:0x0) SYSCALL[13431,2](202) sys_futex ( 0x74f48c4, 393, 15, 0x8790c30, 0x74f4898 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13443,3](59) sys_execve ( 0x8b7da0(/bin/fusermount), 0x8f91620, 0x7502fa0 )SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,2](202) ... [async] --> Failure(0x6e) SYSCALL[13431,2](202) sys_futex ( 0x74f4898, 129, 1, 0x8790c30, 0x74f47f0 ) --> [async] ... SYSCALL[13431,2](202) ... [async] --> Success(0x0:0x0) SYSCALL[13431,2](96) sys_gettimeofday ( 0x8790cd0, 0x0 )[sync] --> Success(0x0:0x0) SYSCALL[13431,2](202) sys_futex ( 0x74f48c4, 393, 17, 0x8790c30, 0x74f4898 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 )[sync] --> Success(0x0:0x0) SYSCALL[13431,1](35) sys_nanosleep ( 0xffefff320, 0x0 ) --> [async] ... SYSCALL[13431,1](35) ... [async] --> Success(0x0:0x0) SYSCALL[13431,1](137) sys_statfs ( 0x74f90b8(/home/atalay/dev/Sage/DispatcherServer/bin/debug/proc/), 0xffefff640 ) Thanks a lot, Atalay On Mon, Apr 13, 2015 at 7:07 AM, Julian Seward <js...@ac...> wrote: > On 09/04/15 20:08, Atalay Ozgovde wrote: > > This is essentially the same bug as: > > https://bugs.kde.org/show_bug.cgi?id=278057 > > A patch was applied for this bug in version 3.7 and it is considered > fixed. > > I am using version 3.10, I confirmed in the source code that the patch is > > applied. Valgrind still dread-locks when used to test an application that > > uses fuse in our environment. We are using 64bit Ubuntu 12.04LTS. > > Anybody knows if there is an easy fix? > > First you need to find out exactly why it is hanging. If you run > with --trace-syscalls=yes, you can infer (indirectly) the state of each > thread at the point where the hang happens. Can you do that and post > the last 100 lines or so? > > J > > > |
|
From: Atalay O. <aoz...@ra...> - 2015-04-15 20:43:32
|
Upon tracing valgrind upon suggestions above I found two offending system
calls in my code: sys_newstat and sys_statfs. I also verified deadlock
lines by running valgrind with "vgdb" set and stepping through the code.
Following patch is the changed I did in valgrind to get these system calls
supported. Let me know if there is interest in applying the patch in trunk,
and if so I should submit this patch elsewhere.
--- coregrind/m_syswrap/syswrap-generic.c 2014-11-25
14:41:20.000000000 -0500
+++
/home/atalay/source/valgrind-3.10.1/coregrind/m_syswrap/syswrap-generic.c
2015-04-15 15:50:38.465388486 -0400
@@ -4101,6 +4101,8 @@
PRE_REG_READ2(long, "setreuid", vki_uid_t, ruid, vki_uid_t, euid);
}
+
+
PRE(sys_setrlimit)
{
UWord arg1 = ARG1;
@@ -4160,6 +4162,7 @@
PRE(sys_newstat)
{
+ *flags |= SfMayBlock;
PRINT("sys_newstat ( %#lx(%s), %#lx )", ARG1,(char*)ARG1,ARG2);
PRE_REG_READ2(long, "stat", char *, file_name, struct stat *, buf);
PRE_MEM_RASCIIZ( "stat(file_name)", ARG1 );
@@ -4173,6 +4176,7 @@
PRE(sys_statfs)
{
+ *flags |= SfMayBlock;
PRINT("sys_statfs ( %#lx(%s), %#lx )",ARG1,(char*)ARG1,ARG2);
PRE_REG_READ2(long, "statfs", const char *, path, struct statfs *, buf);
PRE_MEM_RASCIIZ( "statfs(path)", ARG1 );
Thanks the responses.
Atalay
On Thu, Apr 9, 2015 at 2:08 PM, Atalay Ozgovde <aoz...@ra...> wrote:
> This is essentially the same bug as:
> https://bugs.kde.org/show_bug.cgi?id=278057
> A patch was applied for this bug in version 3.7 and it is considered
> fixed.
> I am using version 3.10, I confirmed in the source code that the patch is
> applied. Valgrind still dread-locks when used to test an application that
> uses fuse in our environment. We are using 64bit Ubuntu 12.04LTS.
> Anybody knows if there is an easy fix?
>
> Thanks,
>
> Atalay
>
>
|
|
From: Philippe W. <phi...@sk...> - 2015-04-15 22:03:41
|
On Wed, 2015-04-15 at 16:35 -0400, Atalay Ozgovde wrote:
> Upon tracing valgrind upon suggestions above I found two offending
> system calls in my code: sys_newstat and sys_statfs. I also verified
> deadlock lines by running valgrind with "vgdb" set and stepping
> through the code.
>
> Following patch is the changed I did in valgrind to get these system
> calls supported. Let me know if there is interest in applying the
> patch in trunk, and if so I should submit this patch elsewhere.
As Valgrind was already modified in the past to support fuse, I think
we better fix the trunk.
A small note:
syscalls that have to be considered as blocking only for 'fuse reason'
are marked with:
FUSE_COMPATIBLE_MAY_BLOCK();
and not with an unconditional
*flags |= SfMayBlock;
unless these syscalls must be considered as blocking
even when not activating the --sim-hints=fuse-compatible hint.
The best way to add a bug in bugzilla, with the patch.
Thanks
Philippe
>
>
> --- coregrind/m_syswrap/syswrap-generic.c 2014-11-25
> 14:41:20.000000000 -0500
> +++ /home/atalay/source/valgrind-3.10.1/coregrind/m_syswrap/syswrap-generic.c 2015-04-15 15:50:38.465388486 -0400
> @@ -4101,6 +4101,8 @@
> PRE_REG_READ2(long, "setreuid", vki_uid_t, ruid, vki_uid_t, euid);
> }
>
> +
> +
> PRE(sys_setrlimit)
> {
> UWord arg1 = ARG1;
> @@ -4160,6 +4162,7 @@
>
> PRE(sys_newstat)
> {
> + *flags |= SfMayBlock;
> PRINT("sys_newstat ( %#lx(%s), %#lx )", ARG1,(char*)ARG1,ARG2);
> PRE_REG_READ2(long, "stat", char *, file_name, struct stat *,
> buf);
> PRE_MEM_RASCIIZ( "stat(file_name)", ARG1 );
> @@ -4173,6 +4176,7 @@
>
> PRE(sys_statfs)
> {
> + *flags |= SfMayBlock;
> PRINT("sys_statfs ( %#lx(%s), %#lx )",ARG1,(char*)ARG1,ARG2);
> PRE_REG_READ2(long, "statfs", const char *, path, struct statfs *,
> buf);
> PRE_MEM_RASCIIZ( "statfs(path)", ARG1 );
>
>
> Thanks the responses.
>
>
> Atalay
>
>
> On Thu, Apr 9, 2015 at 2:08 PM, Atalay Ozgovde <aoz...@ra...>
> wrote:
> This is essentially the same bug
> as:https://bugs.kde.org/show_bug.cgi?id=278057
>
> A patch was applied for this bug in version 3.7 and it is
> considered fixed.
> I am using version 3.10, I confirmed in the source code that
> the patch is applied. Valgrind still dread-locks when used to
> test an application that uses fuse in our environment. We are
> using 64bit Ubuntu 12.04LTS.
>
> Anybody knows if there is an easy fix?
>
>
> Thanks,
>
>
> Atalay
>
>
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Atalay O. <aoz...@ra...> - 2015-04-16 13:32:57
|
OK, makes sense, I'll recreate the patch using FUSE_COMPATIBLE_MAY_BLOCK()
instead and submit it to bugzilla with the new bug report.
Thanks,
Atalay
On Wed, Apr 15, 2015 at 6:04 PM, Philippe Waroquiers <
phi...@sk...> wrote:
> On Wed, 2015-04-15 at 16:35 -0400, Atalay Ozgovde wrote:
> > Upon tracing valgrind upon suggestions above I found two offending
> > system calls in my code: sys_newstat and sys_statfs. I also verified
> > deadlock lines by running valgrind with "vgdb" set and stepping
> > through the code.
> >
> > Following patch is the changed I did in valgrind to get these system
> > calls supported. Let me know if there is interest in applying the
> > patch in trunk, and if so I should submit this patch elsewhere.
> As Valgrind was already modified in the past to support fuse, I think
> we better fix the trunk.
> A small note:
> syscalls that have to be considered as blocking only for 'fuse reason'
> are marked with:
> FUSE_COMPATIBLE_MAY_BLOCK();
> and not with an unconditional
> *flags |= SfMayBlock;
> unless these syscalls must be considered as blocking
> even when not activating the --sim-hints=fuse-compatible hint.
>
> The best way to add a bug in bugzilla, with the patch.
> Thanks
> Philippe
>
> >
> >
> > --- coregrind/m_syswrap/syswrap-generic.c 2014-11-25
> > 14:41:20.000000000 -0500
> > +++
> /home/atalay/source/valgrind-3.10.1/coregrind/m_syswrap/syswrap-generic.c
> 2015-04-15 15:50:38.465388486 -0400
> > @@ -4101,6 +4101,8 @@
> > PRE_REG_READ2(long, "setreuid", vki_uid_t, ruid, vki_uid_t, euid);
> > }
> >
> > +
> > +
> > PRE(sys_setrlimit)
> > {
> > UWord arg1 = ARG1;
> > @@ -4160,6 +4162,7 @@
> >
> > PRE(sys_newstat)
> > {
> > + *flags |= SfMayBlock;
> > PRINT("sys_newstat ( %#lx(%s), %#lx )", ARG1,(char*)ARG1,ARG2);
> > PRE_REG_READ2(long, "stat", char *, file_name, struct stat *,
> > buf);
> > PRE_MEM_RASCIIZ( "stat(file_name)", ARG1 );
> > @@ -4173,6 +4176,7 @@
> >
> > PRE(sys_statfs)
> > {
> > + *flags |= SfMayBlock;
> > PRINT("sys_statfs ( %#lx(%s), %#lx )",ARG1,(char*)ARG1,ARG2);
> > PRE_REG_READ2(long, "statfs", const char *, path, struct statfs *,
> > buf);
> > PRE_MEM_RASCIIZ( "statfs(path)", ARG1 );
> >
> >
> > Thanks the responses.
> >
> >
> > Atalay
> >
> >
> > On Thu, Apr 9, 2015 at 2:08 PM, Atalay Ozgovde <aoz...@ra...>
> > wrote:
> > This is essentially the same bug
> > as:https://bugs.kde.org/show_bug.cgi?id=278057
> >
> > A patch was applied for this bug in version 3.7 and it is
> > considered fixed.
> > I am using version 3.10, I confirmed in the source code that
> > the patch is applied. Valgrind still dread-locks when used to
> > test an application that uses fuse in our environment. We are
> > using 64bit Ubuntu 12.04LTS.
> >
> > Anybody knows if there is an easy fix?
> >
> >
> > Thanks,
> >
> >
> > Atalay
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> > Develop your own process in accordance with the BPMN 2 standard
> > Learn Process modeling best practices with Bonita BPM through live
> exercises
> > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> > _______________________________________________ Valgrind-users mailing
> list Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
|
Thanks for helping keep SourceForge clean.
X