valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] ARMv5?

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

On 19/09/17 20:19, John Reiser wrote:
>> Can someone who has worked on the code clarify if Valgrind is in fact
>> expected to work on an ARMv5?

ARMv5 and ARMv6 aren't supported.  In theory they could be to some extent, but
they lack adequate concurrency-related instructions (atomic insns, mem fences)
and the overall hassle-to-benefit ratio doesn't seem worth it.  ARMv7 is
ubiquitous now -- can't you use that?

> The official position is v7 only.  There is no v8 or higher yet, except aarch64
> which is supported separately because it is totally a different architecture.

No, that's not the case.  ARMv8 (that is, 8.0) is supported in both 32 and 64
bit modes (that is, for both "arm" and "aarch64").

J

Re: [Valgrind-users] Valgrind on mips64

[Vikram C. <vik...@gm...>]

Thanks John. It is memory-mapped hardware device. I will debug more and
would update you.

On Tue, Sep 19, 2017 at 3:00 PM, John Reiser <jr...@bi...> wrote:

> My code access memory-address range starting from 0x8001180000000000. This
>> is legitimate access.
>>
>
> But *what* does it access?  Is it a memory-mapped hardware device, or is
> it real RAM?
> Actual memory can be accessed in smaller or larger pieces in any order,
> and give consistent answers.  Many hardware devices cannot.  If
> 0x8001180000000000
> is a hardware device, then put a logic analyzer on the bus and find out
> exactly what is going on.
> If it's supposed to be actual RAM, then invoke valgrind with
>         --trace-notbelow=0 --trace-flags=10000000
> (warning: many megabytes of output) and examine the accesses there.
>
> --
>
> ------------------------------------------------------------
> ------------------
> 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 mips64

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

> My code access memory-address range starting from 0x8001180000000000. This is legitimate access.

But *what* does it access?  Is it a memory-mapped hardware device, or is it real RAM?
Actual memory can be accessed in smaller or larger pieces in any order,
and give consistent answers.  Many hardware devices cannot.  If 0x8001180000000000
is a hardware device, then put a logic analyzer on the bus and find out exactly what is going on.
If it's supposed to be actual RAM, then invoke valgrind with
	--trace-notbelow=0 --trace-flags=10000000
(warning: many megabytes of output) and examine the accesses there.

-- 

[Valgrind-users] Valgrind on mips64

[Vikram C. <vik...@gm...>]

Hi All,

I am trying to run valgrind on our mips 64 bit platform. I have compiled
valgrind 3.13 with following configure arguments:

./configure --host=mips64-poky-linux --prefix=...  --build=x86_64-linux
CC=... CXX=...

My code access memory-address range starting from 0x8001180000000000. This
is ligitimate access.
We have added following valgrind macro in the code before this access as:
VALGRIND_MALLOCLIKE_BLOCK(CVMX_ADD_IO_SEG(0x8001180000000000ull),
0x0000000000f00000ull, 0, 1);

But when the code tries accessing the memory region, it simply terminates
with SIGBUS:

==1492== Process terminating with default action of signal 10 (SIGBUS)


If we remove the above valgrind macro, the program still terminates with
SIGBUS with additional error message.

==890==  Address 0x8001180000001500 is not stack'd, malloc'd or (recently)
free'

==890== Process terminating with default action of signal 10 (SIGBUS)


I have tried valgrind 3.12 with same issue. If I run any other application
under valgrind that does not access this memory region, it works fine.

Also, this application runs fine without valgrind.

Please let me know what can we do to get around this issue.

Thanks

Re: [Valgrind-users] ARMv5?

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

> Can someone who has worked on the code clarify if Valgrind is in fact expected to work on an ARMv5?

The official position is v7 only.  There is no v8 or higher yet, except aarch64
which is supported separately because it is totally a different architecture.

It is technically possible to support v5/v6, and it is not really difficult
for single-threaded processes.  I myself submitted a set of patches that worked.
But less-than-v7 hardware (especially v5) lacks reasonable support for multi-threading
and mutual exclusion.  It can be done, but it is so cumbersome that it is not worthwhile.
If your project is unwilling to spend another $1 for a v7 chip then you are too cheap.
Get a RaspberryPi 3B, a pine64, or other similar board to use for next-to-last-stage integration.
Interface your hardware peripherals directly or via USB, or over ethernet to a real device.
Algorithm work, plus most integration, should be done in a non-embedded environment
using emulators [you _do_ have and maintain good software models for the devices, right?]

-- 

[Valgrind-users] ARMv5?

[Isaac R. <is...@ra...>]

Hello there!

I have been having some trouble getting Valgrind to work on an embedded platform we are using and have been a bit confused by the supported platform listing. On the website it says the following in the list of supported platforms (http://valgrind.org/info/platforms.html):

"ARM/Linux: up to and including ARMv7."

I read this to mean that Valgrind supports all versions of ARM from v2 to v7 across all processor families, but I am not so sure that this reading is correct.

I have found many old references online to ARMv5 not being supported by Valgrind at all, and the 'valgrind' package in OpenEmbedded refuses to build for anything other than only ARMv7 exactly (I think it is confused to refuse to build on anything either older or newer than v7). The language used on the supported platform page is a little confusing to me I guess, since it doesn't mention the specific ARM processor families (Cortex, "Legacy", the newer looking hybrid 32/64 *-A architecture).

Can someone who has worked on the code clarify if Valgrind is in fact expected to work on an ARMv5?

Thanks a lot for your help!

IJR
Isaac Raway

[Valgrind-users] 答复: 答复: 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

[Wuweijia <wuw...@hu...>]

Hi John:
	I had sent you the shared object last week. Can you re-product  the error now?	

BR
Owen



-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2017年9月15日 5:32
收件人: Wuweijia <wuw...@hu...>
主题: Re: 答复: [Valgrind-users] 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

Hi Wuweijia,

> Meanwhile, I will try using the *.so from my RaspberryPi3 running Fedora 27 (near beta).

The libc.so.* for 32-bit ARM in neither Fedora 27 nor Xubuntu xenial has the symbol  __stack_chk_guard  which is required by testClang.
Therefore I really do need the 32-bit android versions of the shared libraries.

I'll see what I can find using just static dis-assembly ...
--
John

Re: [Valgrind-users] Add markers when using massif

[Frederic D. <fre...@mi...>]

Hi,

Thanks for your answers.


Fred

<www.mipsology.com>

On 07/09/2017 19:53, Philippe Waroquiers wrote:
> On Thu, 2017-09-07 at 09:03 +0200, Frederic DUMOULIN wrote:
>> Hi,
>>
>> I'm using valgrind + massif tool to observe the heap usage.
>>
>> I have an application binary using a shared library which does the
>> memory allocations.
>> There are few functions in the API but they are called many times. So
>> it's difficult to identify them in the visualizer only with the stack.
>>
>> Is there any way to add markers into the program which can be shown in
>> the visualizer ?
> Valgrind 3.13 has added a new way to visualise memory usage
> and/or memory leaks.
>
> Basically, memcheck/massif and helgrind can produce the memory usage
> (or leaks for memcheck) in a kcachegrind compatible file.
> The kcachegrind visualiser can then be used to visualise memory usage,
> and e.g. filter/select based on function names appearing in the stack
> trace.
>
> To produce such a report at the end of execution, you can give the
> option --xtree-memory=full
>
> You can also produce such files on demand during execution from
> a shell; by doing :
>     vgdb xtmemory
>
>
> Philippe
>
>     
>

[Valgrind-users] 答复: 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

[Wuweijia <wuw...@hu...>]

Hi John
	I think the source "testClang.cpp:22" is cause. When I tested the testClang built by clang3.8 is okay, and I used the same shared libraries and linker . I meant the shared libraries and linker is the same , never change.	

BR
Owen

-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2017年9月14日 6:58
收件人: val...@li...
主题: Re: [Valgrind-users] 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

Wuweijia wrote:
> 	I run the same application with valgrind 3.12 .  I can the same stack when the application is down with your command line or not.
> 	
> 	The same stack when the valgrind is down:
> Thread 1: status = VgTs_Runnable (lwpid 29062)
> ==29062==    at 0x1089B6: compare_exchange_strong (atomic:943)
> ==29062==    by 0x1089B6: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376)
> ==29062==    by 0x1089B6: main (testClang.cpp:22)
> 
> 	 I think there maybe the bug in valgrind 3.13. Please check.
> 	
> 	So I send you the vgtrace.txt that is created by valgrind 3.12. I think it maybe helpful to you and valgrind is right .
> 
	[[snip]]
