valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[João M. S. S. <joa...@gm...>]

> There is no (direct) use of the function args on line 118.
> Of course, it might be that e.g. an uninitialised arg (e.g. no_eras
> might be unitialised and get a random value 22) might result later in j
> or whatever being initialised.

You're right, I think I found it. In:

   tmp = INDEX_OF[lambda[j - 1]];

j gets = 22 but lambda is size 21.

This happens because no_eras = 22:

for (i = 1; i < no_eras; i++) {
   u = MODNN(PRIM*(NN-1-eras_pos[i]));
   for (j = i+1; j > 0; j--) {
     tmp = INDEX_OF[lambda[j - 1]];
     if(tmp != A0)
       lambda[j] ^= ALPHA_TO[MODNN(u + tmp)];
   }
}

I missed it before.

Thanks.

-- 
João M. S. Silva

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[João M. S. S. <joa...@gm...>]

> But the most probably culprits are either j or lambda[j-1]
> or whatever the INDEX_OF macro(is it a macro?) is doing behind
> what is visible.
> There is no (direct) use of the function args on line 118.
> Of course, it might be that e.g. an uninitialised arg (e.g. no_eras
> might be unitialised and get a random value 22) might result later in j
> or whatever being initialised.

I already tried get_vbits on j (size 4), lambda (size 21) and INDEX_OF = 
rs->index_of (size 32) and all of them seem initialized (represented 
with 0 by get_vbits).

I also tried --read-var-info=yes but as far as I can see there is no 
difference in the output.

-- 
João M. S. Silva

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[Philippe W. <phi...@sk...>]

On Tue, 2015-04-14 at 22:03 +0100, "João M. S. Silva" wrote:

> 
> Yes, but in some cases the sizeof indicates the size of the pointer (not 
> the size of the allocated memory). So I had to browse the code to get 
> the size of the allocations/structs involved.
or use 
(gdb) monitor v.info location <addr>

You might also better start your valgrind with
   --read-var-info=yes
That might give some more information in some cases
(valgrind will be slower to startup).

> OK, so it is not applicable to this case of uninitialized stack variables.
sg-check will not  help for such an uninit.

> 
> What is strange is that I never faced such a shortcoming in my own code. 
> In my code valgrind always points to the location of the error exactly. 
> Does this happen because this is a library that I link with? Or because 
> of the nature of the error?
Depends on what errors you had in your code.
Uninit errors can be more difficult to track than leaks or dangling
pointers, in particular because the origin of uninit data is not
precisely maintained.

Philippe

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[Philippe W. <phi...@sk...>]

On Tue, 2015-04-14 at 19:26 +0100, "João M. S. Silva" wrote:

> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000000060bdb6d in decode_rs_char (p=0x201aac50, data=0xffefff500 "",
>      eras_pos=0xffefff480, no_eras=22) at decode_rs.h:118
> 118		tmp = INDEX_OF[lambda[j - 1]];
> 
> I tried the get_vbits command in variables p, data, eras_pos and 
> no_eras. I had to manually find out the size of the corresponding 
> variables, since some of them are pointers or structs with pointer fields.
But the most probably culprits are either j or lambda[j-1]
or whatever the INDEX_OF macro(is it a macro?) is doing behind 
what is visible.
There is no (direct) use of the function args on line 118.
Of course, it might be that e.g. an uninitialised arg (e.g. no_eras
might be unitialised and get a random value 22) might result later in j
or whatever being initialised.

Philippe

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[João M. S. S. <joa...@gm...>]

> I do not understand. The below error is an uninitialised value error.
> Why do you say you cannot catch the errors ?

Valgrind points to them, but I don't seem to confirm the uninitialization.

> You just have to use monitor get_vbits at the time of the error
> to investigate more in depth where the error comes from,
> and if needed, relaunch the execution after having added some
> breakpoints earlier in the program flow, and again use get_vbits
> to try to understand where the uninit error comes from.

Easier said than done :)

I've tried but there are a lot of local variables:

   int retval;
   struct rs *rs = (struct rs *)p;
   int deg_lambda, el, deg_omega;
   int i, j, r,k;
   data_t u,q,tmp,num1,num2,den,discr_r;
   data_t lambda[NROOTS+1], s[NROOTS];	/* Err+Eras Locator poly
					 * and syndrome poly */
   data_t b[NROOTS+1], t[NROOTS+1], omega[NROOTS+1];
   data_t root[NROOTS], reg[NROOTS+1], loc[NROOTS];
   int syn_error, count;

