valgrind-users — General discussion list for Valgrind users

[Valgrind-users] About wrapper

[shuai xi <aha...@gm...>]

Hello developers:
I want to write a tool for valgrind base on memcheck. I use the  '_WRAP_
macros' to wrap malloc in libc, but there show me an error:

valgrind: m_redir.c:638 (vgPlain_redir_notify_new_DebugInfo): Assertion
'is_plausible_guest_addr(sym_avmas.main)' failed.
Segmentation fault (core dumped)

The code i add to 'mc_main.c' is:
long I_WRAP_SONAME_FNNAME_ZU(libcZdsoZd6,malloc) ( long n )
{
   char *  r;
   OrigFn fn;
   VALGRIND_GET_ORIG_FN(fn);
   CALL_FN_W_W(r, fn, n);
   //cloak_malloc_addr = r;
   return r;
}

(I has already disable the malloc replacement by deleting
vgpreload_memcheck-amd64-linux.so.)

Thanks

[Valgrind-users] How to invalidate the malloc replacement

[shuai xi <aha...@gm...>]

hello developers,
sorry to ask this question again.
When i delete the 'VG_(needs_malloc_replacement) (MC_(malloc).....)' ,
valgrind show me the error :'--7969-- VG_USERREQ__CLIENT_CALL1: func=0x0'.
It seems that the replace system is still working,but don't know which
address to call. so, what should i do to  invalidate the malloc replacement
? plz.
cloak

[Valgrind-users] About how to turn off the malloc hook

[shuai xi <aha...@gm...>]

 hello developers,
I want to reuse the shadow memory part of  memcheck , but do not want to
use the malloc hook part.
When I set the 'VG_(needs).malloc_replacement = False',the malloc hook
part  seems still to be working.
Which code do I need to modify to make malloc replace invalid?

Re: [Valgrind-users] About how to hook malloc to do sth and execute the original malloc

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

Yes because printf will invoke malloc which will call your wrapper
which will call printf etc etc until the stack is exhausted.

You can't use anything in your wrapper that might use malloc.

Tom

On 12/07/18 13:07, shuai xi wrote:
> thank you for your answer.
> But when i use  _WRAP_ macros like following code, it gives me an error.
> *code:*
> long I_WRAP_SONAME_FNNAME_ZU(libcZdsoZd6,malloc) ( long n )
> {
>    char *  r;
>    OrigFn fn;
>    printf("11111\n");
>    VALGRIND_GET_ORIG_FN(fn);
>    CALL_FN_W_W(r, fn, n);
>    //printf("in wrapper1-post: fact(%d) = %x\n", n, r);
>    return r;
> }
> 
> /* --------------- */
> 
> int main ( void )
> {
>    char * r , *x, *y;
>    //printf("computing fact(5)\n");
>    //r = fact(5);
>    r = malloc(0x20);
>    x = malloc(0x20);
>    printf("malloc(0x20) = %x \n",r );
>    printf("malloc(0x20) = %x \n",x );
>  Â
>    return 0;
> }
> *error:*
> ==14498== Stack overflow in thread #1: can't grow stack to 0xfe04d000
> ==14498==Â
> ==14498== Process terminating with default action of signal 11 (SIGSEGV)
> ==14498==  Access not within mapped region at address 0xFE04DFFC
> ==14498== Stack overflow in thread #1: can't grow stack to 0xfe04d000
> ==14498==    at 0x40B1183: _IO_doallocbuf (genops.c:394)
> ==14498==  If you believe this happened as a result of a stack
> ==14498==  overflow in your program's main thread (unlikely but
> ==14498==  possible), you can try to increase the size of the
> ==14498==  main thread stack using the --main-stacksize= flag.
> ==14498==  The main thread stack size used in this run was 8388608.
> 
> But when i comment out the ' printf("11111\n"); ', It seems ok.....
> 
> On Thu, Jul 12, 2018 at 7:24 PM Tom Hughes <to...@co... 
> <mailto:to...@co...>> wrote:
> 
>     On 12/07/18 10:26, shuai xi wrote:
> 
>      > I know that 'Memcheck's implementation of malloc has "nothing to do"
>      > with glibc's implementation' after readind some code of valgrind,
>     but i
>      > want to use the glibc's malloc to avoid changing heap layout.
>      > Memcheck sets the VG_(needs_malloc_replacement) to hook malloc
>     and exec
>      > MC_(malloc) instead of real malloc. It's very convenient. So can i
>      > get the address of the original malloc in MC_(malloc) and exec it?
>      > if not,can i use I_WRAP_SONAME_FNNAME_ZU function to hook malloc
>     in my
>      > valgrind tool's code?
> 
>     Yes if you want to wrap the function rather than replacing it
>     then use the _WRAP_ macros and then your wrapper can get the
>     original address and call it.
> 
>     Tom
> 
>     -- 
>     Tom Hughes (to...@co... <mailto:to...@co...>)
>     http://compton.nu/
> 


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

