valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] how to kill a target program right after memcheck finds an memory error

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

On Sat, 2015-04-25 at 00:39 +0900, sean jinu wrote:

> 
>    exit(0);      // this one line is added to kill both valgrind
> itself and target as its child
Valgrind cannot use any glibc function, so there is a re-implementation
of a subset of libc in Valgrind.
The equivalent of exit() is called VG_(exit)().
See pub_tool_libcassert.h


> waiting for any comments or idea on this issue.
It is not very clear what is the advantage to exit at the first error,
so the addition of this feature is unlikely.

Valgrind is usually able to give valid information after the first
error (and there is no 'avalanche' of errors caused by the first error).
That means that with one run, you get several errors to fix,
rather than only one single error, if you would exit after the first
error.

Note also that you can control what exit code Valgrind uses, if
an error is detected:
--error-exitcode=<number> exit code to return if errors found [0=disable]

Philippe

[Valgrind-users] how to kill a target program right after memcheck finds an memory error

[sean j. <jin...@gm...>]

Hello,

I want to kill a target binary immediately after memcheck finds an memory
error.

Is there any options to do that?

I checked options list but there seemed no option for that.

As another attempt, I tried to slightly modify source code in memcheck
(mc_errors.c) like this.

#include <stdlib.h>
void MC_(pp_Error) ( Error* err )
{
   const Bool xml  = VG_(clo_xml); /* a shorthand */
   MC_Error* extra = VG_(get_error_extra)(err);

   exit(0);      // this one line is added to kill both valgrind itself and
target as its child
   ...
}

but failed to build with the modification, emitting this error message:

Undefined symbols for architecture x86_64:
  "_exit", referenced from:


waiting for any comments or idea on this issue.

thanks.

Re: [Valgrind-users] Can valgrind print the used "uninitialized value" and its size?

[ISHIKAWA,chiaki <ish...@yk...>]

Hi,

On 2015/04/24 4:10, Philippe Waroquiers wrote:
> On Fri, 2015-04-24 at 01:13 +0900, ISHIKAWA,chiaki wrote:
>
>> Can valgrind print value of used uninitialized memory location, say,
>> something along the suggested manner below?
> I am not a specialist in the way memcheck does all that,
> but at first sight, I do not see major difficulties to implement that.
> However, as far as I can see, it would imply to add a new PARAM to all
> the error reporting helpers, which means the generated code will
> grow and/or be less efficient. Growing the generated code just for
> that seems not that attractive.

I see. I thought it was simply adding some print code somewhere and 
knowledgeable person could do this in a matter of a day, but
I did not realize there is this size/speed implications.

>
> As an alternative, when an error is encountered, you can debug
> your program (using vgdb) at the moment of the error, and e.g.
> examine the value of the variables and/or the definedness of
> what is used in the conditional jump.

I will try this approach with this particular issue I found lately.

> Philippe

Thank you for the pointers.

Chiaki

Re: [Valgrind-users] Can valgrind print the used "uninitialized value" and its size?

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

On Fri, 2015-04-24 at 01:13 +0900, ISHIKAWA,chiaki wrote:

> Can valgrind print value of used uninitialized memory location, say,
> something along the suggested manner below?
I am not a specialist in the way memcheck does all that,
but at first sight, I do not see major difficulties to implement that.
However, as far as I can see, it would imply to add a new PARAM to all
the error reporting helpers, which means the generated code will
grow and/or be less efficient. Growing the generated code just for
that seems not that attractive.

As an alternative, when an error is encountered, you can debug
your program (using vgdb) at the moment of the error, and e.g.
examine the value of the variables and/or the definedness of
what is used in the conditional jump.

Philippe

Re: [Valgrind-users] Can valgrind print the used "uninitialized value" and its size?

[Maurice v. S. <ma...@bl...>]

Hi Chiaki, 

If you use --track-origins=yes, then valgrind will report where the variable was first allocated (or put on the stack). 

