Hmm, I'll check that. Right now the latest apt-update & upgrade seems to have broken my USB connection to the camera. I wanted to check a subroutine I wrote for a program that works with libghoto.
I'm using: Linux version 4.16.0-2-arm64 ([email protected]) (gcc version 7.3.0 (Debian 7.3.0-19)) #1 SMP Debian 4.16.12-1 (2018-05-27) The Valgrind was a 3.13.0 that I'd built from the distribution tarball, then I discovered the same version had been added (Debian Unstable) to the standard debs. I wanted to see Valkyrie so I did a make uninstall and installed Valgrind and Valkyrie from the debs. >From before it broke: ==6541== Memcheck, a memory error detector ==6541== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==6541== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==6541== Command: ./cmpi2 ==6541== ARM64 front end: branch_etc disInstr(arm64): unhandled instruction 0xD5380000 disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000 ==6541== valgrind: Unrecognised instruction at address 0x4014e2c. ==6541== at 0x4014E2C: init_cpu_features (cpu-features.c:72) ==6541== by 0x4014E2C: dl_platform_init (dl-machine.h:208) ==6541== by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231) ==6541== by 0x40018D3: _dl_start_final (rtld.c:414) ==6541== by 0x4001B57: _dl_start (rtld.c:523) ==6541== by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so) ==6541== Your program just tried to execute an instruction that Valgrind ==6541== did not recognise. There are two possible reasons for this. ==6541== 1. Your program has a bug and erroneously jumped to a non-code ==6541== location. If you are running Memcheck and you just saw a ==6541== warning about a bad jump, it's probably your program's fault. ==6541== 2. The instruction is legitimate but Valgrind doesn't handle it, ==6541== i.e. it's Valgrind's fault. If you think this is the case or ==6541== you are not sure, please let us know and we'll try to fix it. ==6541== Either way, Valgrind will now raise a SIGILL signal which will ==6541== probably kill your program. ==6541== ==6541== Process terminating with default action of signal 4 (SIGILL): dumping core ==6541== Illegal opcode at address 0x4014E2C ==6541== at 0x4014E2C: init_cpu_features (cpu-features.c:72) ==6541== by 0x4014E2C: dl_platform_init (dl-machine.h:208) ==6541== by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231) ==6541== by 0x40018D3: _dl_start_final (rtld.c:414) ==6541== by 0x4001B57: _dl_start (rtld.c:523) ==6541== by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so) valgrind: m_coredump/coredump-elf.c:495 (fill_fpu): Assertion 'Unimplemented functionality' failed. valgrind: valgrind host stacktrace: ==6541== at 0x5803CC70: show_sched_status_wrk (m_libcassert.c:355) ==6541== by 0x5803CDB3: report_and_quit (m_libcassert.c:426) ==6541== by 0x5803CF23: vgPlain_assert_fail (m_libcassert.c:492) ==6541== by 0x5806F783: fill_fpu.isra.4 (coredump-elf.c:495) ==6541== by 0x5806F98F: dump_one_thread (coredump-elf.c:552) ==6541== by 0x5806F98F: make_elf_coredump (coredump-elf.c:656) ==6541== by 0x5806F98F: vgPlain_make_coredump (coredump-elf.c:737) ==6541== by 0x58055717: default_action (m_signals.c:1914) ==6541== by 0x58055717: deliver_signal (m_signals.c:1974) ==6541== by 0x58055DDB: vgPlain_synth_sigill (m_signals.c:2083) ==6541== by 0x58096BD7: vgPlain_scheduler (scheduler.c:1581) ==6541== by 0x580A918B: thread_wrapper (syswrap-linux.c:103) ==6541== by 0x580A918B: run_a_thread_NORETURN (syswrap-linux.c:156) ==6541== by 0xFFFFFFFFFFFFFFFF: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 6541) ==6541== at 0x4014E2C: init_cpu_features (cpu-features.c:72) ==6541== by 0x4014E2C: dl_platform_init (dl-machine.h:208) ==6541== by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231) ==6541== by 0x40018D3: _dl_start_final (rtld.c:414) ==6541== by 0x4001B57: _dl_start (rtld.c:523) ==6541== by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. On 6/16/18, Tom Hughes <[email protected]> wrote: > On 16/06/18 17:49, Alan Corey wrote: > >> Maybe a bleeding edge version on Github or somewhere? >> >> I'm on a Raspberry Pi 3b in 64 bit mode: >> Linux version 4.16.0-1-arm64 ([email protected]) (gcc >> version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29) >> >> I have Valgrind 3.13 I built from a release tarball, it works in 32 >> bit mode but not in 64, it doesn't know the instructions yet. > > Well aarch64 is supported in the version you have. > > If you have found an instruction it doesn't understand then > report a bug in the bug tracker. > > Tom > > -- > Tom Hughes ([email protected]) > http://compton.nu/ > -- ------------- No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