and lines where they can be used before initialization: ~ 300.

> Yes, the monitor get_vbits only knows about address+length.
> So, you need to do something like
> (gdb)  p &myvar
> (gdb) p sizeof(myvar)
> and then use
> (gdb) monitor get_vbits <address> <size>
> to get the vbits.

Yes, but in some cases the sizeof indicates the size of the pointer (not 
the size of the allocated memory). So I had to browse the code to get 
the size of the allocations/structs involved.

> When valgrind reports that the origin of an uninit var is in a function,
> then it means it is one of the local variables of the function.
> Not the arguments of this function.

OK, that's why it is difficult to find this. Specially because it is a 
3rd party library. Since the line valgrind pinpoints is not 
accurate/relevant, we are in doubt about where the error comes from. 
(I'm not saying its valgrind's fault, of course, it already is an 
extremely useful tool, as is).

> If you want to detect buffer over or under run in stack and global
> variables, then yes, the experimental exp-sgcheck tool is your friend.

OK, so it is not applicable to this case of uninitialized stack variables.

What is strange is that I never faced such a shortcoming in my own code. 
In my code valgrind always points to the location of the error exactly. 
Does this happen because this is a library that I link with? Or because 
of the nature of the error?

Thanks.

-- 
João M. S. Silva

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[Philippe W. <phi...@sk...>]

On Tue, 2015-04-14 at 19:26 +0100, "João M. S. Silva" wrote:
> > What you can further do is to use the memcheck monitor commands to
> > examine the definedness of the variables used on the line where the
> > error is detected.
> >
> > See manual for more info
> > http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
> 
> Thanks, I didn't know about the "monitor get_vbits" command.
> 
> However, it seems I'm not able to catch any uninitialized variable.
I do not understand. The below error is an uninitialised value error.
Why do you say you cannot catch the errors ?
You just have to use monitor get_vbits at the time of the error
to investigate more in depth where the error comes from,
and if needed, relaunch the execution after having added some
breakpoints earlier in the program flow, and again use get_vbits
to try to understand where the uninit error comes from.

>  I 
> also get this kind of error in another library:
> 
> ==17108== Use of uninitialised value of size 8
> ==17108==    at 0x60BDB6D: decode_rs_char (decode_rs.h:118)
> ==17108==    by 0x41D9B5: Code::decode(unsigned char*, int*, unsigned 
> int, bool) (Code.cpp:114)
> ==17108==    by 0x41E6D8: Code::extract(char*, char*, std::string&, 
> unsigned int) (Code.cpp:326)
> ==17108==    by 0x4060E4: main (test.cpp:178)
> ==17108==  Uninitialised value was created by a stack allocation
> ==17108==    at 0x60BD480: decode_rs_char (decode_rs_char.c:15)
> 
> And with vgdb I get this in gdb:
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000000060bdb6d in decode_rs_char (p=0x201aac50, data=0xffefff500 "",
>      eras_pos=0xffefff480, no_eras=22) at decode_rs.h:118
> 118		tmp = INDEX_OF[lambda[j - 1]];
Yes that is the way the valgrind gdbserver reports to gdb that there is
an error that the user can look at.

> 
> I tried the get_vbits command in variables p, data, eras_pos and 
> no_eras. I had to manually find out the size of the corresponding 
> variables, since some of them are pointers or structs with pointer fields.
Yes, the monitor get_vbits only knows about address+length.
So, you need to do something like
(gdb)  p &myvar
(gdb) p sizeof(myvar)
and then use   
(gdb) monitor get_vbits <address> <size> 
to get the vbits.

> 
> I seem to have computed the corresponding sizes correctly since if I use 
> a size 1 byte larger in the vget_bits command I get an "unaddressable" 
> warning (also represented by the underscore).
> 
> When you say "local variables" you mean the variables the function 
> received as argument or all variables defined inside the function?
When valgrind reports that the origin of an uninit var is in a function,
then it means it is one of the local variables of the function.
Not the arguments of this function.

> 
> I think I know the answer, since I remember having discussed this in the 
> mailing list: all variables inside the function are local, thus 
> allocated in the stack, so valgrind is not yet able to detect errors in 
> them? Can you confirm this?
Valgrind memcheck is able to report some errors originating from local
vars, namely the uninit errors.
> 
> I have to try using exp-sgcheck, right?
If you want to detect buffer over or under run in stack and global
variables, then yes, the experimental exp-sgcheck tool is your friend.