That's usually enough to figure out which it is. 

][ Maurice van Swaaij, Blue Sky Studios ][ 

----- Original Message -----

| From: "chiaki ISHIKAWA" <ish...@yk...>
| To: val...@li...
| Sent: Thursday, April 23, 2015 12:13:38 PM
| Subject: [Valgrind-users] Can valgrind print the used "uninitialized
| value" and its size?

| Hi,

| I was running mozilla TB and found a message during a test run

| ==20163== Conditional jump or move depends on uninitialised value(s)
| ==20163== at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
| void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)
| ...

| so there is an uninitialized usage.

| In this particular instance, I realized that it would be really great
| to know the value of this uninitialized memory (turns out to be
| automatic variable on the stack.)
| so that I can learn what has happened to the subsequent processing.
| Can the uninitialized value was zero or not, for example?

| Can valgrind print value of used uninitialized memory location, say,
| something along the suggested manner below?

| I use the above example:

| ==20163== Conditional jump or move depends on uninitialised value(s)
| ==20163== The value used was: 0xdeadbeaf (4 bytes)
| ==20163== at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
| void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)
| ...

| or maybe considering the possibility of byte block:

| ==20163== Conditional jump or move depends on uninitialised value(s)
| ==20163== The value used started with 0xde 0xad 0xbe 0xaf 0xaa 0xbb
| 0xcc ... (up to the minimum of first N octets or the size of the
| data,
| maybe N can be 16 , etc.)
| ==20163== at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
| void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)

| I believe this simple addition makes the detection very useful
| because it would make creating the suggested patch easier by knowing
| why a program that has been used so long had a hidden issue for so
| many
| years.

| Thank you for sharing this great tool with the programming community.

| Best Regards,
| Chiaki Ishikawa

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

[Valgrind-users] Can valgrind print the used "uninitialized value" and its size?

[ISHIKAWA,chiaki <ish...@yk...>]

Hi,

I was running mozilla TB and found a message during a test run


==20163== Conditional jump or move depends on uninitialised value(s)
==20163==    at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)
  ...

so there is an uninitialized usage.

In this particular instance, I  realized that it would be really great
to know the value of this uninitialized memory (turns out to be
automatic variable on the stack.)
so that I can learn what has happened to the subsequent processing.
Can the uninitialized value was zero or not, for example?

Can valgrind print value of used uninitialized memory location, say,
something along the suggested manner below?

I use the above example:

  ==20163== Conditional jump or move depends on uninitialised value(s)
  ==20163== The value used was: 0xdeadbeaf (4 bytes)
  ==20163==    at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)
  ...

or maybe considering the possibility of byte block:

  ==20163== Conditional jump or move depends on uninitialised value(s)
  ==20163== The value used started with 0xde 0xad 0xbe 0xaf 0xaa 0xbb
0xcc ... (up to the minimum of first N octets or the size of the data,
maybe N can be 16 , etc.)
  ==20163==    at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)

I believe this simple addition makes the detection very useful
because it would make creating the suggested patch easier by knowing
why a program that has been used so long had a hidden issue for so many
years.

Thank you for sharing this great tool with the programming community.

Best Regards,
Chiaki Ishikawa

[Valgrind-users] Reg : Posting Valgrind Queries to lists.

[evv r. <evv...@gm...>]

Hello,


I Would like to know the process to test IOS Project using valgrind to
check  memory issues.

It will be helpful,If you provide me clear info regarding this.

Thanks in advance.

-- 


Thanks & Regards
E.V.V.Rajesh.
+91-8099916975

Re: [Valgrind-users] Query on Numa architecture friendly memory allocation profiling

[Josef W. <Jos...@gm...>]

Am 21.04.2015 um 11:35 schrieb rajsing mohapatro:
> This mail is to check if currently Valgrind  provides any tool/option
> which can be utilized to do profiling of a running process to know what
> % of memory allocation made by the process is NUMA optimized.

Not that I know of.

However, physical memory allocation as well as thread placement depends
on (dynamic) OS behavior. Thus, it may be impossible for a VG tool to
maintain a consistent view with the OS in general.