> vex: external/valgrind/VEX/priv/guest_arm_toIR.c:13352 (decode_V8_instruction): Assertion `szBlg2 <= 3' failed.

Because valgrind-3.13 made changes to the code that handles atomic operations, then there is great reluctance to working on the previous version valgrind-3.12 except to compare and contrast with the current version valgrind-3.13.

The traceback having the same address 0x1089B6 for all three subroutines, and the source location "testClang.cpp:22" suggests that you have a short test case that uses only a few shared libraries, or perhaps no shared library at all.  If so, then please compress and attach the whole executable.  That should be useful for analyzing.

-- 



------------------------------------------------------------------------------
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] 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

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

Using the larger vgtrace.rar (871KB) from a message that was posted just a few minutes
before the smaller version (22.3KB), then the interesting part is near the end
***** line 358098
==== SB 4145 (evchecks 744961) [tid 1] 0x4002995 __dl__ZL24debuggerd_signal_handleriP7siginfoPv+584 /system_O/bin/linker+0x2995

------------------------ Front end ------------------------

         (thumb) 0x4002994:  mov r1, r0

               ------ IMark(0x4002994, 2, 1) ------
               t0 = 0x0:I32
               PUT(392) = t0
               t1 = 0x1:I32
               t2 = GET:I32(8)
               PUT(12) = ITE(CmpNE32(t1,0x0:I32),t2,GET:I32(12))
               PUT(68) = 0x4002997:I32

     [[snip]]

         (thumb) 0x40029A0:  blx 0x4039678 (switch to ARM mode)

               ------ IMark(0x40029A0, 4, 1) ------
               t13 = 0x0:I32
               PUT(392) = t13
               t14 = 0x1:I32
               PUT(392) = t13
               t15 = Shr32(t13,0x8:I8)
               if (CmpNE32(t15,0x0:I32)) { PUT(68) = 0x40029A1:I32; exit-NoDecode }
               PUT(392) = t13
               if (Not1(32to1(t14))) { PUT(68) = 0x40029A5:I32; exit-Boring }
               PUT(64) = 0x40029A5:I32
               PUT(68) = 0x4039678:I32
               PUT(68) = GET:I32(68); exit-Call

GuestBytes 4002995 16  46 40 F2 6B 10 52 46 5B 46 00 95 36 F0 6A EE 00  002ADA34

VexExpansionRatio 16 208   130 :10

--28961-- VALGRIND INTERNAL ERROR: Valgrind received a signal 4 (SIGILL) - exiting
--28961-- si_code=1;  Faulting address: 0x0;  sp: 0x831d9d94
*****

and the earlier translation for the subroutine at 0x4039678:
***** line 61104
==== SB 693 (evchecks 3967) [tid 1] 0x4039678 __dl_syscall /system_O/bin/linker+0x39678

------------------------ Front end ------------------------

	(arm) 0x4039678:  mov r12, r13   // no registers saved at entry

               ------ IMark(0x4039678, 4, 0) ------
               t1 = GET:I32(60)
               t0 = t1
               t2 = t0
               PUT(56) = t2
               PUT(68) = 0x403967C:I32

	(arm) 0x403967C:  stmdb r13!, {0x00F0}

               ------ IMark(0x403967C, 4, 0) ------
               t3 = GET:I32(60)
               t4 = t3
               PUT(60) = Sub32(t3,0x10:I32)
               STle(Sub32(t4,0x4:I32)) = GET:I32(36)
               STle(Sub32(t4,0x8:I32)) = GET:I32(32)
               STle(Sub32(t4,0xC:I32)) = GET:I32(28)
               STle(Sub32(t4,0x10:I32)) = GET:I32(24)
               PUT(68) = 0x4039680:I32

    [[snip]]

         (arm) 0x4039690:  ldmia r12, {0x0078}

               ------ IMark(0x4039690, 4, 0) ------
               t17 = GET:I32(56)
               t18 = t17
               PUT(20) = LDle:I32(Add32(t18,0x0:I32))
               PUT(24) = LDle:I32(Add32(t18,0x4:I32))
               PUT(28) = LDle:I32(Add32(t18,0x8:I32))
               PUT(32) = LDle:I32(Add32(t18,0xC:I32))
               PUT(68) = 0x4039694:I32

         (arm) 0x4039694:  svc #0x00000000

               ------ IMark(0x4039694, 4, 0) ------
               PUT(68) = 0x4039698:I32
               PUT(68) = GET:I32(68); exit-Sys_syscall

         (arm) 0x4039698:  ldmia r13!, {0x00F0}

               ------ IMark(0x4039698, 4, 0) ------
               t0 = GET:I32(60)
               t1 = t0
               PUT(24) = LDle:I32(Add32(t1,0x0:I32))
               PUT(28) = LDle:I32(Add32(t1,0x4:I32))
               PUT(32) = LDle:I32(Add32(t1,0x8:I32))
               PUT(36) = LDle:I32(Add32(t1,0xC:I32))
               PUT(60) = Add32(t0,0x10:I32)
               PUT(68) = 0x403969C:I32

     [[snip]]

         (arm) 0x40396A0:  bx{ls} r14   // conditional return; is taken to (thumb) 0x4008B8E [not shown]

               ------ IMark(0x40396A0, 4, 0) ------
               t5 = armg_calculate_condition[mcx=0x9]{0x5815eb7c}(Or32(GET:I32(72),0x90:I32),GET:I32(76),GET:I32(80),GET:I32(84)):I32
               if (Not1(32to1(t5))) { PUT(68) = 0x40396A4:I32; exit-Boring }
               t6 = GET:I32(64)
               PUT(68) = t6
               PUT(68) = GET:I32(68); exit-Return

     [[snip; note change to (thumb) mode]]

         (thumb) 0x40423E6:  add sp, #16   // THIS LOOKS VERY STRANGE; What is going on with the stack pointer?

               ------ IMark(0x40423E6, 2, 1) ------
               t26 = GET:I32(392)
               t27 = Shr32(t26,0x8:I8)
               PUT(392) = t27
               t28 = armg_calculate_condition[mcx=0x9]{0x5815eb7c}(Or32(GET:I32(72),Xor32(And32(t26,0xF0:I32),0xE0:I32)),GET:I32(76),GET:I32(80),GET:I32(84)):I32
               t29 = ITE(CmpNE32(And32(t26,0xF0:I32),0x0:I32),t28,0x1:I32)
               t30 = Xor32(And32(t26,0x1:I32),0x1:I32)
               t31 = And32(t30,t29)
               PUT(60) = ITE(CmpNE32(t29,0x0:I32),Add32(GET:I32(60),0x10:I32),GET:I32(60))
               PUT(68) = 0x40423E9:I32


         (thumb) 0x40423E8:  ldmia r13!, {0x81F0}  // unconditional return

               ------ IMark(0x40423E8, 4, 1) ------
               t32 = 0x0:I32
               PUT(392) = t32
               t33 = 0x1:I32
               PUT(392) = t32
               t34 = Shr32(t32,0x8:I8)
               if (CmpNE32(t34,0x0:I32)) { PUT(68) = 0x40423E9:I32; exit-NoDecode }
               PUT(392) = t32
               if (Not1(32to1(t33))) { PUT(68) = 0x40423ED:I32; exit-Boring }
               t35 = GET:I32(60)
               t36 = t35
               PUT(24) = LDle:I32(Add32(t36,0x0:I32))
               PUT(28) = LDle:I32(Add32(t36,0x4:I32))
               PUT(32) = LDle:I32(Add32(t36,0x8:I32))
               PUT(36) = LDle:I32(Add32(t36,0xC:I32))
               PUT(40) = LDle:I32(Add32(t36,0x10:I32))
               PUT(68) = LDle:I32(Add32(t36,0x14:I32))
               PUT(60) = Add32(t35,0x18:I32)
               PUT(68) = GET:I32(68)
               PUT(68) = GET:I32(68); exit-Return
*****

I'm very unsure of what is happening.

-- 

Re: [Valgrind-users] 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

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

Wuweijia wrote:
> 	I run the same application with valgrind 3.12 .  I can the same stack when the application is down with your command line or not.
> 	
> 	The same stack when the valgrind is down:
> Thread 1: status = VgTs_Runnable (lwpid 29062)
> ==29062==    at 0x1089B6: compare_exchange_strong (atomic:943)
> ==29062==    by 0x1089B6: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376)
> ==29062==    by 0x1089B6: main (testClang.cpp:22)
> 
> 	 I think there maybe the bug in valgrind 3.13. Please check.
> 	
> 	So I send you the vgtrace.txt that is created by valgrind 3.12. I think it maybe helpful to you and valgrind is right .
> 
	[[snip]]
> vex: external/valgrind/VEX/priv/guest_arm_toIR.c:13352 (decode_V8_instruction): Assertion `szBlg2 <= 3' failed.