Re: [Valgrind-users] About how to hook malloc to do sth and execute the original malloc

[shuai xi <aha...@gm...>]

 thank you for your answer.
But when i use  _WRAP_ macros like following code, it gives me an error.
*code:*
long I_WRAP_SONAME_FNNAME_ZU(libcZdsoZd6,malloc) ( long n )
{
   char *  r;
   OrigFn fn;
   printf("11111\n");
   VALGRIND_GET_ORIG_FN(fn);
   CALL_FN_W_W(r, fn, n);
   //printf("in wrapper1-post: fact(%d) = %x\n", n, r);
   return r;
}

/* --------------- */

int main ( void )
{
   char * r , *x, *y;
   //printf("computing fact(5)\n");
   //r = fact(5);
   r = malloc(0x20);
   x = malloc(0x20);
   printf("malloc(0x20) = %x \n",r );
   printf("malloc(0x20) = %x \n",x );

   return 0;
}
* error:*
==14498== Stack overflow in thread #1: can't grow stack to 0xfe04d000
==14498==
==14498== Process terminating with default action of signal 11 (SIGSEGV)
==14498==  Access not within mapped region at address 0xFE04DFFC
==14498== Stack overflow in thread #1: can't grow stack to 0xfe04d000
==14498==    at 0x40B1183: _IO_doallocbuf (genops.c:394)
==14498==  If you believe this happened as a result of a stack
==14498==  overflow in your program's main thread (unlikely but
==14498==  possible), you can try to increase the size of the
==14498==  main thread stack using the --main-stacksize= flag.
==14498==  The main thread stack size used in this run was 8388608.

But when i comment out the ' printf("11111\n"); ', It seems ok.....

On Thu, Jul 12, 2018 at 7:24 PM Tom Hughes <to...@co...> wrote:

> On 12/07/18 10:26, shuai xi wrote:
>
> > I know that 'Memcheck's implementation of malloc has "nothing to do"
> > with glibc's implementation' after readind some code of valgrind, but i
> > want to use the glibc's malloc to avoid changing heap layout.
> > Memcheck sets the VG_(needs_malloc_replacement) to hook malloc and exec
> > MC_(malloc) instead of real malloc. It's very convenient. So can i
> > get the address of the original malloc in MC_(malloc) and exec it?
> > if not,can i use I_WRAP_SONAME_FNNAME_ZU function to hook malloc in my
> > valgrind tool's code?
>
> Yes if you want to wrap the function rather than replacing it
> then use the _WRAP_ macros and then your wrapper can get the
> original address and call it.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>

Re: [Valgrind-users] About how to hook malloc to do sth and execute the original malloc

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

On 12/07/18 10:26, shuai xi wrote:

> I know that 'Memcheck's implementation of malloc has "nothing to do" 
> with glibc's implementation' after readind some code of valgrind, but i 
> want to use the glibc's malloc to avoid changing heap layout.
> Memcheck sets the VG_(needs_malloc_replacement) to hook malloc and exec 
> MC_(malloc) instead of real malloc. It's very convenient. So can i 
> get the address of the original malloc in MC_(malloc) and exec it?
> if not,can i use I_WRAP_SONAME_FNNAME_ZU function to hook malloc in my 
> valgrind tool's code?

Yes if you want to wrap the function rather than replacing it
then use the _WRAP_ macros and then your wrapper can get the
original address and call it.

Tom

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

[Valgrind-users] About how to hook malloc to do sth and execute the original malloc

[shuai xi <aha...@gm...>]

hello developer, i want to write a tool for valgrind to analysis an
program automatically.
I know that 'Memcheck's implementation of malloc has "nothing to do" with
glibc's implementation' after readind some code of valgrind, but i want to
use the glibc's malloc to avoid changing heap layout.
Memcheck sets the VG_(needs_malloc_replacement) to hook malloc and exec
MC_(malloc) instead of real malloc. It's very convenient. So can i get the
address of the original malloc in  MC_(malloc) and exec it?
if not,can i use I_WRAP_SONAME_FNNAME_ZU function to hook malloc in my
valgrind tool's code?
thanks.

Re: [Valgrind-users] Iterate over leaked memory progamatically

[Kumara, A. <as...@ls...>]

Thanks for the response. This seems a good idea.