Philippe

Re: [Valgrind-users] Bug / typo saving altivec register r25

[Philippe W. <phi...@sk...>]

On Mon, 2015-04-13 at 16:28 +0000, Lerner, Dave wrote:
> I noticed what looks like a typo in the code for the powerpc altivec register set save/restore logic.  I found the bug in both 3.10.1 and 3.9.
> 
> A suggested patch is shown below.
Thanks for the analysis and the patch.

I think it is better to file a bug in bugzilla and attach
the patch. The follow-up can then be done by the
valgrind ppc maintainer.

Philippe

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[João M. S. S. <joa...@gm...>]

> What you can further do is to use the memcheck monitor commands to
> examine the definedness of the variables used on the line where the
> error is detected.
>
> See manual for more info
> http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands

Thanks, I didn't know about the "monitor get_vbits" command.

However, it seems I'm not able to catch any uninitialized variable. I 
also get this kind of error in another library:

==17108== Use of uninitialised value of size 8
==17108==    at 0x60BDB6D: decode_rs_char (decode_rs.h:118)
==17108==    by 0x41D9B5: Code::decode(unsigned char*, int*, unsigned 
int, bool) (Code.cpp:114)
==17108==    by 0x41E6D8: Code::extract(char*, char*, std::string&, 
unsigned int) (Code.cpp:326)
==17108==    by 0x4060E4: main (test.cpp:178)
==17108==  Uninitialised value was created by a stack allocation
==17108==    at 0x60BD480: decode_rs_char (decode_rs_char.c:15)

And with vgdb I get this in gdb:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000060bdb6d in decode_rs_char (p=0x201aac50, data=0xffefff500 "",
     eras_pos=0xffefff480, no_eras=22) at decode_rs.h:118
118		tmp = INDEX_OF[lambda[j - 1]];

I tried the get_vbits command in variables p, data, eras_pos and 
no_eras. I had to manually find out the size of the corresponding 
variables, since some of them are pointers or structs with pointer fields.

I seem to have computed the corresponding sizes correctly since if I use 
a size 1 byte larger in the vget_bits command I get an "unaddressable" 
warning (also represented by the underscore).

When you say "local variables" you mean the variables the function 
received as argument or all variables defined inside the function?

I think I know the answer, since I remember having discussed this in the 
mailing list: all variables inside the function are local, thus 
allocated in the stack, so valgrind is not yet able to detect errors in 
them? Can you confirm this?

I have to try using exp-sgcheck, right?

Thanks.

-- 
João M. S. Silva

Re: [Valgrind-users] Where is the list of supported clang versions?

[Calvin C. <lin...@gm...>]

I see.




It appears that I was looking at the right file and the right `case` line then.  Just wasn’t sharp enough with my bash-fu to have spotted `applellvm-5.1|applellvm-6.*`.




Thank you.




Btw... any interest to switch to git? I am so rusty with svn too. Heh.


—
Sent from Mailbox

On Tue, Apr 14, 2015 at 5:13 PM, Julian Seward <js...@ac...> wrote:

>> r15088 compiles correctly without complaining about clang 6.1.0.  
>> Just curious — does anyone know where this was specified to allow the
> compilation to proceed?
> It was actually 15088 that enabled it.  Try 'svn diff -c15088' to see it.
> J

Re: [Valgrind-users] Where is the list of supported clang versions?

[Julian S. <js...@ac...>]

> r15088 compiles correctly without complaining about clang 6.1.0.  
> Just curious — does anyone know where this was specified to allow the
compilation to proceed?

It was actually 15088 that enabled it.  Try 'svn diff -c15088' to see it.

J

Re: [Valgrind-users] Where is the list of supported clang versions?

[Calvin C. <lin...@gm...>]

My mistake. Hit the reply-to on the wrong part of the thread and so identified Julian wrongly as John.  Thanks Julian.




In any case, I do need to figure out autotools, automake. Not familiar with autotools at all so I can’t figure out how to fix the problem at r14960 earlier.


—
Sent from Mailbox

On Tue, Apr 14, 2015 at 4:43 PM, Julian Seward <js...@ac...> wrote:

