Menu
▾
▴
valgrind-users
|
From: Alan C. <ala...@gm...> - 2018-06-16 16:49:19
|
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 (deb...@li...) (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. -- ------------- No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach |
|
From: Tom H. <to...@co...> - 2018-06-16 16:54:43
|
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 (deb...@li...) (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 (to...@co...) http://compton.nu/ |
|
From: Alan C. <ala...@gm...> - 2018-06-16 23:09:23
|
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 (deb...@li...) (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 <to...@co...> 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 (deb...@li...) (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 (to...@co...) > 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 |
|
From: Mark W. <ma...@kl...> - 2018-06-16 23:30:27
|
On Sat, 2018-06-16 at 19:09 -0400, Alan Corey wrote: > > Linux version 4.16.0-2-arm64 (deb...@li...) (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) That is https://bugs.kde.org/show_bug.cgi?id=381556 arm64: Handle feature registers access on 4.11 Linux kernel or later In Fedora we carry a workaround as mentioned in comment #1: https://bugs.kde.org/show_bug.cgi?id=381556#c1 But this really needs someone who knows what the various HWCAP flags really mean on arm64 and which ones we should/shouldn't mask to indicate what instructions valgrind/VEX emulates. Cheers, Mark |
|
From: Alan C. <ala...@gm...> - 2018-06-17 01:30:23
|
OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it worked fine. Found bugs anyway. KDE and Fedora are way off my beaten path. Oh, I see even Raspbian Stretch finally got 3.13, they had one that didn't do arm at all. On 6/16/18, Mark Wielaard <ma...@kl...> wrote: > On Sat, 2018-06-16 at 19:09 -0400, Alan Corey wrote: >> > Linux version 4.16.0-2-arm64 (deb...@li...) (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) > > That is https://bugs.kde.org/show_bug.cgi?id=381556 > arm64: Handle feature registers access on 4.11 Linux kernel or later > > In Fedora we carry a workaround as mentioned in comment #1: > https://bugs.kde.org/show_bug.cgi?id=381556#c1 > > But this really needs someone who knows what the various HWCAP flags > really mean on arm64 and which ones we should/shouldn't mask to > indicate what instructions valgrind/VEX emulates. > > Cheers, > > Mark > -- ------------- No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach |
|
From: Mark W. <ma...@kl...> - 2018-06-18 13:17:28
|
On Sat, 2018-06-16 at 21:30 -0400, Alan Corey wrote: > OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it > worked fine. Found bugs anyway. KDE and Fedora are way off my beaten > path. Oh, I see even Raspbian Stretch finally got 3.13, they had one > that didn't do arm at all. For now I checked in the workaround so that valgrind from git trunk should work on your arm64 environment. I kept the bug open since it needs someone with a bit more arm64 knowledge to properly fix it. https://bugs.kde.org/show_bug.cgi?id=381556 Cheers, Mark |
|
From: Alan C. <ala...@gm...> - 2018-06-18 13:57:06
|
Um, dumb question probably but you checked it in where? Looks like there are at least 4 forks of Valgrind on Github, on sourceware.org I just see releases, nothing since 3.13. On 6/18/18, Mark Wielaard <ma...@kl...> wrote: > On Sat, 2018-06-16 at 21:30 -0400, Alan Corey wrote: >> OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it >> worked fine. Found bugs anyway. KDE and Fedora are way off my beaten >> path. Oh, I see even Raspbian Stretch finally got 3.13, they had one >> that didn't do arm at all. > > For now I checked in the workaround so that valgrind from git trunk > should work on your arm64 environment. I kept the bug open since it > needs someone with a bit more arm64 knowledge to properly fix it. > https://bugs.kde.org/show_bug.cgi?id=381556 > > Cheers, > > Mark > -- ------------- No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach |
|
From: Tom H. <to...@co...> - 2018-06-18 13:58:47
|
The sourceware git repo is the canonical one: https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=summary Tom On 18/06/18 14:56, Alan Corey wrote: > Um, dumb question probably but you checked it in where? Looks like > there are at least 4 forks of Valgrind on Github, on sourceware.org I > just see releases, nothing since 3.13. > > On 6/18/18, Mark Wielaard <ma...@kl...> wrote: >> On Sat, 2018-06-16 at 21:30 -0400, Alan Corey wrote: >>> OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it >>> worked fine.  Found bugs anyway.  KDE and Fedora are way off my beaten >>> path.  Oh, I see even Raspbian Stretch finally got 3.13, they had one >>> that didn't do arm at all. >> >> For now I checked in the workaround so that valgrind from git trunk >> should work on your arm64 environment. I kept the bug open since it >> needs someone with a bit more arm64 knowledge to properly fix it. >> https://bugs.kde.org/show_bug.cgi?id=381556 >> >> Cheers, >> >> Mark >> > > -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Ivo R. <iv...@iv...> - 2018-06-18 14:07:17
|
Il giorno lun 18 giu 2018 alle ore 15:57 Alan Corey <ala...@gm...> ha scritto: > > Um, dumb question probably but you checked it in where? Looks like > there are at least 4 forks of Valgrind on Github, on sourceware.org I > just see releases, nothing since 3.13. In addition to Tom's answer: I found at least 20 of such forks on github recently active (this year). But none claims to be the master one; all reference master repo at sourceware.org. Where would you expect information about master Valgrind repo? sourceware.org? valgrind.org? I. |
|
From: Alan C. <ala...@gm...> - 2018-06-18 18:28:51
|
I don't really know, I'm not much of a Github user, especially now that Microsoft's buying them. But the forks aren't much better than imposters if you're looking for the original. They may contribute to the parent project or not. I wouldn't expect anybody to mimic valgrind.org, so a clear link there endorsing one of the forks as the real thing would be good. I'd mostly rather have well-tested releases than bleeding edge. Usually when I get something from github I get the master.zip if possible. This did the trick though, runs fine so far on this arm64 Pi. I also have a Rock64 which it should work on. I like these little arm boxes, and my i386 machines are all 10+ years old by now On 6/18/18, Ivo Raisr <iv...@iv...> wrote: > Il giorno lun 18 giu 2018 alle ore 15:57 Alan Corey > <ala...@gm...> ha scritto: >> >> Um, dumb question probably but you checked it in where? Looks like >> there are at least 4 forks of Valgrind on Github, on sourceware.org I >> just see releases, nothing since 3.13. > > In addition to Tom's answer: I found at least 20 of such forks on > github recently active (this year). > But none claims to be the master one; all reference master repo at > sourceware.org. > > Where would you expect information about master Valgrind repo? > sourceware.org? valgrind.org? > I. > -- ------------- No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X