On 6/29/2018 2:47 PM, Alan Corey wrote:
On 6/29/18, Edward Diener <eldlistmaili...@tropicsoft.com> 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 <eldlistmaili...@tropicsoft.com> 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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