> On 14/04/15 02:40, Lin Chuan wrote:
>> I would like to get automake to accept a higher version of clang (6.1.0)
>> and give it a go at installing Valgrind against this newer version from
>> Xcode 6.3.  Where do I make these changes?
> I think this was fixed yesterday morning, in svn r15088.  svn up and
> try again.
> J

Re: [Valgrind-users] Where is the list of supported clang versions?

[Calvin C. <lin...@gm...>]

Thank you, John.




r15088 compiles correctly without complaining about clang 6.1.0.  Just curious — does anyone know where this was specified to allow the compilation to proceed?


—
Sent from Mailbox

On Tue, Apr 14, 2015 at 9:33 AM, John Reiser <jr...@bi...> wrote:

>> I managed to get the trunk version of Valgrind install correctly for Xcode 6.2 (clang 6.0.2 iirc) but after an upgrade, `./configure` stops me from continuing.
>>
>> I would like to get automake to accept a higher version of clang (6.1.0) and give it a go at installing Valgrind against this newer version from Xcode 6.3.  Where do I make these changes?
> Depending on how far back in the pipeline you wish to go: configure, configure.ac, configure.in.
> Valgrind's use of these files follows the usual conventions.
> ------------------------------------------------------------------------------
> 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

Re: [Valgrind-users] Where is the list of supported clang versions?

[John R. <jr...@bi...>]

> I managed to get the trunk version of Valgrind install correctly for Xcode 6.2 (clang 6.0.2 iirc) but after an upgrade, `./configure` stops me from continuing.
>
> I would like to get automake to accept a higher version of clang (6.1.0) and give it a go at installing Valgrind against this newer version from Xcode 6.3.  Where do I make these changes?

Depending on how far back in the pipeline you wish to go: configure, configure.ac, configure.in.
Valgrind's use of these files follows the usual conventions.

[Valgrind-users] Where is the list of supported clang versions?

[Lin C. <lin...@gm...>]

Hi,

I managed to get the trunk version of Valgrind install correctly for Xcode
6.2 (clang 6.0.2 iirc) but after an upgrade, `./configure` stops me from
continuing.

I would like to get automake to accept a higher version of clang (6.1.0)
and give it a go at installing Valgrind against this newer version from
Xcode 6.3.  Where do I make these changes?

Thanks
-- 
http://calvinx.com <http://www.calvinx.com>

Re: [Valgrind-users] valgrind out of memory error

[Tom H. <to...@co...>]

On 13/04/15 21:57, Zhu, Yanwen wrote:

> Can you please confirm if mabi=n32 is currently supported by valgrind or not in MIPS64 platform?  My Linux kernel is 64-bits, but our applications have to be built for 32-bits.  So I need to get valgrind with mabi=n32 to work in our platform.

No, the n32 ABI is not supported currently. There are patches in the bug 
tracker for it (https://bugs.kde.org/show_bug.cgi?id=345763) but they 
have not been applied yet.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] valgrind out of memory error

[Zhu, Y. <Yan...@vi...>]

Julian or Philippe,

Can you please confirm if mabi=n32 is currently supported by valgrind or not in MIPS64 platform?  My Linux kernel is 64-bits, but our applications have to be built for 32-bits.  So I need to get valgrind with mabi=n32 to work in our platform.

Thanks,
Yanwen

-----Original Message-----
From: Zhu, Yanwen 
Sent: Monday, April 13, 2015 9:35 AM
To: 'js...@ac...'; Philippe Waroquiers
Cc: val...@li...
Subject: RE: [Valgrind-users] valgrind out of memory error

Even if I build valgrind with page size of 4 which matches my kernel page size, I'm still seeing the same problem.

I am building valgrind with option -mabi=n32 for mips64.  In the thread below, someone says currently valgrind only supports -mabi=n64 for mips64, is that true?
http://valgrind.10908.n7.nabble.com/Valgrind-13854-Cross-compiling-for-Cavium-MIPS64-N32-ABI-td48980.html

Thanks,
Yanwen

-----Original Message-----
From: Julian Seward [mailto:js...@ac...] 
Sent: Monday, April 13, 2015 7:17 AM
To: Philippe Waroquiers; Zhu, Yanwen
Cc: val...@li...
Subject: Re: [Valgrind-users] valgrind out of memory error


> A possible cause could be the page size: as I understand, mips have 
> different page size setup.
> If your valgrind has  been compiled with a  pagesize not matching your 
> kernel/setup, then maybe Valgrind might ask wrongly aligned mmap 
> requests, giving then this EINVAL