This said, applications may opt in to control thread placement
(sched_setaffinity), and may assume a "first touch policiy" for physical
memory allocation (ie. on first write to a memory page, this page gets
allocated in the memory module of the socket on which the current thread
is running on).

Cheers,
Josef


 By "NUMA
> optimized" allocation I mean, "if a process running on a processor of
> specific Node then through out its lifetime what amount of memory it
> allocates from local node(which is NUMA optimized way) and what % of
> allocation it make from remote NUMA node(which is not optimized way due
> to the latency overhead involved).
>  
> Benefits:
> This report will provide a good understanding of if a process is able to
> make full use of NUMA architecture performance benefits in terms of
> memory allocation. If not then it will allow the developer/Admins to
> fine tune their process/applications to be NUMA friendly in-terms of
> memory allocations.
>  
> Regards,
> Rajsing
>  
>  
> 
>  
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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
> 

[Valgrind-users] Query on Numa architecture friendly memory allocation profiling

[rajsing m. <raj...@ya...>]

   
 

Hi there, This mail is to check if currently Valgrind  provides any tool/option which can be utilized to do profiling of a running process to know what % of memory allocation made by the process is NUMA optimized. By "NUMA optimized" allocation I mean, "if a process running on a processor of specific Node then through out its lifetime what amount of memory it allocates from local node(which is NUMA optimized way) and what % of allocation it make from remote NUMA node(which is not optimized way due to the latency overhead involved). Benefits:This report will provide a good understanding of if a process is able to make full use of NUMA architecture performance benefits in terms of memory allocation. If not then it will allow the developer/Admins to fine tune their process/applications to be NUMA friendly in-terms of memory allocations. Regards,Rajsing  
 

   

[Valgrind-users] Invalid write at _dl_start_user

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

I'm seeing the following errors when running Valgrind 3.10.1 on MIPS64 Cavium OCTEON:

# valgrind uia_init
==1932== Memcheck, a memory error detector
==1932== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1932== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==1932== Command: uia_init
==1932==
==1932== Invalid write of size 4
==1932==    at 0x4001628: _dl_start_user (in /lib/ld-2.16.so.new)
==1932==    by 0x40015B8: __start (in /lib/ld-2.16.so.new)
==1932==  Address 0x7e6afc78 is on thread 1's stack
==1932==  8 bytes below stack pointer
==1932==

And Valgrind is hung from there.

Anyone has any ideas?

Thanks,
Yanwen

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

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

> Finally, effectively, memcheck knows where a ptr points
> (if the ptr is valid).
> So, it should be possible to write a gdb command (probably difficult to
> do, the gdb macro language is not very powerful) or a python extension
> to do a more intelligent get_vbits which would use
>    the type info known by gdb
>   and/or
>    monitor v.info location <address>
> to have an idea about the size of the block.
> and then do the correct monitor get_vbits command.
> Anybody volunteering ?
> We could add a file with 'various valgrind related gdb python extension'
> as part of the Valgrind distribution.

I'm of course ignorant about how memcheck works, but if it checks for 
out-of-bounds accesses, by knowing the size of each allocation (by 
wrapping malloc or so), wouldn't it be possible for valgrind to pinpoint 
the error directly, instead of having to recur to gdb?

I mean, if valgrind is able to signal with 0 or 1 if a byte was 
initialized (monitor get_vbits) then it should be able to tell the user 
which variable was not initialized?

Unless it works on the memory space level, not on the variable level... OK.

-- 
João M. S. Silva

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

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

On Thu, 2015-04-16 at 13:24 +0100, "João M. S. Silva" wrote:
> > I defined a gdb-macro for this:
> >
> > define get_vbits
> >    printf "# mon get_vbits 0x%lx 0x%lx\n" , &$arg0 , sizeof($arg0)
> >    eval "mon get_vbits 0x%lx 0x%lx" , &$arg0 , sizeof($arg0)
> > end
> >
> > Then I can run:
> > (gdb) get_vbits i_Cond
> > # mon get_vbits 0xffefff8bf 0x1
> > 00
> > (gdb)
> 
> Thanks for the hints. The sizeof() only works for variables, not 
> pointers, right?
Yes, it works for pointer. sizeof of a pointer returns the size of
the pointer :). So, 4 or 8 bytes, depending on the arch.
If the pointer is to a fixed size known struct, then you should
be able to use (I did not try).
     get_vbits *pointer