Do you know if I can get the output file name from valgrind programmatically (want to write a common pre-loaded lib which is independent of running process context) ?
One way might be to submit a "psu" command and process the output, are there better ways ?

-----Original Message-----
From: John Reiser [mailto:jr...@bi...] 
Sent: Monday, July 02, 2018 9:52 AM
To: val...@li...
Subject: Re: [Valgrind-users] Iterate over leaked memory progamatically

> Is it possible to do below with valgrind (e.g. using client requests) 
> programmatically
> 
> -Iterate over all leaked blocks
> 
> -Get the stack trace and leaked memory address
> 
> I know above can be done with the combination of gdb and vgdb, I want to know if this can be done in source code itself.

The program can find, read, and process valgrind's .xml output, although of course this is another "back door" method.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Please read these warnings and restrictions:

This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information.

The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence.

If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000.

LSEG may collect, process and retain your personal information for its business purposes. For more information please see our Privacy Policy. 

We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail.

E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. 

Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities.

London Stock Exchange Group plc

10 Paternoster Square
London 
EC4M 7LS

Registered in England and Wales No 05369106

Re: [Valgrind-users] Iterate over leaked memory progamatically

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

> Is it possible to do below with valgrind (e.g. using client requests) programmatically
> 
> -Iterate over all leaked blocks
> 
> -Get the stack trace and leaked memory address
> 
> I know above can be done with the combination of gdb and vgdb, I want to know if this can be done in source code itself.

The program can find, read, and process valgrind's .xml output,
although of course this is another "back door" method.

[Valgrind-users] Iterate over leaked memory progamatically

[Kumara, A. <as...@ls...>]

Hi,
Is it possible to do below with valgrind (e.g. using client requests) programmatically

-          Iterate over all leaked blocks

-          Get the stack trace and leaked memory address

I know above can be done with the combination of gdb and vgdb, I want to know if this can be done in source code itself.




Please read these warnings and restrictions:

This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information.

The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence.

If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000.

LSEG may collect, process and retain your personal information for its business purposes. For more information please see our Privacy Policy. 

We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail.

E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. 

Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities.

London Stock Exchange Group plc

10 Paternoster Square
London 
EC4M 7LS

Registered in England and Wales No 05369106

Re: [Valgrind-users] Valgrind on arm system startup message

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

>> https://bugs.kde.org/show_bug.cgi?id=396001
>>     unhandled instruction: 0xEC51 0x0F1E; ARMv7 libcrypto 'mrrc'
> 
> Thanks. Looks like the bug needs to be fixed before I can use valgrind successfully with libcrypto being loaded on my arm system.

That bug now is marked as a duplicate of the earlier bug
    https://bugs.kde.org/show_bug.cgi?id=344802
which has an updated patch for running valgrind native on arm32 and arm64.

Re: [Valgrind-users] Valgrind's support for copy-stack coroutine

[Remus C. <rem...@gm...>]

I had created the bug report: https://bugs.kde.org/show_bug.cgi?id=396053.

And the code repository is in:
https://github.com/hnes/libaco/tree/valgrind_memcheck_bug_report_on_copy_stack_coroutine
.

All best

Remus

On Mon, Jun 25, 2018 at 11:57 AM, Remus Clearwater <
rem...@gm...> wrote:

> Thank you very much, John.
>
> It is my fault. I will prepare the test cases and submit the detailed
> report as soon as possible.
>
> All best
>
> Remus
>
> On Mon, Jun 25, 2018 at 11:36 AM, John Reiser <jr...@bi...>
> wrote:
>
>> On 06/23/2018, Remus Clearwater wrote:
>>
>> I tried to use valgrind's memcheck on a C copy-stack coroutine program,
>>> and got many false positive reports about the invalid write/read on the
>>> shared stack when memcpy occurred.
>>>
>>> (I already used the VALGRIND_STACK_REGISTER/VALGRIND_STACK_DEREGISTER.)
>>>
>>> Valgrind works fine when I use valgrind on a standalone stack coroutine
>>> program.
>>>
>>> So, the question is:
>>>
>>> Does valgrind support copy-stack coroutine yet?
>>>
>>
>> The errors that you saw when you tried it, say that valgrind does not yet
>> support it.
>> By the way, which version of valgrind?  Which hardware?  Which
>> compiler(s)?
>> Which C run-time library?  And what was the exact text of the first
>> relevant
>> complaint from memcheck?
>>
>> The surest way to make progress is to submit a New bug report at
>>    https://bugs.kde.org/buglist.cgi?quicksearch=valgrind
>> and attach two test cases with actual code: one with "standalone stack
>> co-routine",
>> and one with "copy-stack co-routine".  Supplying actual code, and the
>> recipe
>> to build executables from it, is vital.  If the behavior that you saw
>> cannot be reproduced by a valgrind developer, then it is likely to be
>> a long time before anything gets fixed.
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>
>