Yes, that would be my guess too.  At the time the failure happened there was still a block of 1759MB available:

| --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1
[..]
| --1956:0:aspacem 6: 0011948000-007f880fff 1759m

so it is clearly not the case that it has really run out of memory.

J

[Valgrind-users] Bug / typo saving altivec register r25

[Lerner, D. <dav...@wi...>]

I noticed what looks like a typo in the code for the powerpc altivec register set save/restore logic.  I found the bug in both 3.10.1 and 3.9.

A suggested patch is shown below.
Regards,
Dave

=====================================
Fix typo saving altivec register v24

Fix a typo that saved vector register 25 in the slot reserved for
register 24.  Verified by examining the code that restores v24 from
the same 16 byte offset (112) at label LafterFP9.

Signed-off-by: Dave Lerner <dle...@gm...>

diff --git a/coregrind/m_dispatch/dispatch-ppc32-linux.S b/coregrind/m_dispatch/dispatch-ppc32-linux.S
index 6457219..3c246ef 100644
--- a/coregrind/m_dispatch/dispatch-ppc32-linux.S
+++ b/coregrind/m_dispatch/dispatch-ppc32-linux.S
@@ -158,7 +158,7 @@ LafterFP1:
         li      6,128
         stvx    25,6,1
         li      6,112
-        stvx    25,6,1
+        stvx    24,6,1
         li      6,96
         stvx    23,6,1
         li      6,80
=================================

Re: [Valgrind-users] fuse filesystem syscall deadlocks

[Atalay O. <aoz...@ra...>]

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
>
>
>

Re: [Valgrind-users] valgrind out of memory error

[Zhu, Y. <Yan...@vi...>]

Even if I build valgrind with page size of 4 which matches my kernel page size, I'm still seeing the same problem.

I am building valgrind with option -mabi=n32 for mips64.  In the thread below, someone says currently valgrind only supports -mabi=n64 for mips64, is that true?
http://valgrind.10908.n7.nabble.com/Valgrind-13854-Cross-compiling-for-Cavium-MIPS64-N32-ABI-td48980.html

Thanks,
Yanwen

-----Original Message-----
From: Julian Seward [mailto:js...@ac...] 
Sent: Monday, April 13, 2015 7:17 AM
To: Philippe Waroquiers; Zhu, Yanwen
Cc: val...@li...
Subject: Re: [Valgrind-users] valgrind out of memory error


> A possible cause could be the page size: as I understand, mips have 
> different page size setup.
> If your valgrind has  been compiled with a  pagesize not matching your 
> kernel/setup, then maybe Valgrind might ask wrongly aligned mmap 
> requests, giving then this EINVAL

Yes, that would be my guess too.  At the time the failure happened there was still a block of 1759MB available:

| --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1
[..]
| --1956:0:aspacem 6: 0011948000-007f880fff 1759m

so it is clearly not the case that it has really run out of memory.

J

Re: [Valgrind-users] valgrind out of memory error

[Julian S. <js...@ac...>]

> A possible cause could be the page size: as I understand,
> mips have different page size setup.
> If your valgrind has  been compiled with a  pagesize
> not matching your kernel/setup, then maybe Valgrind might ask
> wrongly aligned mmap requests, giving then this EINVAL

Yes, that would be my guess too.  At the time the failure happened
there was still a block of 1759MB available:

| --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1
[..]
| --1956:0:aspacem 6: 0011948000-007f880fff 1759m

so it is clearly not the case that it has really run out of memory.

J

Re: [Valgrind-users] fuse filesystem syscall deadlocks

[Julian S. <js...@ac...>]

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

Re: [Valgrind-users] valgrind out of memory error

[Philippe W. <phi...@sk...>]

On Fri, 2015-04-10 at 21:39 +0000, Zhu, Yanwen wrote:
> What argument should I give to strace in order to get syscall args?
No idea. 
On my linux box, a normal strace gives the mmap args.
Try to look at
    strace --help
or 
    man strace

Philippe

Re: [Valgrind-users] valgrind out of memory error

[Zhu, Y. <Yan...@vi...>]

What argument should I give to strace in order to get syscall args?

Yanwen

-----Original Message-----
From: Philippe Waroquiers [mailto:phi...@sk...] 
Sent: Friday, April 10, 2015 5:33 PM
To: Zhu, Yanwen
Cc: val...@li...
Subject: RE: [Valgrind-users] valgrind out of memory error