Because valgrind-3.13 made changes to the code that handles atomic operations,
then there is great reluctance to working on the previous version valgrind-3.12
except to compare and contrast with the current version valgrind-3.13.

The traceback having the same address 0x1089B6 for all three subroutines,
and the source location "testClang.cpp:22" suggests that you have a short test case
that uses only a few shared libraries, or perhaps no shared library at all.  If so, then
please compress and attach the whole executable.  That should be useful for analyzing.

-- 

[Valgrind-users] 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

[Wuweijia <wuw...@hu...>]

Hi John:
	
	I run the same application with valgrind 3.12 .  I can the same stack when the application is down with your command line or not.
	
	The same stack when the valgrind is down:
Thread 1: status = VgTs_Runnable (lwpid 29062)
==29062==    at 0x1089B6: compare_exchange_strong (atomic:943)
==29062==    by 0x1089B6: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376)
==29062==    by 0x1089B6: main (testClang.cpp:22)

	 I think there maybe the bug in valgrind 3.13. Please check. 
	
	So I send you the vgtrace.txt that is created by valgrind 3.12. I think it maybe helpful to you and valgrind is right .

	The Last  vgtrace log is :

	(thumb) 0x1089BC:  ldr.w r14, [r13, +#128]

              ------ IMark(0x1089BC, 4, 1) ------
              t9 = 0x0:I32
              PUT(392) = t9
              t10 = 0x1:I32
              t11 = GET:I32(60)
              t12 = Add32(t11,0x80:I32)
              t13 = GET:I32(64)
              t14 = GET:I32(64)
              t15 = if-strict (CmpNE32(t10,0x0:I32)) Ident32(LDle(t12)) else t14
              PUT(64) = t15
              PUT(68) = 0x1089C1:I32

	(thumb) 0x1089C0:  ldrex r3, [r14, #+0]

              ------ IMark(0x1089C0, 4, 1) ------
              t16 = 0x0:I32
              PUT(392) = t16
              t17 = 0x1:I32
              if (Not1(32to1(t17))) { PUT(68) = 0x1089C5:I32; exit-Boring } 
              t18 = LDle-Linked(Add32(GET:I32(64),0x0:I32))
              PUT(20) = t18
              PUT(68) = 0x1089C5:I32

vex: external/valgrind/VEX/priv/guest_arm_toIR.c:13352 (decode_V8_instruction): Assertion `szBlg2 <= 3' failed.

BR
Owen



-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2017年9月13日 0:40
收件人: val...@li...
主题: Re: [Valgrind-users] 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

>                  First, I build the program with clang 4.0 with 32 bit 
> command  param,  but  it run failed because there is unknown 
> instruction;

>                  disInstr(thumb): unhandled instruction: 0x450B 0xD104
> 
> ==24328== valgrind: Unrecognised instruction at address 0x1089c5.
> ==24328==    at 0x1089C4: compare_exchange_strong (atomic:943) 
> ==24328==    by 0x1089C4: 
> atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376) 
> ==24328==    by 0x1089C4: main (testClang.cpp:22)

It looks like there is some confusion because the program containing the supposed unhandled instruction stream:
===== foo.S
	.short 0x450B,0xD104
=====
disassembles (in Thumb mode) to
     $ gcc -c foo.S
     $ gdb foo.o
     (gdb) x/x 0
       0x0: 0xd104450b
     (gdb) x/2i 1    # 1 for Thumb mode
       0x1:	cmp	r3, r1
       0x3:	bne.n	0xe
which valgrind should handle easily.

Please re-run valgrind on the failing program, using additional parameters to valgrind:
     --trace-notbelow=0  --trace-flags=10000000  2>vgtrace.txt

which gives an instruction-by-instruction trace.  The re-directed stderr file vgtrace.txt will be large, possibly many megabytes.  Look near the end of the file for the last line that contains "==== SB nnnnn " where nnnnn is a decimal number of the block of instructions.  Please show us the output from there to the end of the file, probably a couple dozen lines.  Quite possibly it contains "ldrex r3, [lr]" or 0xE85E 0x3F00; but that should have been handled by the code in:
===== VEX/priv/guest_arm_toIR.c  l.22881
    /* ----------------- (T1) LDREX ----------------- */
    if (INSN0(15,4) == 0xE85 && INSN1(11,8) == BITS4(1,1,1,1)) { =====

-- 




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

[Valgrind-users] 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

[Wuweijia <wuw...@hu...>]

I think there is something different when I run the valgrind with your command .
It show me that valgrind  die at :
Thread 1: status = VgTs_Runnable (lwpid 28961)
==28961==    at 0x4039698: __dl_syscall (syscall.S:45)
==28961==    by 0x40029A3: __dl__ZL24debuggerd_signal_handleriP7siginfoPv (debugger.cpp:295)
==28961==    by 0x4044CD7: ??? (__restore.S:58)

Not before :
Die at:
Thread 1: status = VgTs_Runnable (lwpid 29198)
==29198==    at 0x1089B6: compare_exchange_strong (atomic:943)
==29198==    by 0x1089B6: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376)
==29198==    by 0x1089B6: main (testClang.cpp:22)

I send to the vgtrace.rar


-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2017年9月13日 0:40
收件人: val...@li...
主题: Re: [Valgrind-users] 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

>                  First, I build the program with clang 4.0 with 32 bit 
> command  param,  but  it run failed because there is unknown 
> instruction;

>                  disInstr(thumb): unhandled instruction: 0x450B 0xD104
> 
> ==24328== valgrind: Unrecognised instruction at address 0x1089c5.
> ==24328==    at 0x1089C4: compare_exchange_strong (atomic:943) 
> ==24328==    by 0x1089C4: 
> atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376) 
> ==24328==    by 0x1089C4: main (testClang.cpp:22)

It looks like there is some confusion because the program containing the supposed unhandled instruction stream:
===== foo.S
	.short 0x450B,0xD104
=====
disassembles (in Thumb mode) to
     $ gcc -c foo.S
     $ gdb foo.o
     (gdb) x/x 0
       0x0: 0xd104450b
     (gdb) x/2i 1    # 1 for Thumb mode
       0x1:	cmp	r3, r1
       0x3:	bne.n	0xe
which valgrind should handle easily.

Please re-run valgrind on the failing program, using additional parameters to valgrind:
     --trace-notbelow=0  --trace-flags=10000000  2>vgtrace.txt

which gives an instruction-by-instruction trace.  The re-directed stderr file vgtrace.txt will be large, possibly many megabytes.  Look near the end of the file for the last line that contains "==== SB nnnnn " where nnnnn is a decimal number of the block of instructions.  Please show us the output from there to the end of the file, probably a couple dozen lines.  Quite possibly it contains "ldrex r3, [lr]" or 0xE85E 0x3F00; but that should have been handled by the code in:
===== VEX/priv/guest_arm_toIR.c  l.22881
    /* ----------------- (T1) LDREX ----------------- */
    if (INSN0(15,4) == 0xE85 && INSN1(11,8) == BITS4(1,1,1,1)) { =====

-- 




------------------------------------------------------------------------------
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] 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

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

>                  First, I build the program with clang 4.0 with 32 bit command  param,  but  it run failed because there is unknown instruction;

>                  disInstr(thumb): unhandled instruction: 0x450B 0xD104
> 
> ==24328== valgrind: Unrecognised instruction at address 0x1089c5.
> ==24328==    at 0x1089C4: compare_exchange_strong (atomic:943)
> ==24328==    by 0x1089C4: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376)
> ==24328==    by 0x1089C4: main (testClang.cpp:22)

It looks like there is some confusion because the program containing the supposed
unhandled instruction stream:
===== foo.S
	.short 0x450B,0xD104
=====
disassembles (in Thumb mode) to
     $ gcc -c foo.S
     $ gdb foo.o
     (gdb) x/x 0
       0x0: 0xd104450b
     (gdb) x/2i 1    # 1 for Thumb mode
       0x1:	cmp	r3, r1
       0x3:	bne.n	0xe
which valgrind should handle easily.

Please re-run valgrind on the failing program, using additional parameters to valgrind:
     --trace-notbelow=0  --trace-flags=10000000  2>vgtrace.txt

which gives an instruction-by-instruction trace.  The re-directed stderr file
vgtrace.txt will be large, possibly many megabytes.  Look near the end of the file
for the last line that contains "==== SB nnnnn " where nnnnn is a decimal number of
the block of instructions.  Please show us the output from there to the
end of the file, probably a couple dozen lines.  Quite possibly it contains
"ldrex r3, [lr]" or 0xE85E 0x3F00; but that should have been handled by the code in:
===== VEX/priv/guest_arm_toIR.c  l.22881
    /* ----------------- (T1) LDREX ----------------- */
    if (INSN0(15,4) == 0xE85 && INSN1(11,8) == BITS4(1,1,1,1)) {
=====

-- 

[Valgrind-users] 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

[Wuweijia <wuw...@hu...>]

发件人: Wuweijia
发送时间: 2017年9月12日 12:34
收件人: 'val...@li...' <val...@li...>
抄送: Fanbohao <fan...@hu...>
主题: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

Hello:
                First, I build the program with clang 4.0 with 32 bit command  param,  but  it run failed because there is unknown instruction;
                Second , I build the program with clang 4.0 with 64 bit command param, and  it run success.
Third,  I build the same program with clang 3.8  with 32 bit command param, and I run success, there is no unknown instructions.

                There is the error log:
                disInstr(thumb): unhandled instruction: 0x450B 0xD104
==24328== valgrind: Unrecognised instruction at address 0x1089c5.
==24328==    at 0x1089C4: compare_exchange_strong (atomic:943)
==24328==    by 0x1089C4: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376)
==24328==    by 0x1089C4: main (testClang.cpp:22)

                There is some point :
                1: I build the arm application which is 32 bit , but it ran in the aarch64  server which is 64 bit;

                The rar pack  contain:
                1: the compile command with clang 4.0:
                2: the error log
                3: the function  main instruction (that compile with clang3.8 and clang4.0)

                I had search the code. In the implementation,  no matter clang3.8 or clang4.0  they all call __c11_atomic_compare_exchange_strong function to check the value. I think the source code maybe it is the same and fine.

                If you need any more information , Please send e-mail to me and how to gather it step by step. I am waiting for reponse.

BR
Owen

[Valgrind-users] Fw: Valgrind 3.11 on arm 32 linux

[<495...@qq...>]

All, the attachment is log. Thank you.

  I used valgrind 3.11 to do test on my STB, and I can run test program with valgrind. But when I started my test, it would printed logs like below and never finish:

 

 

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D024 szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D028 szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D02C szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D030 szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D034 szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D038 szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D03C szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D040 szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D044 szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D048 szB 4

--371:1:  gdbsrv tid 1 VG_(is_watched) write_watchpoint addr 0x76B7D04C szB 4

Re: [Valgrind-users] Add markers when using massif

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

On Thu, 2017-09-07 at 09:03 +0200, Frederic DUMOULIN wrote:
> Hi,
> 
> I'm using valgrind + massif tool to observe the heap usage.
> 
> I have an application binary using a shared library which does the 
> memory allocations.
> There are few functions in the API but they are called many times. So 
> it's difficult to identify them in the visualizer only with the stack.
> 
> Is there any way to add markers into the program which can be shown in 
> the visualizer ?

Valgrind 3.13 has added a new way to visualise memory usage
and/or memory leaks.

Basically, memcheck/massif and helgrind can produce the memory usage
(or leaks for memcheck) in a kcachegrind compatible file.
The kcachegrind visualiser can then be used to visualise memory usage,
and e.g. filter/select based on function names appearing in the stack
trace.

To produce such a report at the end of execution, you can give the
option --xtree-memory=full

You can also produce such files on demand during execution from
a shell; by doing :
   vgdb xtmemory


Philippe

   

Re: [Valgrind-users] Valgrind not working properly on imx6 platform

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

On 09/07/2017 Kacper Kowalski wrote:
> Thank you very much, John Reiser, for such extensive help.

You're welcome.

> 
> If I understood correctly, memcheck uses hardcoded SP and it's r13? It should use the register passed with ldmdb instruction as SP (within this example it will be r11)?

No, the details are different.  The hardware itself has hardcoded r13 as the
stack pointer sp.  It looks to me like the compiler is trying to tail-merge
the exit-from-subroutine so that all of the branches of a final if-then-else
come together and return from exactly one point.  When the subroutine
uses any of r4 through r11 then those registers must be saved at entry
and restored just before return.
The ldmdb does that, and also performs the return by writing r15(==pc).
(The compiler also cleverly uses the ldmdb to restore sp(==r13) from r12.)
Always exiting from exactly one point does have value, but in this case
where something shorter would work ("bx lr", or "mov pc,lr", or "blx lr";
or even the pair "push lr; pop pc" [==> str lr,[sp, #-4]!; ldr pc,[sp],#4!] )
even if some other paths still must use the ldmdb, then the
move-stmdb-sub wastes time and space.

> 
> ... "--ignore-range-below-sp=44-13" ... I can't find out exactly why such numbers
> should be used. It is clear that 44 stand for 11 registers pushed on the stack > but why memcheck complains only when 8 registers are
> fetched ((44 - 13 + 1)/4 = 8)?
> Is it caused by updating of r13(==sp) after the second fetch when ldmdb is used?
Yes.  memcheck's emulation of ldmdb is serial, using the newly-written value
of r13(==sp) to check the fetches for lower-numbered registers.  All known
instances of ARM hardware effectively do everything in parallel (and cannot
be interrupted), which protects all the fetches.  [I cannot find where this
is documented in the ARM manual.]

Using --ignore-range-below-sp does reduce the noise, but has the danger of
ignoring actual errors for references in that range.  For ldmdb, then
memcheck should use an extra temporary variable to hold the new value of sp,
and perform the actual assignment to sp only after writing all the other
registers.  (And the compiler-generated code should be improved, too.)

-- 

Re: [Valgrind-users] Valgrind not working properly on imx6 platform

[Kacper K. <kac...@gm...>]

Thank you very much, John Reiser, for such extensive help.

If I understood correctly, memcheck uses hardcoded SP and it's r13? It
should use the register passed with ldmdb instruction as SP (within this
example it will be r11)?

According to your suggestion I used "--ignore-range-below-sp=X-Y", but with
other values, because valgrind documentation says that X must be > Y and
they must be decimal. I used trial and error method to achieve smallest
range defining ignored range and I finally found out that memcheck doesn't
complain when I pass: "--ignore-range-below-sp=44-13" and valgrind works
fine with "--leak-check=full" parameter used. I can't find out exactly why
such numbers should be used. It is clear that 44 stand for 11 registers
pushed on the stack, but why memcheck complains only when 8 registers are
fetched ((44 - 13 + 1)/4 = 8)? Is it caused by updating of r13(==sp) after
second fetch when ldmdb is used?

Re: [Valgrind-users] Add markers when using massif

[Milian W. <ma...@mi...>]

On Thursday, September 7, 2017 9:03:55 AM CEST Frederic DUMOULIN wrote:
> Hi,
> 
> I'm using valgrind + massif tool to observe the heap usage.
> 
> I have an application binary using a shared library which does the
> memory allocations.
> There are few functions in the API but they are called many times. So
> it's difficult to identify them in the visualizer only with the stack.
> 
> Is there any way to add markers into the program which can be shown in
> the visualizer ?

If by visualizer you mean the massif_visualizer, then no - that is not 
supported. What you can do (afaik) is use vgdb to trigger snapshots of massif 
files.

Bye

-- 
Milian Wolff
ma...@mi...
http://milianw.de

[Valgrind-users] Add markers when using massif

[Frederic D. <fre...@mi...>]

Hi,

I'm using valgrind + massif tool to observe the heap usage.

I have an application binary using a shared library which does the 
memory allocations.
There are few functions in the API but they are called many times. So 
it's difficult to identify them in the visualizer only with the stack.

Is there any way to add markers into the program which can be shown in 
the visualizer ?

Thanks,
Fred

Re: [Valgrind-users] Valgrind not working properly on imx6 platform

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

> memcheck's bug is reporting the location "at 0x..." using the new value that was loaded into pc,
> instead of the original value of the pc of the instruction which suffered the complaint.

https://bugs.kde.org/show_bug.cgi?id=384442  "ARM: bad pc in complaint if instruction changes pc"

--

Re: [Valgrind-users] Valgrind not working properly on imx6 platform

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

> cat /proc/cpuinfo
   [[snip]]
> processor    : 1
> model name    : ARMv7 Processor rev 10 (v7l)
> BogoMIPS    : 132.00
> Features    : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> CPU implementer    : 0x41
> CPU architecture: 7
> CPU variant    : 0x2
> CPU part    : 0xc09
> CPU revision    : 10
> 
> Hardware    : Freescale i.MX6 Quad/DualLite (Device Tree)
> Revision    : 0000
> Serial        : 0000000000000000
> 
> Operating system info:
> cat /etc/openwrt_release
> DISTRIB_ID='OpenWrt'
> DISTRIB_RELEASE='15.05'
> DISTRIB_REVISION='r48153'
> DISTRIB_CODENAME='chaos_calmer'
> DISTRIB_TARGET='imx6/generic'
> DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05'
> DISTRIB_TAINTS='no-all busybox'
> 
> cat /proc/version
> Linux version 3.18.23 (gcc version 5.3.0 (OpenWrt GCC 5.3.0 r48153) ) #6 SMP Tue Jul 11 16:35:20 CEST 2017
> 
> Source code could be downloaded from:
> https://uclibc.org/downloads/uClibc-0.9.33.2.tar.bz2
> 
> Extracted chunks from trace output can be downloaded from:
> https://github.com/KKoovalsky/Valgrind-problems
> 
> The file is called vgtrace-shortened.txt. Full trace available in vgtrace.txt file. In this repo I also included compiled uClibc library.

Thank you for the detailed information, particularly the vgtrace*.txt.

It's a compiler "bug", and a "bug" in the memcheck implementation,
and a definite bug in the memcheck error reporting.

The workaround is to invoke valgrind(memcheck) with "--ignore-range-below-sp=0x0-0x14".

The problem can be seen here:
===== vgtrace-shortened.txt line 8308
          (arm) 0x4817678:  mov r12, r13   ## copy r12 from r13(==sp)

               ------ IMark(0x4817678, 4, 0) ------
               t1 = GET:I32(60)
               t0 = t1
               t2 = t0
               PUT(56) = t2
               PUT(68) = 0x481767C:I32

        (arm) 0x481767C:  stmdb r13!, {0xDFF0}  ## push r15(==pc),r14(==lr),r12,r11-r4 onto stack (sp===r13) *in that order*
               ------ IMark(0x481767C, 4, 0) ------
               t3 = GET:I32(60)
               t4 = t3
               PUT(60) = Sub32(t3,0x2C:I32)
               STle(Sub32(t4,0x4:I32)) = 0x4817684:I32
               STle(Sub32(t4,0x8:I32)) = GET:I32(64)
               STle(Sub32(t4,0xC:I32)) = GET:I32(56)
               STle(Sub32(t4,0x10:I32)) = GET:I32(52)
               STle(Sub32(t4,0x14:I32)) = GET:I32(48)
               STle(Sub32(t4,0x18:I32)) = GET:I32(44)
               STle(Sub32(t4,0x1C:I32)) = GET:I32(40)
               STle(Sub32(t4,0x20:I32)) = GET:I32(36)
               STle(Sub32(t4,0x24:I32)) = GET:I32(32)
               STle(Sub32(t4,0x28:I32)) = GET:I32(28)
               STle(Sub32(t4,0x2C:I32)) = GET:I32(24)
               PUT(68) = 0x4817680:I32

         (arm) 0x4817680:  sub r11, r12, #0x4   ## r12 has same value as sp before the 'stmdb'

               ------ IMark(0x4817680, 4, 0) ------
               t5 = GET:I32(56)
               t6 = 0x4:I32
               t7 = Sub32(t5,t6)
               PUT(52) = t7
               PUT(68) = 0x4817684:I32

         (arm) 0x4817684:  ldmdb r11, {0xAFF0}   ## load r15(==pc) from stored lr, r13(==sp) from stored r12, r11-r4 from stored original values

               ------ IMark(0x4817684, 4, 0) ------
               t8 = GET:I32(52)
               t9 = t8
               PUT(68) = LDle:I32(Sub32(t9,0x4:I32))
               PUT(60) = LDle:I32(Sub32(t9,0x8:I32))
               PUT(48) = LDle:I32(Sub32(t9,0x10:I32))
               PUT(44) = LDle:I32(Sub32(t9,0x14:I32))
               PUT(40) = LDle:I32(Sub32(t9,0x18:I32))
               PUT(36) = LDle:I32(Sub32(t9,0x1C:I32))
               PUT(32) = LDle:I32(Sub32(t9,0x20:I32))
               PUT(28) = LDle:I32(Sub32(t9,0x24:I32))
               PUT(24) = LDle:I32(Sub32(t9,0x28:I32))
               PUT(52) = LDle:I32(Sub32(t9,0xC:I32))
               PUT(68) = GET:I32(68)
               PUT(68) = GET:I32(68); exit-Boring

GuestBytes 4817678 16  0D C0 A0 E1 F0 DF 2D E9 04 B0 4C E2 F0 AF 1B E9  0028F343

VexExpansionRatio 16 952   595 :10

==26904== Invalid read of size 4
==26904==    at 0x4000E54: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==26904==  Address 0x7dad09fc is on thread 1's stack
==26904==  20 bytes below stack pointer
=====

The net effect of those 3 instructions is:
     r0-r3 do not change; none of them was written
     r4-r10 do not change; each value is stored and fetched to/from the same (corresponding) address
     r11 = (r12 - 4) from the 'sub'
     r12 gets the original (and final) value of r13(==sp)
     r13(==sp) does not change.  It was decremented by 44 (11 registers times 4 bytes per register)
         but then loaded from the location which was written with the value of r12, which is
         the same as the original sp
     r14(==lr) does not change; it never was written
     r15(==pc) is loaded from the original value in r14(==lr) which is the return address

memcheck's bug is reporting the location "at 0x..." using the new value that was loaded into pc,
instead of the original value of the pc of the instruction which suffered the complaint.

The compiler bug is relying on a particular implementation of poorly-specified hardware.
The "ldmdb r11, {0xAFF0}" reads 10 words from memory, and changes the value of r13(==sp)
among other registers.  The compiler assumes that the change to r13 does not become visible
until the entire instruction has completed, yet this is not guaranteed explicitly.
It is conceivable that the 'ldmdb' could be interrupted immediately after writing r13(==sp),
save internal state as part of servicing the interrupt, and resume state upon return.
If so, then the fetches to load the remaining registers are outside the boundary
of the stack (namely, less than the downward-growing sp), and that's a memcheck error.
On the other hand, all known hardware does not allow such an interrupt (all side effects
are "atomic") so the memcheck implementation is not faithful because it uses the new
value of r13(==sp) to check subsequent memory fetches for other registers before the
'lmdb' instruction ends.

The compiler's choice of storing and re-loading r4-r11 is horribly inefficient:
8 writes and 8 reads that only waste time.  The value stored from r15(==pc) via the 'stmdb'
never is read.  The entire sequence could be replaced by "bx lr" or "mov pc,lr",
(possibly preceded by "mov r12,sp"); except that 'bx' is not implemented in some
early hardware, and "mov pc,lr" is frowned upon in hardware that does have 'bx'.
One possible solution that works everywhere is to use "blx lr" and just ignore
the value that is written to lr.

-- 

Re: [Valgrind-users] Valgrind not working properly on imx6 platform

[Kacper K. <kac...@gm...>]

I booted from new image which was compiled fully with GCC-5.3 and the
problem still occurs. The advantage is that packages with debug symbols
were used and I can use the bt gdb command.

GDB:
(gdb) set verbose on
(gdb) target remote | /usr/lib/valgrind/../../bin/vgdb --pid=8269
Remote debugging using | /usr/lib/valgrind/../../bin/vgdb --pid=8269
relaying data between gdb and process 8269
Reading symbols from /lib/ld-uClibc.so.0...done.
Loaded symbols for /lib/ld-uClibc.so.0
0x04000e68 in _start () from /lib/ld-uClibc.so.0
(gdb) c
Continuing.
Reading in symbols for ldso/ldso/ldso.c...done.
Reading symbols from /usr/lib/valgrind/vgpreload_core-arm-linux.so...done.
Loaded symbols for /usr/lib/valgrind/vgpreload_core-arm-linux.so
Reading symbols from
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so...done.
Loaded symbols for /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
Reading symbols from /usr/lib/libboost_thread.so.1.64.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/libboost_thread.so.1.64.0
Reading symbols from /usr/lib/libboost_system.so.1.64.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/libboost_system.so.1.64.0
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.0...done.
Loaded symbols for /lib/libm.so.0
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.0...done.
Loaded symbols for /lib/libc.so.0
Reading symbols from /usr/lib/libboost_atomic.so.1.64.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/libboost_atomic.so.1.64.0
Reading symbols from /lib/librt.so.0...done.
Loaded symbols for /lib/librt.so.0
Reading symbols from /lib/libdl.so.0...done.
Loaded symbols for /lib/libdl.so.0

Program received signal SIGTRAP, Trace/breakpoint trap.
_dl_get_ready_to_run (Reading in symbols for
libc/sysdeps/linux/arm/crti.S...done.
tpnt=0x4007ac0, load_addr=<optimized out>, auxvt=0x7d80ca48,
envp=<optimized out>, argv=0x0) at ldso/ldso/ldso.c:1396
1396    ldso/ldso/ldso.c: No such file or directory.
Current language:  auto
The current source language is "auto; currently c".
(gdb) bt
#0  _dl_get_ready_to_run (tpnt=0x4007ac0, load_addr=<optimized out>,
auxvt=0x7d80ca48, envp=<optimized out>, argv=0x0) at ldso/ldso/ldso.c:1396
#1  0x049be918 in _init () at libc/sysdeps/linux/arm/crti.S:22
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) c
Continuing.
Reading in symbols for libc/misc/internals/__uClibc_main.c...done.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x04a170a0 in __uClibc_main (main=0x7d80cc04, argc=77770752, argv=Reading
in symbols for libc/sysdeps/linux/arm/crtn.S...done.
0x104e4 <_init+12>, app_init=Reading in symbols for
libc/sysdeps/linux/arm/crti.S...done.
0x104d8 <_init>, app_fini=0x10680 <_fini>, rtld_fini=0x4000df0 <_dl_fini>,
stack_end=0x7d80cc04) at libc/misc/internals/__uClibc_main.c:440
440    libc/misc/internals/__uClibc_main.c: No such file or directory.
(gdb) bt
#0  0x04a170a0 in __uClibc_main (main=0x7d80cc04, argc=77770752,
argv=0x104e4 <_init+12>, app_init=0x104d8 <_init>, app_fini=0x10680
<_fini>,
    rtld_fini=0x4000df0 <_dl_fini>, stack_end=0x7d80cc04) at
libc/misc/internals/__uClibc_main.c:440
#1  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
__GI___uClibc_fini () at libc/misc/internals/__uClibc_main.c:304
304    in libc/misc/internals/__uClibc_main.c
(gdb) bt
Reading in symbols for libc/stdlib/exit.c...done.
#0  __GI___uClibc_fini () at libc/misc/internals/__uClibc_main.c:304
#1  0x04a134bc in __GI_exit (rv=0) at libc/stdlib/_atexit.c:336
#2  0x04a17190 in __uClibc_main (main=0x7d80cc04, argc=77770752,
argv=0x4a17190 <__uClibc_main+764>, app_init=0x0, app_fini=0x10680 <_fini>,
    rtld_fini=0x4000df0 <_dl_fini>, stack_end=0x7d80cc04) at
libc/misc/internals/__uClibc_main.c:511
#3  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
_dl_fini () at ldso/ldso/ldso.c:311
311    ldso/ldso/ldso.c: No such file or directory.
(gdb) bt
Reading in symbols for libc/sysdeps/linux/arm/crti.S...done.
#0  _dl_fini () at ldso/ldso/ldso.c:311
#1  0x04818684 in _fini () at libc/sysdeps/linux/arm/crti.S:41
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) c
Continuing.
[Inferior 1 (Remote target) exited normally]


GDBSERVER:
==8269== Memcheck, a memory error detector
==8269== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==8269== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==8269== Command: /nmi/programs/inter_empty/bin/inter_empty
==8269==
==8269== (action at startup) vgdb me ...
==8269==
==8269== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==8269==   /path/to/gdb /nmi/programs/inter_empty/bin/inter_empty
==8269== and then give GDB the following command
==8269==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=8269
==8269== --pid is optional if only one valgrind process is running
==8269==
==8269== Invalid read of size 4
==8269==    at 0x40058F8: _dl_get_ready_to_run (ldso.c:1396)
==8269==  Address 0x7d80c624 is on thread 1's stack
==8269==  20 bytes below stack pointer
==8269==
==8269== (action on error) vgdb me ...
==8269== Continuing ...
==8269== Invalid read of size 4
==8269==    at 0x4A170A0: __uClibc_main (__uClibc_main.c:440)
==8269==    by 0xFFFFFFFF: ???
==8269==  Address 0x7d80ca34 is on thread 1's stack
==8269==  20 bytes below stack pointer
==8269==
==8269== (action on error) vgdb me ...
==8269== Continuing ...
==8269== Invalid read of size 4
==8269==    at 0x4A16E70: __uClibc_fini (__uClibc_main.c:304)
==8269==    by 0x4A134BB: exit (_atexit.c:336)
==8269==    by 0x4A1718F: __uClibc_main (__uClibc_main.c:511)
==8269==    by 0xFFFFFFFF: ???
==8269==  Address 0x7d80ca0c is on thread 1's stack
==8269==  20 bytes below stack pointer
==8269==
==8269== (action on error) vgdb me ...
==8269== Continuing ...
==8269== Invalid read of size 4
==8269==    at 0x4000E54: ??? (ldso.c:311)
==8269==  Address 0x7d80c9fc is on thread 1's stack
==8269==  20 bytes below stack pointer
==8269==
==8269== (action on error) vgdb me ...
==8269== Continuing ...
==8269==
==8269== HEAP SUMMARY:
==8269==     in use at exit: 20,224 bytes in 1 blocks
==8269==   total heap usage: 6 allocs, 5 frees, 20,632 bytes allocated
==8269==
==8269== LEAK SUMMARY:
==8269==    definitely lost: 0 bytes in 0 blocks
==8269==    indirectly lost: 0 bytes in 0 blocks
==8269==      possibly lost: 0 bytes in 0 blocks
==8269==    still reachable: 20,224 bytes in 1 blocks
==8269==         suppressed: 0 bytes in 0 blocks
==8269== Rerun with --leak-check=full to see details of leaked memory
==8269==
==8269== For counts of detected and suppressed errors, rerun with: -v
==8269== ERROR SUMMARY: 128 errors from 4 contexts (suppressed: 0 from 0)

Re: [Valgrind-users] Valgrind not working properly on imx6 platform

[Kacper K. <kac...@gm...>]

Openwrt does not have lscpu command available (nor in any package).

cat /proc/cpuinfo
processor    : 0
model name    : ARMv7 Processor rev 10 (v7l)
BogoMIPS    : 132.00
Features    : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer    : 0x41
CPU architecture: 7
CPU variant    : 0x2
CPU part    : 0xc09
CPU revision    : 10

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

Hardware    : Freescale i.MX6 Quad/DualLite (Device Tree)
Revision    : 0000
Serial        : 0000000000000000

Operating system info:
cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='15.05'
DISTRIB_REVISION='r48153'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='imx6/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05'
DISTRIB_TAINTS='no-all busybox'

cat /proc/version
Linux version 3.18.23 (gcc version 5.3.0 (OpenWrt GCC 5.3.0 r48153) ) #6
SMP Tue Jul 11 16:35:20 CEST 2017

Source code could be downloaded from:
https://uclibc.org/downloads/uClibc-0.9.33.2.tar.bz2

Extracted chunks from trace output can be downloaded from:
https://github.com/KKoovalsky/Valgrind-problems

The file is called vgtrace-shortened.txt. Full trace available in
vgtrace.txt file. In this repo I also included compiled uClibc library.

I am wondering if GCC update could have caused such behavior. I've been
running image compiled with GCC-4.8-Linaro, then I bumped the GCC package
version to use GCC-5.3, run firmware update and then installed valgrind and
other software which was compiled with buildroot which uses GCC-5.3. I will
try to check if this problem is reproducible by flashing from image which
was initially compiled with GCC-5.3.



2017-09-05 18:35 GMT+02:00 John Reiser <jr...@bi...>:

> > 1.
> > ==4996== Invalid read of size 4
> > ==4996==    at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so <
> http://ld-uClibc-0.9.33.2.so>)
> > ==4996==  Address 0x7dbb6664 is on thread 1's stack
> > ==4996==  20 bytes below stack pointer
>
>> GDB:
>>
>> 1.
>> (gdb) info reg
>> r0             0x4007148    67137864
>> r1             0x0    0
>> r2             0x49ba000    77307904
>> r3             0x49bd90c    77322508
>> r4             0x4015f78    67198840
>> r5             0x4006054    67133524
>> r6             0xa    10
>> r7             0x4006ac0    67136192
>> r8             0x24    36
>> r9             0x401602c    67199020
>> r10            0x7dbb6a48    2109434440
>> r11            0x7dbb6674    2109433460
>> r12            0x7dbb6678    2109433464
>> sp             0x7dbb6678    0x7dbb6678
>> lr             0x40054ec    67130604
>> pc             0x40054ec    0x40054ec
>> cpsr           0x20000010    536870928
>> (gdb) x/9i $pc-4*4
>>     0x40054dc:    beq    0x40054ec
>>     0x40054e0:    ldr    r2, [r7]
>>     0x40054e4:    add    r3, r3, r2
>>     0x40054e8:    blx    r3
>> => 0x40054ec:    mov    r0, r7
>>     0x40054f0:    bl    0x4001440
>>     0x40054f4:    b    0x40054b8
>>     0x40054f8:    ldr    r1, [r6, #88]    ; 0x58
>>     0x40054fc:    sub    sp, sp, #16
>>
>>
> This is strange.  None of the instructions (in any of the four cases)
> that are designated by the address in "at 0x..." is a memory fetch 'ldr'
> which would be necessary to correspond to the complaint "Invalid read of
> size 4".
>
> However, I see that each of the 4 complaints is immediately after a 'blx'
> instruction.
> 'blx' has a history of problems in both hardware and software.
> Exactly what hardware are you running?  Please report the output of
> "lscpu" and "cat /proc/cpuinfo".
> Also, please tell us which Linux distribution, and the exact package name
> of the
> compiled binary package for uClibc, and where anyone can download a copy
> of the package
> (both compiled binary and source code).
>
> Meanwhile, please invoke with these diagnostic flags:
>     valgrind --trace-notbelow=0 --trace-flags=10000000 /bin/true
> 2>vgtrace.txt
>
> The re-directed stderr vgtrace.txt will be an instruction-by-instruction
> trace
> [it will be large, probably about 5 MB or so] where the individual blocks
> look like
> *****  [This example was generated on x86_64.]
> ==== SB 0 (evchecks 0) [tid 1] 0x4000c50 UNKNOWN_FUNCTION /usr/lib64/
> ld-2.24.so+0xc50
>
> ------------------------ Front end ------------------------
>
>         0x4000C50:  movq %rsp,%rdi
>
>               ------ IMark(0x4000C50, 3, 0) ------
>               PUT(72) = GET:I64(48)
>               PUT(184) = 0x4000C53:I64
> *****
> where the "SB 0" is a serial number of the block.   Find the 'blx'
> instruction
> and its enclosing "SB nnnnn".  Then look forward until you find the SB for
> the
> pc that is specified in the complaint from memcheck.  Select the entire
> range of SB
> (from the 'blx' to the complaint) into a file, gzip it, and upload it
> somewhere
> that anyone interested can download it.  The idea is to find out how
> memcheck
> got the address that it is complaining about.
>
>
> --
>
> ------------------------------------------------------------
> ------------------
> 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
>