Re: [Valgrind-users] Valgrind on arm system startup message

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

>> To make progress in the meantime, replace those 32 bits by the two instructions
>>      mov r0,#0
>>      mov r1,#0
>> which clear general registers r0 and r1.  This is a guess that zeroes
>> mean "this CPU has no such hardware assist".  The libcrypto software
>> will choose slower but equivalent code, instead of using
>> any special hardware assist.

> How do I "replace" those 32 bits with instructions before the library is loaded at run-time ?

If you have the source for libcrypto.so.1.1, which is in software package openssl-1.1.0h
(or openssl-libs-1.1.0h depending on your Linux distro) then in file crypto/armv4cpuid.pl
change to:
=====
_armv7_tick:
#ifdef  __APPLE__
         mrrc    p15,0,r0,r1,c14         @ CNTPCT
#else
      @  mrrc    p15,1,r0,r1,c14         @ CNTVCT  <<< COMMENTED OUT
	mov r0,#0    @ replacement for valgrind-3.13
	mov r1,#0    @ replacement for valgrind-3.13
#endif
         bx      lr
=====
Build from the modified source, and install the modified shared library.

If you don't have source, then use a hex (binary) editor such as hexedit.
Assemble a one-instruction program "mov r0,#0", then over-write the bytes
for "mrrc p15,1,r0,r1,cr14" with the bytes for "mov r0,#0".  If the code
is 32-bit ARM mode, then that's all there is to do.  If the code is 16-bit
Thumb mode, then over-write the second 16-bit word with "mov r1,#0".
Your initial report said "(thumb)", but perhaps that is inaccurate.

Re: [Valgrind-users] Valgrind on arm system startup message

[Edward D. <eld...@tr...>]

On 6/29/2018 2:47 PM, Alan Corey wrote:
> On 6/29/18, Edward Diener <eld...@tr...> wrote:
>> On 6/28/2018 9:01 PM, Alan Corey wrote:
>>> I'm no expert, but especially if it's arm64 try fetching the absolute
>>> latest from https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=summary
>>>
>>> That's about the error I got running versions before 3.13 on my Pi and
>>> there was something similar even with 3.13 on the same Pi running as
>>> arm64.  (and my rock64)  Search in the archives of this list for
>>> arm64, it's probably not the final fix but it works for me.
>>
>> I am running valgrind 3.13.0 on the arm system.
>>
>> My attempts at cloning using sourceware.org/git/valgrind.git always get
>> permission denied.
> 
> I just had no problem doing
> git clone git://sourceware.org/git/valgrind.git
> which is the URL on the page.  I think you can also get to it through
> github but there are something like 20 forks of it, it's safer to use
> the sourceware URL.  But all that's going to get you is the latest
> Valgrind, you may have more serious problems.  Best to use the latest
> though.

I did get this to work properly when I tried it again. Thanks ! I built 
the latest and tried it against my application, but the same valgrind 
message still exists. It does look like I will have to wait until this 
is fixed in valgrind in order to use it for my problem. Someone showed 
the bug report as:

https://bugs.kde.org/show_bug.cgi?id=396001
     unhandled instruction: 0xEC51 0x0F1E; ARMv7 libcrypto 'mrrc'

so I will have to wait for that fix.

The details of my actual problem is that a 3rd party shared library, 
whose source is publicly available, is crashing when I use it in my 
application. The crash occurs because somewhere the code of the 3rd 
party library is overwriting memory. Running under gdb it picks up the 
crash but the point at which it picks it up is obviously not the point 
at which it is occurring. So I was hoping valgrind might catch the 
original memory overwrite but because of the aforementioned bug valgrind 
does not work on my arm system.

Thanks for everyone for their help ! I am sure valgrind is a great 
product but if it does not currently work on my arm system I have to 
look elsewhere to solve my problem.