On Fri, 2015-04-10 at 21:24 +0000, Zhu, Yanwen wrote:
> Philippe,
> 
> Please see the attached file for
> strace -f valgrind -v -v -v -d -d -d
> output
The trace confirms that the mmap syscall is failing:
n64_write(--1953:1:main     Starting the dynamic memory manager
)                             = 54
n64_mmap()                              = -1 EINVAL (Invalid argument)

But we do not see the syscall args.
Maybe you need to give an argument to strace to have them ?


A possible cause could be the page size: as I understand, mips have different page size setup.
If your valgrind has  been compiled with a  pagesize not matching your kernel/setup, then maybe Valgrind might ask wrongly aligned mmap requests, giving then this EINVAL

You could then configure/compile valgrind, specifying the correct page size e.g. use the below configure option:
  --with-pagesize=        override detected page size (4, 16 or 64)

Philippe

Re: [Valgrind-users] valgrind out of memory error

[Philippe W. <phi...@sk...>]

On Fri, 2015-04-10 at 21:24 +0000, Zhu, Yanwen wrote:
> Philippe,
> 
> Please see the attached file for
> strace -f valgrind -v -v -v -d -d -d
> output
The trace confirms that the mmap syscall is failing:
n64_write(--1953:1:main     Starting the dynamic memory manager
)                             = 54
n64_mmap()                              = -1 EINVAL (Invalid argument)

But we do not see the syscall args.
Maybe you need to give an argument to strace to have them ?


A possible cause could be the page size: as I understand,
mips have different page size setup.
If your valgrind has  been compiled with a  pagesize
not matching your kernel/setup, then maybe Valgrind might ask
wrongly aligned mmap requests, giving then this EINVAL

You could then configure/compile valgrind, specifying the correct
page size e.g. use the below configure option:
  --with-pagesize=        override detected page size (4, 16 or 64)

Philippe

Re: [Valgrind-users] valgrind out of memory error

[Zhu, Y. <Yan...@vi...>]

Philippe,

Please see the attached file for
strace -f valgrind -v -v -v -d -d -d
output

Thanks,
Yanwen

-----Original Message-----
From: Philippe Waroquiers [mailto:phi...@sk...] 
Sent: Friday, April 10, 2015 4:55 PM
To: Zhu, Yanwen
Cc: val...@li...
Subject: RE: [Valgrind-users] valgrind out of memory error

On Fri, 2015-04-10 at 20:27 +0000, Zhu, Yanwen wrote:
> Also, I just looked at online:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchiv
> e.com_valgrind-2Dusers-40lists.sourceforge.net_msg02027.html&d=AwICaQ&
> c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=rAkQlM2psJuhxCfM2RLlYF
> 9VSPgnp4OE1EdTCMEFlmc&m=qQDnkR1m0dMIHitUxu0e-9pkjZ-YcvHep9EUNsPqef8&s=
> xVzNkqFJ9Olvmbh_F02lcPlsblIrgHs-sufLHrICw58&e=
> 
> Is it a permission problem?
It does not look like.
But in any case, it looks like you are running Valgrind as root.
This is very unusual, and should not be needed.

Apart of that, the trace you gave shows that initialisation of the Valgrind malloc lib fails.
A succesful startup of the Valgrind malloc lib would give:
--13999:1:    main Starting the dynamic memory manager
--13999:1:mallocfr newSuperblock at 0x61C35000 (pszB 4194288)  owner VALGRIND/core

So, can you redo the -v -v -v -d -d -d experiment, but using strace to trace it i.e.
   strace -f valgrind -v -v -v -d -d -d

A succesful startup results in a trace such as:
[pid 13912] write(2, "--13912:1:    main Starting the "..., 55--13912:1:    main Starting the dynamic memory manager
) = 55
[pid 13912] mmap2(0x61e41000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x61e41000
[pid 13912] getpid()                    = 13912
[pid 13912] write(2, "--13912:1:mallocfr newSuperblock"..., 83--13912:1:mallocfr newSuperblock at 0x61E41000 (pszB 4194288)  owner VALGRIND/core
) = 83

which shows the mmap syscall, and the resulting superblock trace.

So, can you redo the trial with strace, and give the equivalent traces ?
Probably the mmap fails. We can then see which address has been chosen by aspacemgr, the resulting errno, and all that could explain the failure

Philippe