[valgrind] [Bug 476553] RPM build of Valgrind 3.22.0 fails under RHEL8
https://bugs.kde.org/show_bug.cgi?id=476553 --- Comment #4 from Peter Klotz --- Created attachment 163037 --> https://bugs.kde.org/attachment.cgi?id=163037=edit Patch needed to package libexec content As mentioned earlier in the bug, this patch is needed to properly package libexec files. Otherwise the RPM build mechanism complains about installed but unpackaged files. This was observed when building the RPM under RHEL8. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476553] RPM build of Valgrind 3.22.0 fails under RHEL8
https://bugs.kde.org/show_bug.cgi?id=476553 --- Comment #3 from Peter Klotz --- Created attachment 163036 --> https://bugs.kde.org/attachment.cgi?id=163036=edit Workaround to packge gdb Python script files It seems gdb in RHEL8 is not too old for packaging valgrind-monitor-def.py and valgrind-monitor.py. The initial comment in the bug points to a permission problem because the RPM build tries to incorrectly write the files into /usr/libexec/valgrind. In an RPM build the correct path would be '/home/user/rpmbuild/BUILDROOT/valgrind-3.22.0-1.x86_64/usr/libexec/valgrind', so the prefix is missing. The problem lies in the 'install-recursive' target of the build. This patch is just a workaround, that always sets the directory but it would not work if the user opted for --without-gdbscripts-dir. Maybe someone who has a deeper understanding of the Valgrind build mechanism can come up with a patch that works in all cases. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476553] RPM build of Valgrind 3.22.0 fails under RHEL8
https://bugs.kde.org/show_bug.cgi?id=476553
--- Comment #2 from Peter Klotz ---
Hi Mark
Thanks, your suggestion brought me a lot closer to building the RPM.
However at the end I got messages about unpackaged files:
> Checking for unpackaged file(s): /usr/lib/rpm/check-files
> /home/user/rpmbuild/BUILDROOT/valgrind-3.22.0.x86_64
> error: Installed (but unpackaged) file(s) found:
>
> /usr/lib/debug/usr/libexec/valgrind/cachegrind-amd64-linux-3.22.0.x86_64.debug
>...
>/usr/libexec/valgrind/32bit-core-valgrind-s1.xml
>
> RPM build errors:
> Installed (but unpackaged) file(s) found:
>
> /usr/lib/debug/usr/libexec/valgrind/cachegrind-amd64-linux-3.22.0.x86_64.debug
>...
>/usr/libexec/valgrind/32bit-core-valgrind-s1.xml
>...
To fix those, another patch was needed:
> diff -Nur valgrind-3.22.0/valgrind.spec valgrind-3.22.0.patched/valgrind.spec
> --- valgrind-3.22.0/valgrind.spec 2023-10-31 18:26:43.0 +0100
> +++ valgrind-3.22.0.patched/valgrind.spec 2023-11-08 07:13:21.246612838
> +0100
> @@ -42,6 +42,7 @@
> %{_includedir}/valgrind
> %{_libdir}/valgrind
> %{_libdir}/pkgconfig/*
> +%{_libexecdir}/valgrind
>
> %doc
> %defattr(-,root,root)
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 476553] New: RPM build of Valgrind 3.22.0 fails under RHEL8
https://bugs.kde.org/show_bug.cgi?id=476553 Bug ID: 476553 Summary: RPM build of Valgrind 3.22.0 fails under RHEL8 Classification: Developer tools Product: valgrind Version: 3.22 GIT Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: peter.klot...@gmail.com Target Milestone: --- SUMMARY Building an RPM of Valgrind 3.22.0 does not work under Red Hat Enterprise Linux 8 STEPS TO REPRODUCE 1. Execute "rpmbuild -tb valgrind-3.22.0.tar.bz2" on a fully patched RHEL 8.8 system 2. One obtains the error messages below OBSERVED RESULT The error messages: --- /usr/bin/mkdir -p '/usr/libexec/valgrind' /usr/bin/install -c -m 644 m_gdbserver/valgrind-monitor.py m_gdbserver/valgrind-monitor-def.py '/usr/libexec/valgrind' /usr/bin/install: cannot create regular file '/usr/libexec/valgrind/valgrind-monitor.py': Permission denied /usr/bin/install: cannot create regular file '/usr/libexec/valgrind/valgrind-monitor-def.py': Permission denied make[4]: *** [Makefile:9424: install-gdbscriptsDATA] Error 1 make[4]: Leaving directory '/home/user/rpmbuild/BUILD/valgrind-3.22.0/coregrind' make[3]: *** [Makefile:9565: install-am] Error 2 make[3]: Leaving directory '/home/user/rpmbuild/BUILD/valgrind-3.22.0/coregrind' make[2]: *** [Makefile:9558: install] Error 2 make[2]: Leaving directory '/home/user/rpmbuild/BUILD/valgrind-3.22.0/coregrind' make[1]: *** [Makefile:918: install-recursive] Error 1 make[1]: Leaving directory '/home/user/rpmbuild/BUILD/valgrind-3.22.0' make: *** [Makefile:1225: install] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.Jax4dz (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.Jax4dz (%install) --- EXPECTED RESULT It should build, like 3.21.0 did. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #46 from Peter Klotz --- Is there a chance that the available fix for this issue will make it into the upcoming Valgrind version (3.18 I assume)? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #15 from Peter Klotz --- Hi Eyal Your patch indeed solves the Valgrind error that occurred in the original program. Really great work, thanks a lot! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #10 from Peter Klotz --- Hi Eyal Thank you very much for the analysis of the problem! Will you open an LLVM issue? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #4 from Peter Klotz --- Created attachment 135597 --> https://bugs.kde.org/attachment.cgi?id=135597=edit Disassembly of main() when Valgrind shows no warning The second sigaction() call was removed. In this case the assembly code of main() looks very similar to the original one. In all other cases (e.g. removing the pattern[0] assignment or replacing the myLen() call with a constant) the disassembly looks much simpler. It seems the compiler optimization removes most of the code. This is interesting because my assumption was that "volatile" should prevent the compiler from doing so. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #3 from Peter Klotz --- Created attachment 135596 --> https://bugs.kde.org/attachment.cgi?id=135596=edit Disassembly of main() when Valgrind shows the warning -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 320546] valgrind exits with "Assertion 'in_rx' failed" for /system/lib/libva-android.so on Android 4.0.4
https://bugs.kde.org/show_bug.cgi?id=320546 Peter Klotz changed: What|Removed |Added CC||peter.klot...@gmail.com --- Comment #3 from Peter Klotz --- Bug 389412 describes the same assertion for clang under Linux. In our case the upgrade from clang 7 to 11 solved the problem. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] New: Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Bug ID: 432801 Summary: Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: peter.klot...@gmail.com Target Milestone: --- Created attachment 135595 --> https://bugs.kde.org/attachment.cgi?id=135595=edit The test program The attached program (extracted from a much larger piece of code) gives us this report: ==2193718== Conditional jump or move depends on uninitialised value(s) ==2193718==at 0x20199D: main (Standalone.c:33) ==2193718== Uninitialised value was created by a stack allocation ==2193718==at 0x201A90: ??? (in a.out) STEPS TO REPRODUCE clang -W -Wall -g -O2 Standalone.c && valgrind --track-origins=yes ./a.out According to objdump the allocation happens in sigaction(): 201a90: ff 25 ea 21 00 00 jmpq *0x21ea(%rip)# 203c80 The use of the uninitialized memory then occurs in line 33 which reads "if (hs==hp)". It is unclear how something that sigaction() does could affect those two local variables. Some strange facts about the issue: * It only occurs with clang (tested with 11.0.0 and 11.0.1), not with gcc (8.3.1 and 4.8.5) * It only happens when -O2 is specified, not with -O1 * It occurs under RHEL 8 (glibc 2.28) and Arch Linux (glibc 2.33) but not RHEL 7 (glibc 2.17) * The problem goes away if slight, seemingly unrelated modifications are made to the program + Skip assignment to variable pattern[0] + Change all size_t variables to unsigned int + Call sigaction() only once + Replace the myLen() call with a constant We are in no way sure, this is a Valgrind issue, it could be a miscompile by clang or a subtle error in the program we are missing. So our hope is that someone with deeper knowledge can point us into the right direction. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389412] Failed assertion in readelf.c, line 697 for clang binaries with coverage information
https://bugs.kde.org/show_bug.cgi?id=389412 Peter Klotz changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #6 from Peter Klotz --- After switching to clang 11 the problem disappeared. It is our assumption that the way how older clang versions (particularly 5 and 7) used to write the debug information into the binary was a contributing factor. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389412] Failed assertion in readelf.c, line 697 for clang binaries with coverage information
https://bugs.kde.org/show_bug.cgi?id=389412 --- Comment #2 from Peter Klotz --- Hi Julian A test with the git snapshot from today showed that the assertion is still triggered (just the line number has changed): valgrind: m_debuginfo/readelf.c:715 (get_elf_symbol_info): Assertion 'in_rx' failed. Regards, Peter -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389412] New: Failed assertion in readelf.c, line 697 for clang binaries with coverage information
https://bugs.kde.org/show_bug.cgi?id=389412
Bug ID: 389412
Summary: Failed assertion in readelf.c, line 697 for clang
binaries with coverage information
Product: valgrind
Version: 3.13.0
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: peter.klot...@gmail.com
Target Milestone: ---
Approximately 1% of our internal regression tests show a failed assertion when
run with Valgrind 3.13.0:
"valgrind: m_debuginfo/readelf.c:697 (get_elf_symbol_info): Assertion 'in_rx'
failed."
This only happens if the code is compiled with clang (5.0.1 on RHEL 7 x86_64)
together with coverage information options ("-fprofile-instr-generate
-fcoverage-mapping"). Valgrind runs fine without the coverage options or if gcc
is used. The problem occurs with the Google gold linker and also with the LLVM
lld linker.
We tracked it down to a single find_rx_mapping() call that returns 0 (via the
"return NULL" at the end of the method).
Call: find_rx_mapping(DebugInfo=0x100287C470, lo=3ef0e8, hi=42a0f7)
In a "readelf -aW" output the symbol causing the assertion seems to be
"__llvm_coverage_mapping":
9458: 003ef0e8 0x3b010 OBJECT LOCAL DEFAULT 33
__llvm_coverage_mapping
9459: 0 FILELOCAL DEFAULT ABS /.../SourceFile.cpp
Since variable "in_text" in get_elf_symbol_info() is true, the assertion
"vg_assert(in_rx);" fails.
Here a "--trace-symtab=yes" output from Valgrind:
--
raw symbol [9453]: LOC FUN : svma 0x42de90, sz 18
__cxx_global_var_init.68
rec(t) [9453]:val 0x42de90, sz 18
__cxx_global_var_init.68
raw symbol [9454]: LOC FUN : svma 0x42deb0, sz 18
__cxx_global_var_init.69
rec(t) [9454]:val 0x42deb0, sz 18
__cxx_global_var_init.69
raw symbol [9455]: LOC FUN : svma 0x42d6f0, sz 26
__cxx_global_var_init.7
rec(t) [9455]:val 0x42d6f0, sz 26
__cxx_global_var_init.7
raw symbol [9456]: LOC FUN : svma 0x42d710, sz 26
__cxx_global_var_init.8
rec(t) [9456]:val 0x42d710, sz 26
__cxx_global_var_init.8
raw symbol [9457]: LOC FUN : svma 0x42d730, sz 26
__cxx_global_var_init.9
rec(t) [9457]:val 0x42d730, sz 26
__cxx_global_var_init.9
raw symbol [9458]: LOC OBJ : svma 0x3ef0e8, sz 241680
__llvm_coverage_mapping
valgrind: m_debuginfo/readelf.c:697 (get_elf_symbol_info): Assertion 'in_rx'
failed.
--
Please let me know, if any additional information or further testing is needed.
Regards, Peter.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 384727] valgrind does not support debug info for read only segments (generated by LLD)
https://bugs.kde.org/show_bug.cgi?id=384727 Peter Klotz <peter.klot...@gmail.com> changed: What|Removed |Added CC||peter.klot...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