> 
>>
>>>
>>> On 6/28/18, Edward Diener <eld...@tr...> wrote:
>>>> I am attempting to use Valgrind with an application on an embedded arm
>>>> system. Debugging with gdb, a problem is occurring with a shared library
>>>> used by the application, where gdb is showing a SIGABRT from a malloc
>>>> call in a well-supported library, but can not show me the memory
>>>> overwrite problem that must be causing the crash. I was hoping using
>>>> valgrind could isolate from where the original memory overwrite is
>>>> occurring.
>>>>
>>>> However as soon as I start 'valgrind --leak-check=yes ./myprogram' I get
>>>> the message:
>>>>
>>>> ==621== Memcheck, a memory error detector
>>>> ==621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>>>> ==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright
>>>> info
>>>> ==621== Command: ./myprogram
>>>> ==621==
>>>> disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
>>>> ==621== valgrind: Unrecognised instruction at address 0x4cc1767.
>>>> ==621==    at 0x4CC1766: ??? (in
>>>> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
>>>> ==621== Your program just tried to execute an instruction that Valgrind
>>>> ==621== did not recognise.  There are two possible reasons for this.
>>>> ==621== 1. Your program has a bug and erroneously jumped to a non-code
>>>> ==621==    location.  If you are running Memcheck and you just saw a
>>>> ==621==    warning about a bad jump, it's probably your program's fault.
>>>> ==621== 2. The instruction is legitimate but Valgrind doesn't handle it,
>>>> ==621==    i.e. it's Valgrind's fault.  If you think this is the case or
>>>> ==621==    you are not sure, please let us know and we'll try to fix it.
>>>> ==621== Either way, Valgrind will now raise a SIGILL signal which will
>>>> ==621== probably kill your program.
>>>>
>>>> Does this mean that valgrind is not reliable for my purposes. It appears
>>>> impossible that this problem is being caused by any code execution in
>>>> 'myprogram' since the message occurs at the beginning of my valgrind
>>>> session and before the first console message 'myprogram' outputs, which
>>>> is at the beginning of the 'main' routine.
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
> 
> 

Re: [Valgrind-users] Valgrind on arm system startup message

[Alan C. <ala...@gm...>]

On 6/29/18, Edward Diener <eld...@tr...> wrote:
> On 6/28/2018 9:01 PM, Alan Corey wrote:
>> I'm no expert, but especially if it's arm64 try fetching the absolute
>> latest from https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=summary
>>
>> That's about the error I got running versions before 3.13 on my Pi and
>> there was something similar even with 3.13 on the same Pi running as
>> arm64.  (and my rock64)  Search in the archives of this list for
>> arm64, it's probably not the final fix but it works for me.
>
> I am running valgrind 3.13.0 on the arm system.
>
> My attempts at cloning using sourceware.org/git/valgrind.git always get
> permission denied.

I just had no problem doing
git clone git://sourceware.org/git/valgrind.git
which is the URL on the page.  I think you can also get to it through
github but there are something like 20 forks of it, it's safer to use
the sourceware URL.  But all that's going to get you is the latest
Valgrind, you may have more serious problems.  Best to use the latest
though.

>
>>
>> On 6/28/18, Edward Diener <eld...@tr...> wrote:
>>> I am attempting to use Valgrind with an application on an embedded arm
>>> system. Debugging with gdb, a problem is occurring with a shared library
>>> used by the application, where gdb is showing a SIGABRT from a malloc
>>> call in a well-supported library, but can not show me the memory
>>> overwrite problem that must be causing the crash. I was hoping using
>>> valgrind could isolate from where the original memory overwrite is
>>> occurring.
>>>
>>> However as soon as I start 'valgrind --leak-check=yes ./myprogram' I get
>>> the message:
>>>
>>> ==621== Memcheck, a memory error detector
>>> ==621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>>> ==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright
>>> info
>>> ==621== Command: ./myprogram
>>> ==621==
>>> disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
>>> ==621== valgrind: Unrecognised instruction at address 0x4cc1767.
>>> ==621==    at 0x4CC1766: ??? (in
>>> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
>>> ==621== Your program just tried to execute an instruction that Valgrind
>>> ==621== did not recognise.  There are two possible reasons for this.
>>> ==621== 1. Your program has a bug and erroneously jumped to a non-code
>>> ==621==    location.  If you are running Memcheck and you just saw a
>>> ==621==    warning about a bad jump, it's probably your program's fault.
>>> ==621== 2. The instruction is legitimate but Valgrind doesn't handle it,
>>> ==621==    i.e. it's Valgrind's fault.  If you think this is the case or
>>> ==621==    you are not sure, please let us know and we'll try to fix it.
>>> ==621== Either way, Valgrind will now raise a SIGILL signal which will
>>> ==621== probably kill your program.
>>>
>>> Does this mean that valgrind is not reliable for my purposes. It appears
>>> impossible that this problem is being caused by any code execution in
>>> 'myprogram' since the message occurs at the beginning of my valgrind
>>> session and before the first console message 'myprogram' outputs, which
>>> is at the beginning of the 'main' routine.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Valgrind-users] Valgrind on arm system startup message

[Edward D. <eld...@tr...>]

On 6/29/2018 11:52 AM, John Reiser wrote:
> https://bugs.kde.org/show_bug.cgi?id=396001
>     unhandled instruction: 0xEC51 0x0F1E; ARMv7 libcrypto 'mrrc'

Thanks. Looks like the bug needs to be fixed before I can use valgrind 
successfully with libcrypto being loaded on my arm system.

Re: [Valgrind-users] Valgrind on arm system startup message

[Edward D. <eld...@tr...>]

On 6/28/2018 9:01 PM, Alan Corey wrote:
> I'm no expert, but especially if it's arm64 try fetching the absolute
> latest from https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=summary
> 
> That's about the error I got running versions before 3.13 on my Pi and
> there was something similar even with 3.13 on the same Pi running as
> arm64.  (and my rock64)  Search in the archives of this list for
> arm64, it's probably not the final fix but it works for me.

I am running valgrind 3.13.0 on the arm system.

My attempts at cloning using sourceware.org/git/valgrind.git always get 
permission denied.

> 
> On 6/28/18, Edward Diener <eld...@tr...> wrote:
>> I am attempting to use Valgrind with an application on an embedded arm
>> system. Debugging with gdb, a problem is occurring with a shared library
>> used by the application, where gdb is showing a SIGABRT from a malloc
>> call in a well-supported library, but can not show me the memory
>> overwrite problem that must be causing the crash. I was hoping using
>> valgrind could isolate from where the original memory overwrite is
>> occurring.
>>
>> However as soon as I start 'valgrind --leak-check=yes ./myprogram' I get
>> the message:
>>
>> ==621== Memcheck, a memory error detector
>> ==621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>> ==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
>> ==621== Command: ./myprogram
>> ==621==
>> disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
>> ==621== valgrind: Unrecognised instruction at address 0x4cc1767.
>> ==621==    at 0x4CC1766: ??? (in
>> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
>> ==621== Your program just tried to execute an instruction that Valgrind
>> ==621== did not recognise.  There are two possible reasons for this.
>> ==621== 1. Your program has a bug and erroneously jumped to a non-code
>> ==621==    location.  If you are running Memcheck and you just saw a
>> ==621==    warning about a bad jump, it's probably your program's fault.
>> ==621== 2. The instruction is legitimate but Valgrind doesn't handle it,
>> ==621==    i.e. it's Valgrind's fault.  If you think this is the case or
>> ==621==    you are not sure, please let us know and we'll try to fix it.
>> ==621== Either way, Valgrind will now raise a SIGILL signal which will
>> ==621== probably kill your program.
>>
>> Does this mean that valgrind is not reliable for my purposes. It appears
>> impossible that this problem is being caused by any code execution in
>> 'myprogram' since the message occurs at the beginning of my valgrind
>> session and before the first console message 'myprogram' outputs, which
>> is at the beginning of the 'main' routine.

Re: [Valgrind-users] Valgrind on arm system startup message

[Edward D. <eld...@tr...>]

On 6/29/2018 12:55 AM, John Reiser wrote:
> On 06/28/2018, Edward Diener wrote:
>> I am attempting to use Valgrind with an application on an embedded arm 
>> system.
> 
>> ==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright 
>> info
>> ==621== Command: ./myprogram
>> ==621==
>> disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
>> ==621== valgrind: Unrecognised instruction at address 0x4cc1767.
>> ==621==    at 0x4CC1766: ??? (in 
>> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
> 
> Dis-assembling the one-line program
>      .short 0xEC51,0x0F1E
> in Thumb mode [using: (gdb) x/i 1 ] gives
>      mrrc 15,1,r0,r1,cr14
> which is moving data from co-processor 15 register cr14 into registers 
> r0 and r1.
> If the "libcrypto.so.1.1" return address is a correct hint,
> then this is some cryptography code checking for the presence of 
> hardware assist.
> You could be more sure of this by dis-assembling several instructions
> before and after 0x4CC1766, and by looking at the source code for
> libcrypto.so.1.1.
> 
> The actual bits returned by the mrrc instruction depend on the exact 
> model of the CPU.
> What does "cat /proc/cpuinfo" say?

processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 20.12
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 1
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 20.12
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

Hardware        : Freescale i.MX7 Dual (Device Tree)
Revision        : 0000
Serial          : 0000000000000000

> 
> Valgrind does not know enough about your CPU chip.
> You can help by filing a bug report; see  
> http://valgrind.org/support/bug_reports.html .
> Be sure to include the version of your C-language run-time library
> and how a valgrind developer can download your exact version of 
> libcrypto.so.1.1.
> 
> To make progress in the meantime, replace those 32 bits by the two 
> instructions
>      mov r0,#0
>      mov r1,#0
> which clear general registers r0 and r1.  This is a guess that zeroes
> mean "this CPU has no such hardware assist".  The libcrypto software
> will choose slower but equivalent code, instead of using
> any special hardware assist.

How do I "replace" those 32 bits with instructions before the library is 
loaded at run-time ?

Re: [Valgrind-users] Valgrind on arm system startup message

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

https://bugs.kde.org/show_bug.cgi?id=396001
    unhandled instruction: 0xEC51 0x0F1E; ARMv7 libcrypto 'mrrc'

Re: [Valgrind-users] Valgrind Solaris port - current and future shape

[Paul F. <pj...@wa...>]

> On 18 Jun 2018, at 15:39, Ivo Raisr <iv...@iv...> wrote:
> 
> Dear Valgrind'ers,
> 
> I have been maintaining the Valgrind Solaris (and partly also illumos)
> port for nearly three years,
> ensuring it builds and runs on the latest Solaris 11.1, 11.2, 11.3
> (and 11.4 until April 2018).
> 
> 
> I am still a Valgrind user and contributor, though. Will focus on Linux now.
> I.
> 

Hi Ivo

A big thanks for all of the work that you’ve done.

I guess there’s no backing from Oracle any more. Do you know of anyone on the Illumos side who would be interested/able to help?

For my part I do have a PC that runs S11.4, but I don’t use it much these days. I also have an Illumos virtual box, but that doesn’t see much action.


A+
Paul

Re: [Valgrind-users] Error when analysing pthreads code?

[EML <sa2...@cy...>]

Hi Philippe - yes, I think you're right. I've reported a possible race 
condition on RedHat's pthread_exit 
(https://bugzilla.redhat.com/show_bug.cgi?id=1596537).

Thanks.

Re: [Valgrind-users] Valgrind on arm system startup message

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

On 06/28/2018, Edward Diener wrote:
> I am attempting to use Valgrind with an application on an embedded arm system.

> ==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==621== Command: ./myprogram
> ==621==
> disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
> ==621== valgrind: Unrecognised instruction at address 0x4cc1767.
> ==621==    at 0x4CC1766: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)

Dis-assembling the one-line program
	.short 0xEC51,0x0F1E
in Thumb mode [using: (gdb) x/i 1 ] gives
	mrrc 15,1,r0,r1,cr14
which is moving data from co-processor 15 register cr14 into registers r0 and r1.
If the "libcrypto.so.1.1" return address is a correct hint,
then this is some cryptography code checking for the presence of hardware assist.
You could be more sure of this by dis-assembling several instructions
before and after 0x4CC1766, and by looking at the source code for
libcrypto.so.1.1.

The actual bits returned by the mrrc instruction depend on the exact model of the CPU.
What does "cat /proc/cpuinfo" say?

Valgrind does not know enough about your CPU chip.
You can help by filing a bug report; see  http://valgrind.org/support/bug_reports.html .
Be sure to include the version of your C-language run-time library
and how a valgrind developer can download your exact version of libcrypto.so.1.1.

To make progress in the meantime, replace those 32 bits by the two instructions
	mov r0,#0
	mov r1,#0
which clear general registers r0 and r1.  This is a guess that zeroes
mean "this CPU has no such hardware assist".  The libcrypto software
will choose slower but equivalent code, instead of using
any special hardware assist.

Re: [Valgrind-users] Error when analysing pthreads code?

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

Yo

On Thu, 2018-06-28 at 14:50 +0100, EML wrote:
> The program below creates two threads, in a detached state, and waits for them to complete with 'pthread_exit'. Compile and run as:
> 
> > gcc -lpthread test.c
> > valgrind --leak-check=full a.out
> 
> valgrind-3.13.0 (compiled from source) reports no errors on some runs, and a possible leak on other runs (560 bytes in 1 blocks), fairly randomly. On my system, the ratio of error-free to bad runs is about 50/50.
> 
> Is this is a problem with valgrind, or my use of pthreads? Note that this isn't the standard 'pthread_create' memory leak with joinable threads which haven't been joined, since the threads are detached.  I'm compiling on Centos 6.9, gcc 4.4.7. Thanks.

On my system, I systematically have the following possible leak:
==20923== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==20923==    at 0x4C2DB70: calloc (vg_replace_malloc.c:711)
==20923==    by 0x4011EF1: allocate_dtv (dl-tls.c:322)
==20923==    by 0x401287D: _dl_allocate_tls (dl-tls.c:539)
==20923==    by 0x4E4100B: allocate_stack (allocatestack.c:580)
==20923==    by 0x4E4100B: pthread_create@@GLIBC_2.2.5 (pthread_create.c:539)
==20923==    by 0x108936: main (pth.c:19)

Assuming what you see is the same leak (always interesting to give the error
when you discuss an error :)), the possible leak disappears if I am adding
   sleep (10);
before
   pthread_exit(0);

So, it looks like pthread_exit (0) is executed in your case
when a detached thread has not yet cleaned up some of the memory
(the dtv array) used for its thread local storage.
And when this detached thread exits as the last one of the process,
no cleanup of this memory is done.

You can further investigate what happens by adding -v -v -v -d -d -d
and/or use some more options of memcheck to see what stack trace is releasing
this dtv memory when you add the sleep.

Philippe

Re: [Valgrind-users] Valgrind on arm system startup message

[Alan C. <ala...@gm...>]

I'm no expert, but especially if it's arm64 try fetching the absolute
latest from https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=summary

That's about the error I got running versions before 3.13 on my Pi and
there was something similar even with 3.13 on the same Pi running as
arm64.  (and my rock64)  Search in the archives of this list for
arm64, it's probably not the final fix but it works for me.

On 6/28/18, Edward Diener <eld...@tr...> wrote:
> I am attempting to use Valgrind with an application on an embedded arm
> system. Debugging with gdb, a problem is occurring with a shared library
> used by the application, where gdb is showing a SIGABRT from a malloc
> call in a well-supported library, but can not show me the memory
> overwrite problem that must be causing the crash. I was hoping using
> valgrind could isolate from where the original memory overwrite is
> occurring.
>
> However as soon as I start 'valgrind --leak-check=yes ./myprogram' I get
> the message:
>
> ==621== Memcheck, a memory error detector
> ==621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==621== Command: ./myprogram
> ==621==
> disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
> ==621== valgrind: Unrecognised instruction at address 0x4cc1767.
> ==621==    at 0x4CC1766: ??? (in
> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
> ==621== Your program just tried to execute an instruction that Valgrind
> ==621== did not recognise.  There are two possible reasons for this.
> ==621== 1. Your program has a bug and erroneously jumped to a non-code
> ==621==    location.  If you are running Memcheck and you just saw a
> ==621==    warning about a bad jump, it's probably your program's fault.
> ==621== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==621==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==621==    you are not sure, please let us know and we'll try to fix it.
> ==621== Either way, Valgrind will now raise a SIGILL signal which will
> ==621== probably kill your program.
>
> Does this mean that valgrind is not reliable for my purposes. It appears
> impossible that this problem is being caused by any code execution in
> 'myprogram' since the message occurs at the beginning of my valgrind
> session and before the first console message 'myprogram' outputs, which
> is at the beginning of the 'main' routine.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

[Valgrind-users] Valgrind on arm system startup message

[Edward D. <eld...@tr...>]

I am attempting to use Valgrind with an application on an embedded arm 
system. Debugging with gdb, a problem is occurring with a shared library 
used by the application, where gdb is showing a SIGABRT from a malloc 
call in a well-supported library, but can not show me the memory 
overwrite problem that must be causing the crash. I was hoping using 
valgrind could isolate from where the original memory overwrite is 
occurring.

However as soon as I start 'valgrind --leak-check=yes ./myprogram' I get 
the message:

==621== Memcheck, a memory error detector
==621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==621== Command: ./myprogram
==621==
disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
==621== valgrind: Unrecognised instruction at address 0x4cc1767.
==621==    at 0x4CC1766: ??? (in 
/usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==621== Your program just tried to execute an instruction that Valgrind
==621== did not recognise.  There are two possible reasons for this.
==621== 1. Your program has a bug and erroneously jumped to a non-code
==621==    location.  If you are running Memcheck and you just saw a
==621==    warning about a bad jump, it's probably your program's fault.
==621== 2. The instruction is legitimate but Valgrind doesn't handle it,
==621==    i.e. it's Valgrind's fault.  If you think this is the case or
==621==    you are not sure, please let us know and we'll try to fix it.
==621== Either way, Valgrind will now raise a SIGILL signal which will
==621== probably kill your program.

Does this mean that valgrind is not reliable for my purposes. It appears 
impossible that this problem is being caused by any code execution in 
'myprogram' since the message occurs at the beginning of my valgrind 
session and before the first console message 'myprogram' outputs, which 
is at the beginning of the 'main' routine.