Finally, effectively, memcheck knows where a ptr points
(if the ptr is valid).
So, it should be possible to write a gdb command (probably difficult to
do, the gdb macro language is not very powerful) or a python extension
to do a more intelligent get_vbits which would use
  the type info known by gdb
 and/or
  monitor v.info location <address>
to have an idea about the size of the block.
and then do the correct monitor get_vbits command.
Anybody volunteering ?
We could add a file with 'various valgrind related gdb python extension'
as part of the Valgrind distribution.

> > I think there was also some option to switch valgrind so that the
> > definedness of registers can be checked: --vgdb-shadow-registers=yes
Yes, when giving this option, you can examine the definedness of a
register by printing its shadow 1 register.
For example, 
   p $eaxs1
shows the definedness of the eax register.

See
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-shadowregisters
and
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands

Philippe

Re: [Valgrind-users] fuse filesystem syscall deadlocks

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

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

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

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

> I defined a gdb-macro for this:
>
> define get_vbits
>    printf "# mon get_vbits 0x%lx 0x%lx\n" , &$arg0 , sizeof($arg0)
>    eval "mon get_vbits 0x%lx 0x%lx" , &$arg0 , sizeof($arg0)
> end
>
> Then I can run:
> (gdb) get_vbits i_Cond
> # mon get_vbits 0xffefff8bf 0x1
> 00
> (gdb)

Thanks for the hints. The sizeof() only works for variables, not 
pointers, right?

gdb should not know about the size of the allocated memory, but valgrind 
should know that, since it checks for out-of-bounds access. Is this correct?

> For the case above, you should check the instruction triggering the error.
> (gdb) x/i $rip
>
> Then you know in what register to look for. with the complete
> disassembly you might be able to track down what it exactly was.
> Then look near the problematic instruction.
> (gdb) disassemble /m
>
> I think there was also some option to switch valgrind so that the
> definedness of registers can be checked: --vgdb-shadow-registers=yes

-- 
João M. S. Silva

Re: [Valgrind-users] fuse filesystem syscall deadlocks

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

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

[Valgrind-users] vex mips->IR: unhandled instruction bytes

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

Has anyone seen this error in MIPS64 platform running Valgrind 3.10.1?

# valgrind /var/www/cgi-bin/view_status.cgi
==1957== Memcheck, a memory error detector
==1957== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1957== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==1957== Command: /var/www/cgi-bin/view_status.cgi
==1957==
vex mips->IR: unhandled instruction bytes: 0xD8 0x5D 0x4 0x16
==1957== valgrind: Unrecognised instruction at address 0x4002484.
==1957==    at 0x4002484: dl_main (rtld.c:1301)
==1957==    by 0x400243C: dl_main (rtld.c:1286)
==1957== Your program just tried to execute an instruction that Valgrind
==1957== did not recognise.  There are two possible reasons for this.
==1957== 1. Your program has a bug and erroneously jumped to a non-code
==1957==    location.  If you are running Memcheck and you just saw a
==1957==    warning about a bad jump, it's probably your program's fault.
==1957== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1957==    i.e. it's Valgrind's fault.  If you think this is the case or
==1957==    you are not sure, please let us know and we'll try to fix it.
==1957== Either way, Valgrind will now raise a SIGILL signal which will
==1957== probably kill your program.
==1957==
==1957== Process terminating with default action of signal 4 (SIGILL)
==1957==  Illegal opcode at address 0x4002484
==1957==    at 0x4002484: dl_main (rtld.c:1301)
==1957==    by 0x400243C: dl_main (rtld.c:1286)
==1957==
==1957== HEAP SUMMARY:
==1957==     in use at exit: 0 bytes in 0 blocks
==1957==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1957==
==1957== All heap blocks were freed -- no leaks are possible
==1957==
==1957== For counts of detected and suppressed errors, rerun with: -v
==1957== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction

Thanks,
Yanwen

Re: [Valgrind-users] fuse filesystem syscall deadlocks

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

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

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

[Matthias S. <zz...@ge...>]

On 14.04.2015 21:24, Philippe Waroquiers wrote:
> 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 defined a gdb-macro for this:

define get_vbits
  printf "# mon get_vbits 0x%lx 0x%lx\n" , &$arg0 , sizeof($arg0)
  eval "mon get_vbits 0x%lx 0x%lx" , &$arg0 , sizeof($arg0)
end

Then I can run:
(gdb) get_vbits i_Cond
# mon get_vbits 0xffefff8bf 0x1
00
(gdb)

For the case above, you should check the instruction triggering the error.
(gdb) x/i $rip

Then you know in what register to look for. with the complete
disassembly you might be able to track down what it exactly was.
Then look near the problematic instruction.
(gdb) disassemble /m

I think there was also some option to switch valgrind so that the
definedness of registers can be checked: --vgdb-shadow-registers=yes

Regards
Matthias

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[John O. <joh...@cl...>]

Hi Guys,
Thanks for the feedback, I will investigate further regarding the file
system, the system is built using Buildroot, so I will poke around there too
see if I can get to the bottom of it.

Regards


-----Original Message-----
From: Julian Seward [mailto:js...@ac...] 
Sent: 15 April 2015 15:13
To: Florian Krohm; John OSullivan; val...@li...
Subject: Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

On 15/04/15 16:03, Florian Krohm wrote:

> This isn't sane, because for an ANON segment we should have d=0 and 
> i=0 and o=0.
> Clearly, this is not an ANON segment but a file segment.
> 
> I suggest to change the condition on line 3248 in aspacemgr-linux.c 
> (refering to 3.10.1 sources) to if (1) and rerun. That way we can see 
> the contents of /proc/self/maps and can deduce why d == 0  (it should 
> be != 0).

Ah, good point.

So, d is the device number, right?  If that's so, then the problem is likely
because memcheck-arm-linux is on some unusual, hacky, etc, filesystem, and
the device numbers are zero, when they shouldn't be.

And in fact, you can see that in the /proc/self/maps output that John showed
in his first message:

00008000-00106000 r-xp 00000000 00:00 8773       /bin/busybox
0010e000-0010f000 rw-p 000fe000 00:00 8773       /bin/busybox
0010f000-00111000 rw-p 00000000 00:00 0          [heap]
b6dae000-b6eea000 r-xp 00000000 00:00 8937       /lib/libc-2.13.so
                                ^^^^^
                                 dev & ino are always zero

So John, what's with the filesystem that you installed Valgrind on?

J

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

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

On 15/04/15 16:03, Florian Krohm wrote:

> This isn't sane, because for an ANON segment we should have d=0 and i=0
> and o=0.
> Clearly, this is not an ANON segment but a file segment.
> 
> I suggest to change the condition on line 3248 in aspacemgr-linux.c
> (refering to 3.10.1 sources) to if (1) and rerun. That way we can see
> the contents of /proc/self/maps and can deduce why d == 0  (it should be
> != 0).

Ah, good point.

So, d is the device number, right?  If that's so, then the problem is
likely because memcheck-arm-linux is on some unusual, hacky, etc,
filesystem, and the device numbers are zero, when they shouldn't be.

And in fact, you can see that in the /proc/self/maps output that John
showed in his first message:

00008000-00106000 r-xp 00000000 00:00 8773       /bin/busybox
0010e000-0010f000 rw-p 000fe000 00:00 8773       /bin/busybox
0010f000-00111000 rw-p 00000000 00:00 0          [heap]
b6dae000-b6eea000 r-xp 00000000 00:00 8937       /lib/libc-2.13.so
                                ^^^^^
                                 dev & ino are always zero

So John, what's with the filesystem that you installed Valgrind on?

J

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[Florian K. <fl...@ei...>]

