|
From: Edward D. <eld...@tr...> - 2018-06-29 00:38:11
|
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. |
|
From: Alan C. <ala...@gm...> - 2018-06-29 01:02:04
|
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 |
|
From: John R. <jr...@bi...> - 2018-06-29 04:55:55
|
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. |
|
From: John R. <jr...@bi...> - 2018-06-29 15:52:37
|
https://bugs.kde.org/show_bug.cgi?id=396001 unhandled instruction: 0xEC51 0x0F1E; ARMv7 libcrypto 'mrrc' |
|
From: Edward D. <eld...@tr...> - 2018-06-29 18:25:45
|
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 ? |
|
From: John R. <jr...@bi...> - 2018-06-30 05:17:13
|
>> 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.
|
|
From: Edward D. <eld...@tr...> - 2018-06-29 18:34:00
|
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. |
|
From: Edward D. <eld...@tr...> - 2018-06-29 18:37:16
|
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. |
|
From: John R. <jr...@bi...> - 2018-07-02 03:29:56
|
>> 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. |
|
From: Alan C. <ala...@gm...> - 2018-06-29 18:47:45
|
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 |
|
From: Edward D. <eld...@tr...> - 2018-06-29 19:49:38
|
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 >> > > |