On 15.04.2015 15:45, Julian Seward wrote:
> 
>>> --2993:2:aspacem    Reading /proc/self/maps
>>> --2993:0:aspacem   -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed
>>> d=0x000 i=8527    o=32768   (0) m=0 /usr/lib/valgrind/memcheck-arm-linux

This isn't sane, because for an ANON segment we should have d=0 and i=0
and o=0.
Clearly, this is not an ANON segment but a file segment.

I suggest to change the condition on line 3248 in aspacemgr-linux.c
(refering to 3.10.1 sources) to if (1) and rerun. That way we can see
the contents of /proc/self/maps and can deduce why d == 0  (it should be
!= 0).

   Florian

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

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

>> --2993:2:aspacem    Reading /proc/self/maps
>> --2993:0:aspacem   -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed
>> d=0x000 i=8527    o=32768   (0) m=0 /usr/lib/valgrind/memcheck-arm-linux
>> --2993:0:aspacem  Valgrind: FATAL: aspacem assertion failed:
>> --2993:0:aspacem    segment_is_sane
>> --2993:0:aspacem    at m_aspacemgr/aspacemgr-linux.c:1477 (add_segment)
>> --2993:0:aspacem  Exiting now.

That is a really bizarre failure.  I've never seen anything like it before
and I can't imagine how it happened.

It would be useful to know why sane_NSegment() decided the NSegment wasn't
sane.  Can you put some debug printing into sane_NSegment ?  It's a pretty
simple function.  The only small detail is, you have to use the following
to print stuff:

  VG_(debugLog)(0, "aspacem", format-string, args ...)

J

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[John O. <joh...@cl...>]

Hi Julian,
Thank you for your reply. I get the same message when I run version 3.10.1.
Assertion is at aspacemgr-linux.c:1502

Regards
Beckett

-----Original Message-----
From: Julian Seward [mailto:js...@ac...] 
Sent: 15 April 2015 10:07
To: joh...@cl...; val...@li...
Subject: Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:


Could you try that again with the current SVN trunk, please?  I don't think
anyone has much enthusiasm to chase down obscure failures on an old version
(3.8.x).

svn co svn://svn.valgrind.org/valgrind/trunk trunk cd trunk ./autogen.sh

Then configure/build as normal.

J

> --2993:2:aspacem    Reading /proc/self/maps
> --2993:0:aspacem   -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed
> d=0x000 i=8527    o=32768   (0) m=0 /usr/lib/valgrind/memcheck-arm-linux
> --2993:0:aspacem  Valgrind: FATAL: aspacem assertion failed:
> --2993:0:aspacem    segment_is_sane
> --2993:0:aspacem    at m_aspacemgr/aspacemgr-linux.c:1477 (add_segment)
> --2993:0:aspacem  Exiting now.

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

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

Could you try that again with the current SVN trunk, please?  I don't
think anyone has much enthusiasm to chase down obscure failures on an old
version (3.8.x).

svn co svn://svn.valgrind.org/valgrind/trunk trunk
cd trunk
./autogen.sh

Then configure/build as normal.

J

> --2993:2:aspacem    Reading /proc/self/maps
> --2993:0:aspacem   -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed
> d=0x000 i=8527    o=32768   (0) m=0 /usr/lib/valgrind/memcheck-arm-linux
> --2993:0:aspacem  Valgrind: FATAL: aspacem assertion failed:
> --2993:0:aspacem    segment_is_sane
> --2993:0:aspacem    at m_aspacemgr/aspacemgr-linux.c:1477 (add_segment)
> --2993:0:aspacem  Exiting now.

[Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[john <joh...@cl...>]

Hi,
I am trying to run valgrind on an embedded arm device without success.
The system is built using buildroot-2013.05. The system specifications
are given below the following vargrind output:
 
# valgrind -d -d
--2993:1:debuglog DebugLog system started by Stage 1, level 2 logging
requested
--2993:1:launcher no tool requested, defaulting to 'memcheck'
--2993:1:launcher no client specified, defaulting platform to
'arm-linux'
--2993:1:launcher launching /usr/lib/valgrind/memcheck-arm-linux
--2993:1:debuglog DebugLog system started by Stage 2 (main), level 2
logging requested
--2993:1:main     Welcome to Valgrind version 3.8.1 debug logging
--2993:1:main     Checking current stack is plausible
--2993:1:main     Checking initial stack was noted
--2993:1:main     Starting the address space manager
--2993:2:aspacem            sp_at_startup = 0x00beeead70 (supplied)
--2993:2:aspacem                  minAddr = 0x0004000000 (computed)
--2993:2:aspacem                  maxAddr = 0x00beee9fff (computed)
--2993:2:aspacem                   cStart = 0x0004000000 (computed)
--2993:2:aspacem                   vStart = 0x0061775000 (computed)
--2993:2:aspacem    suggested_clstack_top = 0x00bdeeafff (computed)
--2993:2:aspacem    <<< SHOW_SEGMENTS: Initial layout (5 segments, 0
segnames)
--2993:2:aspacem      0: RSVN 0000000000-0003ffffff     64m -----
SmFixed
--2993:2:aspacem      1:      0004000000-0061774fff   1495m
--2993:2:aspacem      2: RSVN 0061775000-0061775fff    4096 -----
SmFixed
--2993:2:aspacem      3:      0061776000-00beee9fff   1495m
--2993:2:aspacem      4: RSVN 00beeea000-00ffffffff   1041m -----
SmFixed
--2993:2:aspacem    >>>
--2993:2:aspacem    Reading /proc/self/maps
--2993:0:aspacem   -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed
d=0x000 i=8527    o=32768   (0) m=0 /usr/lib/valgrind/memcheck-arm-linux
--2993:0:aspacem  Valgrind: FATAL: aspacem assertion failed:
--2993:0:aspacem    segment_is_sane
--2993:0:aspacem    at m_aspacemgr/aspacemgr-linux.c:1477 (add_segment)
--2993:0:aspacem  Exiting now.

My /proc/self/maps is as follows:
--------------------------
00008000-00106000 r-xp 00000000 00:00 8773       /bin/busybox
0010e000-0010f000 rw-p 000fe000 00:00 8773       /bin/busybox
0010f000-00111000 rw-p 00000000 00:00 0          [heap]
b6dae000-b6eea000 r-xp 00000000 00:00 8937       /lib/libc-2.13.so
b6eea000-b6ef2000 ---p 0013c000 00:00 8937       /lib/libc-2.13.so
b6ef2000-b6ef4000 r--p 0013c000 00:00 8937       /lib/libc-2.13.so
b6ef4000-b6ef5000 rw-p 0013e000 00:00 8937       /lib/libc-2.13.so
b6ef5000-b6ef8000 rw-p 00000000 00:00 0 
b6ef8000-b6f66000 r-xp 00000000 00:00 8935       /lib/libm-2.13.so
b6f66000-b6f6d000 ---p 0006e000 00:00 8935       /lib/libm-2.13.so
b6f6d000-b6f6e000 r--p 0006d000 00:00 8935       /lib/libm-2.13.so
b6f6e000-b6f6f000 rw-p 0006e000 00:00 8935       /lib/libm-2.13.so
b6f6f000-b6f8f000 r-xp 00000000 00:00 8945       /lib/ld-2.13.so
b6f91000-b6f92000 rw-p 00000000 00:00 0 
b6f94000-b6f95000 rw-p 00000000 00:00 0 
b6f95000-b6f96000 r-xp 00000000 00:00 0          [sigpage]
b6f96000-b6f97000 r--p 0001f000 00:00 8945       /lib/ld-2.13.so
b6f97000-b6f98000 rw-p 00020000 00:00 8945       /lib/ld-2.13.so
bee7c000-bee9d000 rw-p 00000000 00:00 0          [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]
----------------------------------------------
# cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 0 (v7l)
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls
vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

processor       : 1
model name      : ARMv7 Processor rev 0 (v7l)
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls
vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

Hardware        : Xilinx Zynq Platform
Revision        : 0000
Serial          : 0000000000000000
----------------------------------------------------------



Any suggestions on what the issue might be or where I should start
looking

regards
beckett