Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John R. <jr...@bi...> - 2024-12-14 21:17:42
|
>> Building proceeds until
>> ===== (Note "-m32")
>> $ gcc -m64 ... -static ... -m32 -o vgpreload_core-arm-linux.so \
>> vgpreload_core_arm_linux_so_preloaded.o
>> ld.lld: error: unable to find library -lc
>> =====
>> which I workaround by running "gcc -v ...", to get the command line,
>> then manually running the 'ld' without the "-lc". So gcc adding
>> "-lc" was not necessary?
>
>
> What is the full text of the line for linking vgpreload_core-arm-linux.so?
Moving the old outputs out of the way (vgpreload_core-arm-linux.so.save
and vgpreload_core-arm64-linux.so.save), and adding "-v" to what "make"
says when run from directory 'coregrind':
=====
$ gcc -v -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith
-Wstrict-prototypes -Wmissing-declarations -Wno-unused-result
-Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat
-Wformat-signedness -Wformat-security -Wignored-qualifiers
-Wenum-conversion -finline-functions -fno-stack-protector
-fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign
-Wno-tautological-compare -O -g -fno-omit-frame-pointer
-fno-strict-aliasing -fpic -fno-builtin -nodefaultlibs -shared
-Wl,-z,interpose,-z,initfirst -nostdlib -m32 -o
vgpreload_core-arm-linux.so vgpreload_core_arm_linux_so-vg_preloaded.o
clang version 19.1.5
Target: arm-unknown-linux-android24
Thread model: posix
InstalledDir: /data/data/com.termux/files/usr/bin
"/data/data/com.termux/files/usr/bin/ld.lld"
--sysroot=/data/data/com.termux/files -EL -z now -z relro -z
max-page-size=4096 -X --hash-style=gnu
-rpath=/data/data/com.termux/files/usr/arm-linux-androideabi/lib
--eh-frame-hdr -m armelf_linux_eabi -shared -o
vgpreload_core-arm-linux.so
-L/data/data/com.termux/files/usr/arm-linux-androideabi/lib
-L/system/lib -z interpose -z initfirst
vgpreload_core_arm_linux_so-vg_preloaded.o
=====
and it succeeded (no complaint). So I don't know where "-lc"
came from the first time.
I also ran that gcc command under "strace -f -e trace=open,openat -o
strace.out" to see what filenames the linker was trying.
The strace gave 212 lines that all were 'openat',
and applying "grep libc" yields
=====
22993 openat(AT_FDCWD, "/data/data/com.termux/files/usr/lib/libc.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
22993 openat(AT_FDCWD, "/system/lib64/libc.so", O_RDONLY|O_CLOEXEC) = 4
22993 openat(AT_FDCWD,
"/data/data/com.termux/files/usr/lib/libclang-cpp.so",
O_RDONLY|O_CLOEXEC) = 5
22993 openat(AT_FDCWD,
"/data/data/com.termux/files/usr/lib/libc++_shared.so",
O_RDONLY|O_CLOEXEC) = 7
22993 openat(AT_FDCWD,
"/dev/__properties__/u:object_r:libc_debug_prop:s0",
O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 3
22993 openat(AT_FDCWD, "/system/lib64/libc++.so", O_RDONLY|O_CLOEXEC) = 4
22994 openat(AT_FDCWD, "/data/data/com.termux/files/usr/lib/libc.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
22994 openat(AT_FDCWD, "/system/lib64/libc.so", O_RDONLY|O_CLOEXEC) = 4
22994 openat(AT_FDCWD,
"/data/data/com.termux/files/usr/lib/libc++_shared.so",
O_RDONLY|O_CLOEXEC) = 8
22994 openat(AT_FDCWD,
"/dev/__properties__/u:object_r:libc_debug_prop:s0",
O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 3
22994 openat(AT_FDCWD, "/system/lib64/libc++.so", O_RDONLY|O_CLOEXEC) = 4
=====
>> =====
>> $ cd coregrind
>> $ ./valgrind
>> error: "./valgrind": executable's TLS segment is underaligned: \
>> alignment is 8 (skew 0), needs to be at least 64 for ARM64 Bionic
>> Aborted
>> $ echo $?
>> 134 ## error 6 (134 - 128) ENXIO
>> $
>> =====
>>
>> So now it's time to get the linker script from "ld --verbose ...",
>> then make TLS 64-byte aligned. To be continued ...
>
> Do the Google/Android folks have any Valgrind patches for these issues?
I ran "ld --verbose > android.lds" [notice not the same as 'ld.lld',
which did not recognize '--verbose'],
lopped off the prefix and suffix lines marked by "==========",
and changed one line to ".tdata : align(64)". Then
adding "-T android.lds" to the linker command line that creates
'valgrind', and applying "readelf --segments" gave
=====
TLS 0x000000000006c000 0x000000000046c000 0x000000000046c000
0x0000000000000008 0x0000000000000008 R 0x40
=====
which did achieve 64-byte alignment in the Elf64_Phdr for TLS.
But 'vagrind' still won't run:
=====
$ gdb -q ./valgrind
Reading symbols from ./valgrind...
(gdb) x/5i _start ## disassemble from entry point
0x4003ec <_start>: bti j ## legal target for indirect branch
0x4003f0 <_start+4>: mov x29, #0x0 // #0
0x4003f4 <_start+8>: mov x30, #0x0 // #0
0x4003f8 <_start+12>: mov x0, sp
0x4003fc <_start+16>: b 0x400400 <_start_main>
(gdb) run
Starting program:
/data/data/com.termux/files/home/valgrind/coregrind/valgrind
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) info proc
No current process: you must name one.
=====
and the process is empty: no registers. So Android kernel refused
to perform the 'execve'. Must be the layout of PT_LOAD, or the
Section table, or the symbol table, or being "-static" (no shared
libraries), or ...
|
|
From: Paul F. <pj...@wa...> - 2024-12-14 07:13:40
|
On 14-12-24 04:11, John Reiser wrote:
>> I've tried to build the last release but have not resolved the place
>> why it tries to link against the non-existing libc and how to fix that...
>
> Here are some workarounds:
>
> I'm trying to build valgrind (memcheck) for 32-bit programs on Android
> running under 64-bit TermUX on 64-bit Android 14. A fully-static 32-
> bit program created under Linux on [old] RaspberryPi does run
> under TermUX on my Samsung A9-Lite tablet with 3MB RAM! All building
> for valgrind was done on the tablet.
>
> Starting with "git clone; ./aclocal; ./configure --prefix=...";
> then in just a few minutes "make -j4" reaches
> =====
> $ gcc ... `m_coredump/coredump-elf.c
> m_coredump/coredump-elf.c:152:4: error: typedef redefinition with
> different types ('struct Elf32_Nhdr' vs 'struct elf32_note')
> 152 | Elf32_Nhdr;
> | ^
> /data/data/com.termux/files/usr/include/linux/elf.h:380:3: note:
> previous definition is here
> 380 | } Elf32_Nhdr;
> | ^
> m_coredump/coredump-elf.c:775:17: warning: variable 'name' set but not
> used [-Wunused-but-set-variable]
> 775 | const HChar* name;
> | ^
> =====
>
> My usr/include/elf.h from ndk-root version 27c does have a Elf32_Nhdr,
> so I patch with
> =====
> diff --git a/coregrind/m_coredump/coredump-elf.c b/coregrind/m_coredump/
> coredump-elf.c
> index a4632d9e2..aa58e6f48 100644
> --- a/coregrind/m_coredump/coredump-elf.c
> +++ b/coregrind/m_coredump/coredump-elf.c
> @@ -140,8 +140,8 @@ static void fill_phdr(ESZ(Phdr) *phdr, const
> NSegment *seg, UInt off, Bool write
> phdr->p_align = VKI_PAGE_SIZE;
> }
>
> -#if defined(VGPV_arm_linux_android) || defined(VGPV_x86_linux_android) \
> - || defined(VGPV_mips32_linux_android)
> +#if 0 && ( defined(VGPV_arm_linux_android) ||
> defined(VGPV_x86_linux_android) \
> + || defined(VGPV_mips32_linux_android))
> /* Android's libc doesn't provide a definition for this. Hence: */
> typedef
> struct {
> =====
If elf.h doesn't indicate that it has a Elf32_Nhdr then we could add a
configure check for that. See
https://bugs.kde.org/show_bug.cgi?id=339861. Do we need to keep
backwards compatibility with the old systems that didn't have Elf32_Nhdr?
> Building proceeds until
> ===== (Note "-m32")
> $ gcc -m64 ... -static ... -m32 -o vgpreload_core-arm-linux.so \
> vgpreload_core_arm_linux_so_preloaded.o
> ld.lld: error: unable to find library -lc
> =====
> which I workaround by running "gcc -v ...", to get the command line,
> then manually running the 'ld' without the "-lc". So gcc adding
> "-lc" was not necessary?
What is the full text of the line for linking vgpreload_core-arm-linux.so?
I don't know where -lc is coming from, maybe implicitly with lld and it
needs -nostdlib.
Also I don't see how both -m32 and -m64 get added. In this case it seems
harmless as the later -m32 will be taken.
> More building until (in directory coregrind):
> ===== (Note no "-m32")
> $ gcc -m64 ... -static ... -o valgrind \
> valgrind-launcher-linux.o valgrind-m_debuglog.o
> ld.lld: error: unable to find library -lc
> =====
>
> Next "dpkg --search libc.a" shows a nice-looking
> usr/opt/ndk-multilib/aarch64-linux-android/lib/libc.a
> and manually adding that appears to succeed:
> =====
> $ cd /data/data/com.termux/files/home/valgrind/coregrind
> $ ld -o valgrind valgrind-launcher-linux.o valgrind-m_debuglog.o \
>
> /data/data/com.termux/files/usr/opt/ndk-multilib/aarch64-linux-android/
> lib/libc.a
> $ readelf --all --wide valgrind >valgrind.readelfcd ..
> # 5744 lines; 10 Program headers; 29 Sections
> # Header Offset VirtAddr PhysAddr Fsiz Msiz Flg Align
> # TLS 0x069870 0x271870 0x271870 8 8 R 0x8
> =====
>
> But a trial run fails:
> =====
> $ cd coregrind
> $ ./valgrind
> error: "./valgrind": executable's TLS segment is underaligned: \
> alignment is 8 (skew 0), needs to be at least 64 for ARM64 Bionic
> Aborted
> $ echo $?
> 134 ## error 6 (134 - 128) ENXIO
> $
> =====
>
> So now it's time to get the linker script from "ld --verbose ...",
> then make TLS 64-byte aligned. To be continued ...
Do the Google/Android folks have any Valgrind patches for these issues?
A+
Paul
|
|
From: John R. <jr...@bi...> - 2024-12-14 03:12:00
|
> I've tried to build the last release but have not resolved the place why
> it tries to link against the non-existing libc and how to fix that...
Here are some workarounds:
I'm trying to build valgrind (memcheck) for 32-bit programs on Android
running under 64-bit TermUX on 64-bit Android 14. A fully-static 32-
bit program created under Linux on [old] RaspberryPi does run
under TermUX on my Samsung A9-Lite tablet with 3MB RAM! All building
for valgrind was done on the tablet.
Starting with "git clone; ./aclocal; ./configure --prefix=...";
then in just a few minutes "make -j4" reaches
=====
$ gcc ... `m_coredump/coredump-elf.c
m_coredump/coredump-elf.c:152:4: error: typedef redefinition with
different types ('struct Elf32_Nhdr' vs 'struct elf32_note')
152 | Elf32_Nhdr;
| ^
/data/data/com.termux/files/usr/include/linux/elf.h:380:3: note:
previous definition is here
380 | } Elf32_Nhdr;
| ^
m_coredump/coredump-elf.c:775:17: warning: variable 'name' set but not
used [-Wunused-but-set-variable]
775 | const HChar* name;
| ^
=====
My usr/include/elf.h from ndk-root version 27c does have a Elf32_Nhdr,
so I patch with
=====
diff --git a/coregrind/m_coredump/coredump-elf.c
b/coregrind/m_coredump/coredump-elf.c
index a4632d9e2..aa58e6f48 100644
--- a/coregrind/m_coredump/coredump-elf.c
+++ b/coregrind/m_coredump/coredump-elf.c
@@ -140,8 +140,8 @@ static void fill_phdr(ESZ(Phdr) *phdr, const
NSegment *seg, UInt off, Bool write
phdr->p_align = VKI_PAGE_SIZE;
}
-#if defined(VGPV_arm_linux_android) || defined(VGPV_x86_linux_android) \
- || defined(VGPV_mips32_linux_android)
+#if 0 && ( defined(VGPV_arm_linux_android) ||
defined(VGPV_x86_linux_android) \
+ || defined(VGPV_mips32_linux_android))
/* Android's libc doesn't provide a definition for this. Hence: */
typedef
struct {
=====
Building proceeds until
===== (Note "-m32")
$ gcc -m64 ... -static ... -m32 -o vgpreload_core-arm-linux.so \
vgpreload_core_arm_linux_so_preloaded.o
ld.lld: error: unable to find library -lc
=====
which I workaround by running "gcc -v ...", to get the command line,
then manually running the 'ld' without the "-lc". So gcc adding
"-lc" was not necessary?
More building until (in directory coregrind):
===== (Note no "-m32")
$ gcc -m64 ... -static ... -o valgrind \
valgrind-launcher-linux.o valgrind-m_debuglog.o
ld.lld: error: unable to find library -lc
=====
Next "dpkg --search libc.a" shows a nice-looking
usr/opt/ndk-multilib/aarch64-linux-android/lib/libc.a
and manually adding that appears to succeed:
=====
$ cd /data/data/com.termux/files/home/valgrind/coregrind
$ ld -o valgrind valgrind-launcher-linux.o valgrind-m_debuglog.o \
/data/data/com.termux/files/usr/opt/ndk-multilib/aarch64-linux-android/lib/libc.a
$ readelf --all --wide valgrind >valgrind.readelfcd ..
# 5744 lines; 10 Program headers; 29 Sections
# Header Offset VirtAddr PhysAddr Fsiz Msiz Flg Align
# TLS 0x069870 0x271870 0x271870 8 8 R 0x8
=====
But a trial run fails:
=====
$ cd coregrind
$ ./valgrind
error: "./valgrind": executable's TLS segment is underaligned: \
alignment is 8 (skew 0), needs to be at least 64 for ARM64 Bionic
Aborted
$ echo $?
134 ## error 6 (134 - 128) ENXIO
$
=====
So now it's time to get the linker script from "ld --verbose ...",
then make TLS 64-byte aligned. To be continued ...
|
|
From: Paul F. <pj...@wa...> - 2024-12-13 20:08:01
|
On 13/12/2024 16:26, Simon Sobisch wrote: > Daear valgrind users and devs, > > Valgrind-3.22.0 and asserts reproducible on > aarch64-unknown-linux-android (with several applications) as follows: > > valgrind: > /home/builder/.termux-build/valgrind/src/coregrind/m_redir.c:796 (void > vgPlain_redir_add_ifunc_target(Addr, Addr)): Assertion 'old' failed. This does look like https://bugs.kde.org/show_bug.cgi?id=327427 > > host stacktrace: > ==27034== at 0x5802EB10: ??? (in > /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux) > ==27034== by 0x5802EE4B: ??? (in > /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux) > ==27034== by 0x5802EE27: ??? (in > /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux) > ==27034== by 0x58041BB3: ??? (in > /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux) > ==27034== by 0x5809247B: ??? (in > /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux) > ==27034== by 0x580A180B: ??? (in > /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux) > ==27034== by 0xFFFFFFFFFFFFFFFF: ??? > Unfortunately Valgrind has failed to read its own debuginfo, so this not much use to us. > sched status: > running_tid=1 > > Thread 1: status = VgTs_Runnable (lwpid 27034) > ==27034== at 0x5DE8460: ??? (in > /data/data/com.termux/files/usr/libexec/valgrind/vgpreload_core-arm64-linux.so) > client stack range: [0x1FFEFF9000 0x1FFF000FFF] client SP: 0x1FFEFFCAC0 > valgrind stack range: [0x1002CBC000 0x1002DBBFFF] top usage: 12432 of > 1048576 > > > Following the output of the assert I've found > https://bugs.kde.org/show_bug.cgi?id=327427 > but the test w/wo --keep-debuginfos=yes / no showed the same > stacktrace in this case. > --keep-debuginfo, IIRC, is only related to keeping debuginfo for shared libraries that get loaded and unoaded. > The application does not show any errors in other environments. > > In this environment we get a bunch of warnings > Conditional jump or move depends on uninitialised value(s) > Use of uninitialised value of size 8 You need to analyze them. > in C posix functions from the binary > /apex/com.android.runtime/bin/linker64 (memcpy, strlen, ...) which I > _guess_ is not related to this error. > That could be due to Valgrind not redirecting those functions. > Is there something that's "known" which I've overlooked (FAQ has no > entries on this, changelog from newer versions did not show anything > that seems related)? > > > I've tried to build the last release but have not resolved the place > why it tries to link against the non-existing libc and how to fix that... > Sorry, but we don't have anyone that uses Android working on Valgrind as far as I know. Not much has been done that is Android specific for quite a while. aarch64 is getting some fixes and enhancements. A+ Paul |
|
From: Simon S. <sim...@gn...> - 2024-12-13 15:27:38
|
Daear valgrind users and devs,
Valgrind-3.22.0 and asserts reproducible on
aarch64-unknown-linux-android (with several applications) as follows:
valgrind:
/home/builder/.termux-build/valgrind/src/coregrind/m_redir.c:796 (void
vgPlain_redir_add_ifunc_target(Addr, Addr)): Assertion 'old' failed.
host stacktrace:
==27034== at 0x5802EB10: ??? (in
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034== by 0x5802EE4B: ??? (in
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034== by 0x5802EE27: ??? (in
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034== by 0x58041BB3: ??? (in
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034== by 0x5809247B: ??? (in
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034== by 0x580A180B: ??? (in
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034== by 0xFFFFFFFFFFFFFFFF: ???
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 27034)
==27034== at 0x5DE8460: ??? (in
/data/data/com.termux/files/usr/libexec/valgrind/vgpreload_core-arm64-linux.so)
client stack range: [0x1FFEFF9000 0x1FFF000FFF] client SP: 0x1FFEFFCAC0
valgrind stack range: [0x1002CBC000 0x1002DBBFFF] top usage: 12432 of
1048576
Following the output of the assert I've found
https://bugs.kde.org/show_bug.cgi?id=327427
but the test w/wo --keep-debuginfos=yes / no showed the same stacktrace
in this case.
The application does not show any errors in other environments.
In this environment we get a bunch of warnings
Conditional jump or move depends on uninitialised value(s)
Use of uninitialised value of size 8
in C posix functions from the binary
/apex/com.android.runtime/bin/linker64 (memcpy, strlen, ...) which I
_guess_ is not related to this error.
Is there something that's "known" which I've overlooked (FAQ has no
entries on this, changelog from newer versions did not show anything
that seems related)?
I've tried to build the last release but have not resolved the place why
it tries to link against the non-existing libc and how to fix that...
Any hints on the bug issue (or the linking) welcome,
Simon
|
|
From: Wojciech B. <woj...@gm...> - 2024-12-10 13:12:05
|
Hello again, I was able to figure out the problem. It turns out this range: scan 0x53c4000-0x14dc4000 (262144000) --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel Corresponds to the area that the application obtains with mmap(). It reserves 250 MB of memory and mmap() returns success both in the VM and in the container. Then the application checks if the whole region is accessible by gradually memsetting it to 0, intercepting SIGSEGV and SIGBUS signals, and then reporting how much of that range it was able to zero. It turns out that in the case of the container, only 64MB of that is accessible, and the application reports that as a warning that I missed. This limit is just a default docker uses. All started working as soon as I specified shm_size=256MB in my docker compose file. Thank you for your help. Kind regards, Wojciech On Tue, Dec 10, 2024 at 10:22 AM Wojciech Bocer <woj...@gm...> wrote: > > Hello again, > > Thank both of you John and Paul for helping me out. > > I changed the mentioned macros and compiled valgrind. The outcome of > the test is the same. However I can see additional debug output in the > logs. > > There is a repeating pattern, Valgrind scans the same memory region > and something happens there: > scan 0x4fc1000-0x4fc4000 (12288) > scan 0x53c4000-0x14dc4000 (262144000) > --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > > Now the valgrind will repeatedly output the last line. > > Below are some logs from 3 processes that produce extensive log files. > > Kind regards, > Wojciech > > 1. Log file for process 3477 (260MB when valgrind killed): > > ==00:00:00:01.741 3477== Memcheck, a memory error detector > ==00:00:00:01.741 3477== Copyright (C) 2002-2024, and GNU GPL'd, by > Julian Seward et al. > ==00:00:00:01.741 3477== Using Valgrind-3.24.0-fcdaa47426-20241101X > and LibVEX; rerun with -h for copyright info > ==00:00:00:01.741 3477== Command: bin/gm_server --master > XXXXXXXXXXXXXXXXXXXXXXXX > ==00:00:00:01.741 3477== Parent PID: 3461 > ==00:00:00:01.741 3477== > --00:00:00:01.741 3477-- > --00:00:00:01.741 3477-- Valgrind options: > --00:00:00:01.741 3477-- --log-file=/tmp/valgrind/memcheck-%p.log > --00:00:00:01.741 3477-- --tool=memcheck > --00:00:00:01.741 3477-- --leak-check=summary > --00:00:00:01.741 3477-- --time-stamp=yes > --00:00:00:01.741 3477-- --track-fds=no > --00:00:00:01.741 3477-- --trace-signals=yes > --00:00:00:01.741 3477-- --track-origins=no > --00:00:00:01.741 3477-- --trace-children=yes > --00:00:00:01.741 3477-- > --trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc > --00:00:00:01.741 3477-- --vgdb=no > --00:00:00:01.741 3477-- --error-limit=no > --00:00:00:01.741 3477-- --verbose > --00:00:00:01.741 3477-- Contents of /proc/version: > --00:00:00:01.741 3477-- Linux version 6.11.9-100.fc39.x86_64 > (mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1 > 20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP > PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024 > --00:00:00:01.741 3477-- > --00:00:00:01.741 3477-- Arch and hwcaps: X86, LittleEndian, > x86-mmxext-sse1-sse2-sse3-lzcnt > --00:00:00:01.741 3477-- Page sizes: currently 4096, max supported 4096 > --00:00:00:01.741 3477-- Valgrind library directory: /usr/local/libexec/valgrind > --00:00:00:01.750 3477-- sys_sigaction: sigNo 12, new 0xfeae4d34, old > 0x0, new flags 0x4000000 > --00:00:00:01.750 3477-- sys_sigaction: sigNo 10, new 0xfeae4d34, old > 0x0, new flags 0x4000000 > --00:00:00:01.751 3477-- sys_sigaction: sigNo 15, new 0xfeae4d34, old > 0x0, new flags 0x4000000 > --00:00:00:01.752 3477-- sys_sigaction: sigNo 13, new 0xfeae4d34, old > 0x0, new flags 0x4000000 > --00:00:00:01.752 3477-- sys_sigaction: sigNo 2, new 0xfeae4d34, old > 0x0, new flags 0x4000000 > --00:00:00:01.753 3477-- sys_sigaction: sigNo 17, new 0xfeae4d34, old > 0x0, new flags 0x4000000 > --00:00:00:01.754 3477-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), > newset = 0x0 (NULL) > --00:00:00:01.754 3477-- oldset=0xFEAE4FCC 0000000000000000 > --00:00:00:01.757 3477-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), > newset = 0xFEAE4EA0 (fffffffe7ffee115) > --00:00:01:42.040 3477-- sys_sigaction: sigNo 11, new 0x82cfdeec, old > 0x0, new flags 0x0 > --00:00:01:42.040 3477-- sys_sigaction: sigNo 7, new 0x82cfdeec, old > 0x0, new flags 0x0 > --00:00:01:42.040 3477-- sys_sigaction: sigNo 4, new 0x82cfdee4, old > 0x0, new flags 0x0 > --00:00:01:42.040 3477-- sys_sigaction: sigNo 8, new 0x82cfdee4, old > 0x0, new flags 0x0 > --00:00:01:42.040 3477-- sys_sigaction: sigNo 31, new 0x82cfdedc, old > 0x0, new flags 0x0 > ==00:00:01:42.065 3477== > ==00:00:01:42.065 3477== HEAP SUMMARY: > ==00:00:01:42.065 3477== in use at exit: 2,440 bytes in 378 blocks > ==00:00:01:42.065 3477== total heap usage: 3,807 allocs, 3,429 > frees, 430,504 bytes allocated > ==00:00:01:42.065 3477== > ==00:00:01:42.065 3477== Searching for pointers to 378 not-freed blocks > scan 0x30d000-0x5d4000 (2912256) > ptr=0x502ac10 -> block 368 > ptr=0x503b100 -> block 373 > ptr=0x50200b0 -> block 299 > ptr=0x5020150 -> block 301 > ptr=0x50201f0 -> block 303 > ptr=0x5020600 -> block 316 > ptr=0x5020560 -> block 314 > ptr=0x503b160 -> block 374 > ptr=0x501fcf0 -> block 287 > ptr=0x501fd90 -> block 289 > ptr=0x501fc50 -> block 285 > ptr=0x503b100 -> block 373 > ptr=0x5018d80 -> block 0 > ptr=0x5018dd0 -> block 1 > ptr=0x5018e20 -> block 2 > ptr=0x5018e70 -> block 3 > ptr=0x5018ed0 -> block 4 > ptr=0x5018f40 -> block 5 > ptr=0x5018f90 -> block 6 > ptr=0x5018fe0 -> block 7 > ptr=0x5019030 -> block 8 > ptr=0x5019080 -> block 9 > ptr=0x50190d0 -> block 10 > ... > ptr=0x503b3b0 -> block 376 > ptr=0x501a0f3 -> block 61 > scan 0x5d4000-0x5dd000 (36864) > ptr=0x502ac10 -> block 368 > ptr=0x5024b70 -> block 352 > ptr=0x502a9d0 -> block 364 > ptr=0x502aa70 -> block 365 > ptr=0x502aa70 -> block 365 > ptr=0x502aac0 -> block 366 > ptr=0x501d850 -> block 236 > ptr=0x501d8a0 -> block 237 > scan 0x4036000-0x4037000 (4096) > scan 0x4037000-0x4038000 (4096) > scan 0x4837000-0x4839000 (8192) > scan 0x483d000-0x483e000 (4096) > scan 0x4858000-0x4859000 (4096) > scan 0x4861000-0x4862000 (4096) > scan 0x4872000-0x4873000 (4096) > scan 0x4873000-0x4875000 (8192) > scan 0x494c000-0x494f000 (12288) > scan 0x494f000-0x4950000 (4096) > scan 0x4d97000-0x4d99000 (8192) > scan 0x4d99000-0x4d9b000 (8192) > scan 0x4db8000-0x4db9000 (4096) > scan 0x4fb2000-0x4fb3000 (4096) > scan 0x4fb3000-0x4fb8000 (20480) > scan 0x4fbc000-0x4fbd000 (4096) > scan 0x4fc1000-0x4fc4000 (12288) > scan 0x53c4000-0x14dc4000 (262144000) > --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > > 2. Log file for process 3479 (335MB when valgrind killed): > > ==00:00:00:01.749 3479== Memcheck, a memory error detector > ==00:00:00:01.749 3479== Copyright (C) 2002-2024, and GNU GPL'd, by > Julian Seward et al. > ==00:00:00:01.749 3479== Using Valgrind-3.24.0-fcdaa47426-20241101X > and LibVEX; rerun with -h for copyright info > ==00:00:00:01.749 3479== Command: bin/gm_server --master > XXXXXXXXXXXXXXXXXXXXXXXX > ==00:00:00:01.749 3479== Parent PID: 3461 > ==00:00:00:01.749 3479== > --00:00:00:01.749 3479-- > --00:00:00:01.749 3479-- Valgrind options: > --00:00:00:01.749 3479-- --log-file=/tmp/valgrind/memcheck-%p.log > --00:00:00:01.749 3479-- --tool=memcheck > --00:00:00:01.749 3479-- --leak-check=summary > --00:00:00:01.749 3479-- --time-stamp=yes > --00:00:00:01.749 3479-- --track-fds=no > --00:00:00:01.749 3479-- --trace-signals=yes > --00:00:00:01.749 3479-- --track-origins=no > --00:00:00:01.749 3479-- --trace-children=yes > --00:00:00:01.749 3479-- > --trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc > --00:00:00:01.749 3479-- --vgdb=no > --00:00:00:01.749 3479-- --error-limit=no > --00:00:00:01.749 3479-- --verbose > --00:00:00:01.749 3479-- Contents of /proc/version: > --00:00:00:01.749 3479-- Linux version 6.11.9-100.fc39.x86_64 > (mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1 > 20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP > PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024 > --00:00:00:01.749 3479-- > --00:00:00:01.749 3479-- Arch and hwcaps: X86, LittleEndian, > x86-mmxext-sse1-sse2-sse3-lzcnt > --00:00:00:01.749 3479-- Page sizes: currently 4096, max supported 4096 > --00:00:00:01.749 3479-- Valgrind library directory: /usr/local/libexec/valgrind > --00:00:00:01.759 3479-- sys_sigaction: sigNo 12, new 0xfeae4cf4, old > 0x0, new flags 0x4000000 > --00:00:00:01.759 3479-- sys_sigaction: sigNo 10, new 0xfeae4cf4, old > 0x0, new flags 0x4000000 > --00:00:00:01.759 3479-- sys_sigaction: sigNo 15, new 0xfeae4cf4, old > 0x0, new flags 0x4000000 > --00:00:00:01.760 3479-- sys_sigaction: sigNo 13, new 0xfeae4cf4, old > 0x0, new flags 0x4000000 > --00:00:00:01.760 3479-- sys_sigaction: sigNo 2, new 0xfeae4cf4, old > 0x0, new flags 0x4000000 > --00:00:00:01.760 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), > newset = 0x0 (NULL) > --00:00:00:01.760 3479-- oldset=0xFEAE4FBC 0000000000000000 > --00:00:00:01.762 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), > newset = 0xFEAE4E60 (fffffffe7fffe115) > --00:00:00:01.765 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), > newset = 0xFEAE4FBC (0000000000000000) > --00:00:01:33.725 3479-- async signal handler: signal=15, vgtid=3479, > tid=1, si_code=0, exitreason VgSrc_None > --00:00:01:33.725 3479-- interrupted_syscall: tid=1, ip=0x580d540d, > restart=False, sres.isErr=True, sres.val=4 > --00:00:01:33.725 3479-- completed, but uncommitted: committing > --00:00:01:33.725 3479-- delivering signal 15 (SIGTERM):0 to thread 1 > --00:00:01:33.725 3479-- push_signal_frame (thread 1): signal 15 > ==00:00:01:33.725 3479== at 0x4E6D47B: __clock_nanosleep_time64 > (clock_nanosleep.c:62) > ==00:00:01:33.725 3479== by 0x4E80024: __nanosleep64 (nanosleep.c:25) > ==00:00:01:33.725 3479== by 0x4E80024: nanosleep (nanosleep.c:42) > ==00:00:01:33.725 3479== by 0x4E92263: sleep (sleep.c:55) > ==00:00:01:33.725 3479== by 0x1CF4A9: harmony_process (harmony.c:1320) > ==00:00:01:33.725 3479== by 0x1D0E02: harmony_run (harmony.c:1811) > ==00:00:01:33.725 3479== by 0x29BDC3: main (main.c:1054) > --00:00:01:33.726 3479-- VG_(sigframe_destroy) (thread 1): isRT=0 > valid magic; EIP=0x401b002 > --00:00:01:33.818 3479-- sys_sigaction: sigNo 11, new 0x82cfdeec, old > 0x0, new flags 0x0 > --00:00:01:33.818 3479-- sys_sigaction: sigNo 7, new 0x82cfdeec, old > 0x0, new flags 0x0 > --00:00:01:33.818 3479-- sys_sigaction: sigNo 4, new 0x82cfdee4, old > 0x0, new flags 0x0 > --00:00:01:33.818 3479-- sys_sigaction: sigNo 8, new 0x82cfdee4, old > 0x0, new flags 0x0 > --00:00:01:33.818 3479-- sys_sigaction: sigNo 31, new 0x82cfdedc, old > 0x0, new flags 0x0 > ==00:00:01:33.833 3479== > ==00:00:01:33.833 3479== HEAP SUMMARY: > ==00:00:01:33.833 3479== in use at exit: 2,440 bytes in 378 blocks > ==00:00:01:33.833 3479== total heap usage: 3,810 allocs, 3,432 > frees, 452,136 bytes allocated > ==00:00:01:33.833 3479== > ==00:00:01:33.833 3479== Searching for pointers to 378 not-freed blocks > scan 0x30d000-0x5d4000 (2912256) > ptr=0x502ac10 -> block 368 > ptr=0x503b100 -> block 373 > ptr=0x50200b0 -> block 299 > ptr=0x5020150 -> block 301 > ptr=0x50201f0 -> block 303 > ptr=0x5020600 -> block 316 > ptr=0x5020560 -> block 314 > ptr=0x503b160 -> block 374 > ptr=0x501fcf0 -> block 287 > ptr=0x501fd90 -> block 289 > ptr=0x501fc50 -> block 285 > ptr=0x503b100 -> block 373 > ptr=0x5018d80 -> block 0 > ptr=0x5018dd0 -> block 1 > ptr=0x5018e20 -> block 2 > ptr=0x5018e70 -> block 3 > ptr=0x5018ed0 -> block 4 > ptr=0x5018f40 -> block 5 > ptr=0x5018f90 -> block 6 > ptr=0x5018fe0 -> block 7 > ptr=0x5019030 -> block 8 > ptr=0x5019080 -> block 9 > ptr=0x50190d0 -> block 10 > ... > ptr=0x503b3b0 -> block 376 > ptr=0x501a0f3 -> block 61 > scan 0x5d4000-0x5dd000 (36864) > ptr=0x502ac10 -> block 368 > ptr=0x5024b70 -> block 352 > ptr=0x502a9d0 -> block 364 > ptr=0x502aa70 -> block 365 > ptr=0x502aa70 -> block 365 > ptr=0x502aac0 -> block 366 > ptr=0x501d850 -> block 236 > ptr=0x501d8a0 -> block 237 > scan 0x4036000-0x4037000 (4096) > scan 0x4037000-0x4038000 (4096) > scan 0x4837000-0x4839000 (8192) > scan 0x483d000-0x483e000 (4096) > scan 0x4858000-0x4859000 (4096) > scan 0x4861000-0x4862000 (4096) > scan 0x4872000-0x4873000 (4096) > scan 0x4873000-0x4875000 (8192) > scan 0x494c000-0x494f000 (12288) > scan 0x494f000-0x4950000 (4096) > scan 0x4d97000-0x4d99000 (8192) > scan 0x4d99000-0x4d9b000 (8192) > scan 0x4db8000-0x4db9000 (4096) > scan 0x4fb2000-0x4fb3000 (4096) > scan 0x4fb3000-0x4fb8000 (20480) > scan 0x4fbc000-0x4fbd000 (4096) > scan 0x4fc1000-0x4fc4000 (12288) > scan 0x53c4000-0x14dc4000 (262144000) > --00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > --00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > --00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > > 3. Log file for process 3491 (142MB when valgrind killed): > > ==00:00:00:02.218 3491== Memcheck, a memory error detector > ==00:00:00:02.218 3491== Copyright (C) 2002-2024, and GNU GPL'd, by > Julian Seward et al. > ==00:00:00:02.218 3491== Using Valgrind-3.24.0-fcdaa47426-20241101X > and LibVEX; rerun with -h for copyright info > ==00:00:00:02.218 3491== Command: bin/gm_server --master > XXXXXXXXXXXXXXXXXXXXXXXX > ==00:00:00:02.218 3491== Parent PID: 3461 > ==00:00:00:02.218 3491== > --00:00:00:02.218 3491-- > --00:00:00:02.218 3491-- Valgrind options: > --00:00:00:02.218 3491-- --log-file=/tmp/valgrind/memcheck-%p.log > --00:00:00:02.218 3491-- --tool=memcheck > --00:00:00:02.218 3491-- --leak-check=summary > --00:00:00:02.218 3491-- --time-stamp=yes > --00:00:00:02.218 3491-- --track-fds=no > --00:00:00:02.218 3491-- --trace-signals=yes > --00:00:00:02.218 3491-- --track-origins=no > --00:00:00:02.218 3491-- --trace-children=yes > --00:00:00:02.218 3491-- > --trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc > --00:00:00:02.218 3491-- --vgdb=no > --00:00:00:02.218 3491-- --error-limit=no > --00:00:00:02.218 3491-- --verbose > --00:00:00:02.218 3491-- Contents of /proc/version: > --00:00:00:02.218 3491-- Linux version 6.11.9-100.fc39.x86_64 > (mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1 > 20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP > PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024 > --00:00:00:02.218 3491-- > --00:00:00:02.218 3491-- Arch and hwcaps: X86, LittleEndian, > x86-mmxext-sse1-sse2-sse3-lzcnt > --00:00:00:02.218 3491-- Page sizes: currently 4096, max supported 4096 > --00:00:00:02.218 3491-- Valgrind library directory: /usr/local/libexec/valgrind > --00:00:00:02.227 3491-- sys_sigaction: sigNo 12, new 0xfeae4d04, old > 0x0, new flags 0x4000000 > --00:00:00:02.228 3491-- sys_sigaction: sigNo 10, new 0xfeae4d04, old > 0x0, new flags 0x4000000 > --00:00:00:02.228 3491-- sys_sigaction: sigNo 15, new 0xfeae4d04, old > 0x0, new flags 0x4000000 > --00:00:00:02.229 3491-- sys_sigaction: sigNo 13, new 0xfeae4d04, old > 0x0, new flags 0x4000000 > --00:00:00:02.229 3491-- sys_sigaction: sigNo 2, new 0xfeae4d04, old > 0x0, new flags 0x4000000 > --00:00:00:02.229 3491-- sys_sigaction: sigNo 17, new 0xfeae4d04, old > 0x0, new flags 0x4000000 > --00:00:00:02.230 3491-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), > newset = 0x0 (NULL) > --00:00:00:02.230 3491-- oldset=0xFEAE4FBC 0000000000000000 > --00:00:00:02.231 3491-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), > newset = 0xFEAE4E70 (fffffffe7ffee115) > --00:00:02:02.494 3491-- sys_sigaction: sigNo 11, new 0x82cfdeec, old > 0x0, new flags 0x0 > --00:00:02:02.494 3491-- sys_sigaction: sigNo 7, new 0x82cfdeec, old > 0x0, new flags 0x0 > --00:00:02:02.494 3491-- sys_sigaction: sigNo 4, new 0x82cfdee4, old > 0x0, new flags 0x0 > --00:00:02:02.494 3491-- sys_sigaction: sigNo 8, new 0x82cfdee4, old > 0x0, new flags 0x0 > --00:00:02:02.494 3491-- sys_sigaction: sigNo 31, new 0x82cfdedc, old > 0x0, new flags 0x0 > ==00:00:02:02.525 3491== > ==00:00:02:02.525 3491== HEAP SUMMARY: > ==00:00:02:02.525 3491== in use at exit: 20,649 bytes in 576 blocks > ==00:00:02:02.525 3491== total heap usage: 5,562 allocs, 4,986 > frees, 595,523 bytes allocated > ==00:00:02:02.525 3491== > ==00:00:02:02.526 3491== Searching for pointers to 576 not-freed blocks > scan 0x30d000-0x5d4000 (2912256) > ptr=0x502ac10 -> block 377 > ptr=0x503b100 -> block 382 > ptr=0x50200b0 -> block 308 > ptr=0x5020150 -> block 310 > ptr=0x50201f0 -> block 312 > ptr=0x5020600 -> block 325 > ptr=0x5020560 -> block 323 > ptr=0x503b160 -> block 383 > ptr=0x501fcf0 -> block 296 > ptr=0x501fd90 -> block 298 > ptr=0x501fc50 -> block 294 > ptr=0x503b100 -> block 382 > ptr=0x5018d80 -> block 9 > ptr=0x5018dd0 -> block 10 > ... > ptr=0x50b2770 -> block 558 > ptr=0x50b2880 -> block 560 > ptr=0x50b14d0 -> block 539 > ptr=0x50b09b0 -> block 538 > ptr=0x50a2f40 -> block 499 > scan 0x4036000-0x4037000 (4096) > scan 0x4037000-0x4038000 (4096) > scan 0x4837000-0x4839000 (8192) > scan 0x483d000-0x483e000 (4096) > scan 0x4858000-0x4859000 (4096) > scan 0x4861000-0x4862000 (4096) > scan 0x4872000-0x4873000 (4096) > scan 0x4873000-0x4875000 (8192) > scan 0x494c000-0x494f000 (12288) > scan 0x494f000-0x4950000 (4096) > scan 0x4d97000-0x4d99000 (8192) > scan 0x4d99000-0x4d9b000 (8192) > scan 0x4db8000-0x4db9000 (4096) > scan 0x4fb2000-0x4fb3000 (4096) > scan 0x4fb3000-0x4fb8000 (20480) > scan 0x4fbc000-0x4fbd000 (4096) > scan 0x4fc1000-0x4fc4000 (12288) > scan 0x53c4000-0x14dc4000 (262144000) > --00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > --00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > --00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2, > EIP=0x0, eip=0x58002e8d, from kernel > > On Mon, Dec 9, 2024 at 8:28 AM Paul Floyd via Valgrind-users > <val...@li...> wrote: > > > > > > > > On 05-12-24 14:19, Wojciech Bocer wrote: > > > Hello, > > > > > > I have a problem with Valgrind taking a lot of time trying to > > > determine if there are memory leaks before it exits. > > > > > > Roughly speaking leak detection involves scanning though all accessible > > memory using pointer-size alignment to look for any pointers to unfreed > > memory blocks. This code does handle segfaults. > > > > I don't have any real idea why the combination of x86 and Docker gives > > large numbers of segfaults and a major slowdown. > > > > I suggest that you get the source for Valgrind and set these macros in > > mc_leakcheck.c to 1 > > > > > > // Define to debug the memory-leak-detector. > > #define VG_DEBUG_FIND_CHUNK 0 > > #define VG_DEBUG_LEAKCHECK 0 > > #define VG_DEBUG_CLIQUE 0 > > > > and then build Valgrind. > > > > A+ > > Paul > > > > > > > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Wojciech B. <woj...@gm...> - 2024-12-10 09:23:02
|
Hello again, Thank both of you John and Paul for helping me out. I changed the mentioned macros and compiled valgrind. The outcome of the test is the same. However I can see additional debug output in the logs. There is a repeating pattern, Valgrind scans the same memory region and something happens there: scan 0x4fc1000-0x4fc4000 (12288) scan 0x53c4000-0x14dc4000 (262144000) --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel Now the valgrind will repeatedly output the last line. Below are some logs from 3 processes that produce extensive log files. Kind regards, Wojciech 1. Log file for process 3477 (260MB when valgrind killed): ==00:00:00:01.741 3477== Memcheck, a memory error detector ==00:00:00:01.741 3477== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==00:00:00:01.741 3477== Using Valgrind-3.24.0-fcdaa47426-20241101X and LibVEX; rerun with -h for copyright info ==00:00:00:01.741 3477== Command: bin/gm_server --master XXXXXXXXXXXXXXXXXXXXXXXX ==00:00:00:01.741 3477== Parent PID: 3461 ==00:00:00:01.741 3477== --00:00:00:01.741 3477-- --00:00:00:01.741 3477-- Valgrind options: --00:00:00:01.741 3477-- --log-file=/tmp/valgrind/memcheck-%p.log --00:00:00:01.741 3477-- --tool=memcheck --00:00:00:01.741 3477-- --leak-check=summary --00:00:00:01.741 3477-- --time-stamp=yes --00:00:00:01.741 3477-- --track-fds=no --00:00:00:01.741 3477-- --trace-signals=yes --00:00:00:01.741 3477-- --track-origins=no --00:00:00:01.741 3477-- --trace-children=yes --00:00:00:01.741 3477-- --trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc --00:00:00:01.741 3477-- --vgdb=no --00:00:00:01.741 3477-- --error-limit=no --00:00:00:01.741 3477-- --verbose --00:00:00:01.741 3477-- Contents of /proc/version: --00:00:00:01.741 3477-- Linux version 6.11.9-100.fc39.x86_64 (mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1 20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024 --00:00:00:01.741 3477-- --00:00:00:01.741 3477-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3-lzcnt --00:00:00:01.741 3477-- Page sizes: currently 4096, max supported 4096 --00:00:00:01.741 3477-- Valgrind library directory: /usr/local/libexec/valgrind --00:00:00:01.750 3477-- sys_sigaction: sigNo 12, new 0xfeae4d34, old 0x0, new flags 0x4000000 --00:00:00:01.750 3477-- sys_sigaction: sigNo 10, new 0xfeae4d34, old 0x0, new flags 0x4000000 --00:00:00:01.751 3477-- sys_sigaction: sigNo 15, new 0xfeae4d34, old 0x0, new flags 0x4000000 --00:00:00:01.752 3477-- sys_sigaction: sigNo 13, new 0xfeae4d34, old 0x0, new flags 0x4000000 --00:00:00:01.752 3477-- sys_sigaction: sigNo 2, new 0xfeae4d34, old 0x0, new flags 0x4000000 --00:00:00:01.753 3477-- sys_sigaction: sigNo 17, new 0xfeae4d34, old 0x0, new flags 0x4000000 --00:00:00:01.754 3477-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), newset = 0x0 (NULL) --00:00:00:01.754 3477-- oldset=0xFEAE4FCC 0000000000000000 --00:00:00:01.757 3477-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), newset = 0xFEAE4EA0 (fffffffe7ffee115) --00:00:01:42.040 3477-- sys_sigaction: sigNo 11, new 0x82cfdeec, old 0x0, new flags 0x0 --00:00:01:42.040 3477-- sys_sigaction: sigNo 7, new 0x82cfdeec, old 0x0, new flags 0x0 --00:00:01:42.040 3477-- sys_sigaction: sigNo 4, new 0x82cfdee4, old 0x0, new flags 0x0 --00:00:01:42.040 3477-- sys_sigaction: sigNo 8, new 0x82cfdee4, old 0x0, new flags 0x0 --00:00:01:42.040 3477-- sys_sigaction: sigNo 31, new 0x82cfdedc, old 0x0, new flags 0x0 ==00:00:01:42.065 3477== ==00:00:01:42.065 3477== HEAP SUMMARY: ==00:00:01:42.065 3477== in use at exit: 2,440 bytes in 378 blocks ==00:00:01:42.065 3477== total heap usage: 3,807 allocs, 3,429 frees, 430,504 bytes allocated ==00:00:01:42.065 3477== ==00:00:01:42.065 3477== Searching for pointers to 378 not-freed blocks scan 0x30d000-0x5d4000 (2912256) ptr=0x502ac10 -> block 368 ptr=0x503b100 -> block 373 ptr=0x50200b0 -> block 299 ptr=0x5020150 -> block 301 ptr=0x50201f0 -> block 303 ptr=0x5020600 -> block 316 ptr=0x5020560 -> block 314 ptr=0x503b160 -> block 374 ptr=0x501fcf0 -> block 287 ptr=0x501fd90 -> block 289 ptr=0x501fc50 -> block 285 ptr=0x503b100 -> block 373 ptr=0x5018d80 -> block 0 ptr=0x5018dd0 -> block 1 ptr=0x5018e20 -> block 2 ptr=0x5018e70 -> block 3 ptr=0x5018ed0 -> block 4 ptr=0x5018f40 -> block 5 ptr=0x5018f90 -> block 6 ptr=0x5018fe0 -> block 7 ptr=0x5019030 -> block 8 ptr=0x5019080 -> block 9 ptr=0x50190d0 -> block 10 ... ptr=0x503b3b0 -> block 376 ptr=0x501a0f3 -> block 61 scan 0x5d4000-0x5dd000 (36864) ptr=0x502ac10 -> block 368 ptr=0x5024b70 -> block 352 ptr=0x502a9d0 -> block 364 ptr=0x502aa70 -> block 365 ptr=0x502aa70 -> block 365 ptr=0x502aac0 -> block 366 ptr=0x501d850 -> block 236 ptr=0x501d8a0 -> block 237 scan 0x4036000-0x4037000 (4096) scan 0x4037000-0x4038000 (4096) scan 0x4837000-0x4839000 (8192) scan 0x483d000-0x483e000 (4096) scan 0x4858000-0x4859000 (4096) scan 0x4861000-0x4862000 (4096) scan 0x4872000-0x4873000 (4096) scan 0x4873000-0x4875000 (8192) scan 0x494c000-0x494f000 (12288) scan 0x494f000-0x4950000 (4096) scan 0x4d97000-0x4d99000 (8192) scan 0x4d99000-0x4d9b000 (8192) scan 0x4db8000-0x4db9000 (4096) scan 0x4fb2000-0x4fb3000 (4096) scan 0x4fb3000-0x4fb8000 (20480) scan 0x4fbc000-0x4fbd000 (4096) scan 0x4fc1000-0x4fc4000 (12288) scan 0x53c4000-0x14dc4000 (262144000) --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel 2. Log file for process 3479 (335MB when valgrind killed): ==00:00:00:01.749 3479== Memcheck, a memory error detector ==00:00:00:01.749 3479== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==00:00:00:01.749 3479== Using Valgrind-3.24.0-fcdaa47426-20241101X and LibVEX; rerun with -h for copyright info ==00:00:00:01.749 3479== Command: bin/gm_server --master XXXXXXXXXXXXXXXXXXXXXXXX ==00:00:00:01.749 3479== Parent PID: 3461 ==00:00:00:01.749 3479== --00:00:00:01.749 3479-- --00:00:00:01.749 3479-- Valgrind options: --00:00:00:01.749 3479-- --log-file=/tmp/valgrind/memcheck-%p.log --00:00:00:01.749 3479-- --tool=memcheck --00:00:00:01.749 3479-- --leak-check=summary --00:00:00:01.749 3479-- --time-stamp=yes --00:00:00:01.749 3479-- --track-fds=no --00:00:00:01.749 3479-- --trace-signals=yes --00:00:00:01.749 3479-- --track-origins=no --00:00:00:01.749 3479-- --trace-children=yes --00:00:00:01.749 3479-- --trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc --00:00:00:01.749 3479-- --vgdb=no --00:00:00:01.749 3479-- --error-limit=no --00:00:00:01.749 3479-- --verbose --00:00:00:01.749 3479-- Contents of /proc/version: --00:00:00:01.749 3479-- Linux version 6.11.9-100.fc39.x86_64 (mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1 20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024 --00:00:00:01.749 3479-- --00:00:00:01.749 3479-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3-lzcnt --00:00:00:01.749 3479-- Page sizes: currently 4096, max supported 4096 --00:00:00:01.749 3479-- Valgrind library directory: /usr/local/libexec/valgrind --00:00:00:01.759 3479-- sys_sigaction: sigNo 12, new 0xfeae4cf4, old 0x0, new flags 0x4000000 --00:00:00:01.759 3479-- sys_sigaction: sigNo 10, new 0xfeae4cf4, old 0x0, new flags 0x4000000 --00:00:00:01.759 3479-- sys_sigaction: sigNo 15, new 0xfeae4cf4, old 0x0, new flags 0x4000000 --00:00:00:01.760 3479-- sys_sigaction: sigNo 13, new 0xfeae4cf4, old 0x0, new flags 0x4000000 --00:00:00:01.760 3479-- sys_sigaction: sigNo 2, new 0xfeae4cf4, old 0x0, new flags 0x4000000 --00:00:00:01.760 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), newset = 0x0 (NULL) --00:00:00:01.760 3479-- oldset=0xFEAE4FBC 0000000000000000 --00:00:00:01.762 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), newset = 0xFEAE4E60 (fffffffe7fffe115) --00:00:00:01.765 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), newset = 0xFEAE4FBC (0000000000000000) --00:00:01:33.725 3479-- async signal handler: signal=15, vgtid=3479, tid=1, si_code=0, exitreason VgSrc_None --00:00:01:33.725 3479-- interrupted_syscall: tid=1, ip=0x580d540d, restart=False, sres.isErr=True, sres.val=4 --00:00:01:33.725 3479-- completed, but uncommitted: committing --00:00:01:33.725 3479-- delivering signal 15 (SIGTERM):0 to thread 1 --00:00:01:33.725 3479-- push_signal_frame (thread 1): signal 15 ==00:00:01:33.725 3479== at 0x4E6D47B: __clock_nanosleep_time64 (clock_nanosleep.c:62) ==00:00:01:33.725 3479== by 0x4E80024: __nanosleep64 (nanosleep.c:25) ==00:00:01:33.725 3479== by 0x4E80024: nanosleep (nanosleep.c:42) ==00:00:01:33.725 3479== by 0x4E92263: sleep (sleep.c:55) ==00:00:01:33.725 3479== by 0x1CF4A9: harmony_process (harmony.c:1320) ==00:00:01:33.725 3479== by 0x1D0E02: harmony_run (harmony.c:1811) ==00:00:01:33.725 3479== by 0x29BDC3: main (main.c:1054) --00:00:01:33.726 3479-- VG_(sigframe_destroy) (thread 1): isRT=0 valid magic; EIP=0x401b002 --00:00:01:33.818 3479-- sys_sigaction: sigNo 11, new 0x82cfdeec, old 0x0, new flags 0x0 --00:00:01:33.818 3479-- sys_sigaction: sigNo 7, new 0x82cfdeec, old 0x0, new flags 0x0 --00:00:01:33.818 3479-- sys_sigaction: sigNo 4, new 0x82cfdee4, old 0x0, new flags 0x0 --00:00:01:33.818 3479-- sys_sigaction: sigNo 8, new 0x82cfdee4, old 0x0, new flags 0x0 --00:00:01:33.818 3479-- sys_sigaction: sigNo 31, new 0x82cfdedc, old 0x0, new flags 0x0 ==00:00:01:33.833 3479== ==00:00:01:33.833 3479== HEAP SUMMARY: ==00:00:01:33.833 3479== in use at exit: 2,440 bytes in 378 blocks ==00:00:01:33.833 3479== total heap usage: 3,810 allocs, 3,432 frees, 452,136 bytes allocated ==00:00:01:33.833 3479== ==00:00:01:33.833 3479== Searching for pointers to 378 not-freed blocks scan 0x30d000-0x5d4000 (2912256) ptr=0x502ac10 -> block 368 ptr=0x503b100 -> block 373 ptr=0x50200b0 -> block 299 ptr=0x5020150 -> block 301 ptr=0x50201f0 -> block 303 ptr=0x5020600 -> block 316 ptr=0x5020560 -> block 314 ptr=0x503b160 -> block 374 ptr=0x501fcf0 -> block 287 ptr=0x501fd90 -> block 289 ptr=0x501fc50 -> block 285 ptr=0x503b100 -> block 373 ptr=0x5018d80 -> block 0 ptr=0x5018dd0 -> block 1 ptr=0x5018e20 -> block 2 ptr=0x5018e70 -> block 3 ptr=0x5018ed0 -> block 4 ptr=0x5018f40 -> block 5 ptr=0x5018f90 -> block 6 ptr=0x5018fe0 -> block 7 ptr=0x5019030 -> block 8 ptr=0x5019080 -> block 9 ptr=0x50190d0 -> block 10 ... ptr=0x503b3b0 -> block 376 ptr=0x501a0f3 -> block 61 scan 0x5d4000-0x5dd000 (36864) ptr=0x502ac10 -> block 368 ptr=0x5024b70 -> block 352 ptr=0x502a9d0 -> block 364 ptr=0x502aa70 -> block 365 ptr=0x502aa70 -> block 365 ptr=0x502aac0 -> block 366 ptr=0x501d850 -> block 236 ptr=0x501d8a0 -> block 237 scan 0x4036000-0x4037000 (4096) scan 0x4037000-0x4038000 (4096) scan 0x4837000-0x4839000 (8192) scan 0x483d000-0x483e000 (4096) scan 0x4858000-0x4859000 (4096) scan 0x4861000-0x4862000 (4096) scan 0x4872000-0x4873000 (4096) scan 0x4873000-0x4875000 (8192) scan 0x494c000-0x494f000 (12288) scan 0x494f000-0x4950000 (4096) scan 0x4d97000-0x4d99000 (8192) scan 0x4d99000-0x4d9b000 (8192) scan 0x4db8000-0x4db9000 (4096) scan 0x4fb2000-0x4fb3000 (4096) scan 0x4fb3000-0x4fb8000 (20480) scan 0x4fbc000-0x4fbd000 (4096) scan 0x4fc1000-0x4fc4000 (12288) scan 0x53c4000-0x14dc4000 (262144000) --00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel --00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel --00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel 3. Log file for process 3491 (142MB when valgrind killed): ==00:00:00:02.218 3491== Memcheck, a memory error detector ==00:00:00:02.218 3491== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==00:00:00:02.218 3491== Using Valgrind-3.24.0-fcdaa47426-20241101X and LibVEX; rerun with -h for copyright info ==00:00:00:02.218 3491== Command: bin/gm_server --master XXXXXXXXXXXXXXXXXXXXXXXX ==00:00:00:02.218 3491== Parent PID: 3461 ==00:00:00:02.218 3491== --00:00:00:02.218 3491-- --00:00:00:02.218 3491-- Valgrind options: --00:00:00:02.218 3491-- --log-file=/tmp/valgrind/memcheck-%p.log --00:00:00:02.218 3491-- --tool=memcheck --00:00:00:02.218 3491-- --leak-check=summary --00:00:00:02.218 3491-- --time-stamp=yes --00:00:00:02.218 3491-- --track-fds=no --00:00:00:02.218 3491-- --trace-signals=yes --00:00:00:02.218 3491-- --track-origins=no --00:00:00:02.218 3491-- --trace-children=yes --00:00:00:02.218 3491-- --trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc --00:00:00:02.218 3491-- --vgdb=no --00:00:00:02.218 3491-- --error-limit=no --00:00:00:02.218 3491-- --verbose --00:00:00:02.218 3491-- Contents of /proc/version: --00:00:00:02.218 3491-- Linux version 6.11.9-100.fc39.x86_64 (mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1 20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024 --00:00:00:02.218 3491-- --00:00:00:02.218 3491-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3-lzcnt --00:00:00:02.218 3491-- Page sizes: currently 4096, max supported 4096 --00:00:00:02.218 3491-- Valgrind library directory: /usr/local/libexec/valgrind --00:00:00:02.227 3491-- sys_sigaction: sigNo 12, new 0xfeae4d04, old 0x0, new flags 0x4000000 --00:00:00:02.228 3491-- sys_sigaction: sigNo 10, new 0xfeae4d04, old 0x0, new flags 0x4000000 --00:00:00:02.228 3491-- sys_sigaction: sigNo 15, new 0xfeae4d04, old 0x0, new flags 0x4000000 --00:00:00:02.229 3491-- sys_sigaction: sigNo 13, new 0xfeae4d04, old 0x0, new flags 0x4000000 --00:00:00:02.229 3491-- sys_sigaction: sigNo 2, new 0xfeae4d04, old 0x0, new flags 0x4000000 --00:00:00:02.229 3491-- sys_sigaction: sigNo 17, new 0xfeae4d04, old 0x0, new flags 0x4000000 --00:00:00:02.230 3491-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), newset = 0x0 (NULL) --00:00:00:02.230 3491-- oldset=0xFEAE4FBC 0000000000000000 --00:00:00:02.231 3491-- do_setmask: tid = 1 how = 2 (SIG_SETMASK), newset = 0xFEAE4E70 (fffffffe7ffee115) --00:00:02:02.494 3491-- sys_sigaction: sigNo 11, new 0x82cfdeec, old 0x0, new flags 0x0 --00:00:02:02.494 3491-- sys_sigaction: sigNo 7, new 0x82cfdeec, old 0x0, new flags 0x0 --00:00:02:02.494 3491-- sys_sigaction: sigNo 4, new 0x82cfdee4, old 0x0, new flags 0x0 --00:00:02:02.494 3491-- sys_sigaction: sigNo 8, new 0x82cfdee4, old 0x0, new flags 0x0 --00:00:02:02.494 3491-- sys_sigaction: sigNo 31, new 0x82cfdedc, old 0x0, new flags 0x0 ==00:00:02:02.525 3491== ==00:00:02:02.525 3491== HEAP SUMMARY: ==00:00:02:02.525 3491== in use at exit: 20,649 bytes in 576 blocks ==00:00:02:02.525 3491== total heap usage: 5,562 allocs, 4,986 frees, 595,523 bytes allocated ==00:00:02:02.525 3491== ==00:00:02:02.526 3491== Searching for pointers to 576 not-freed blocks scan 0x30d000-0x5d4000 (2912256) ptr=0x502ac10 -> block 377 ptr=0x503b100 -> block 382 ptr=0x50200b0 -> block 308 ptr=0x5020150 -> block 310 ptr=0x50201f0 -> block 312 ptr=0x5020600 -> block 325 ptr=0x5020560 -> block 323 ptr=0x503b160 -> block 383 ptr=0x501fcf0 -> block 296 ptr=0x501fd90 -> block 298 ptr=0x501fc50 -> block 294 ptr=0x503b100 -> block 382 ptr=0x5018d80 -> block 9 ptr=0x5018dd0 -> block 10 ... ptr=0x50b2770 -> block 558 ptr=0x50b2880 -> block 560 ptr=0x50b14d0 -> block 539 ptr=0x50b09b0 -> block 538 ptr=0x50a2f40 -> block 499 scan 0x4036000-0x4037000 (4096) scan 0x4037000-0x4038000 (4096) scan 0x4837000-0x4839000 (8192) scan 0x483d000-0x483e000 (4096) scan 0x4858000-0x4859000 (4096) scan 0x4861000-0x4862000 (4096) scan 0x4872000-0x4873000 (4096) scan 0x4873000-0x4875000 (8192) scan 0x494c000-0x494f000 (12288) scan 0x494f000-0x4950000 (4096) scan 0x4d97000-0x4d99000 (8192) scan 0x4d99000-0x4d9b000 (8192) scan 0x4db8000-0x4db9000 (4096) scan 0x4fb2000-0x4fb3000 (4096) scan 0x4fb3000-0x4fb8000 (20480) scan 0x4fbc000-0x4fbd000 (4096) scan 0x4fc1000-0x4fc4000 (12288) scan 0x53c4000-0x14dc4000 (262144000) --00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel --00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel --00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002e8d, from kernel On Mon, Dec 9, 2024 at 8:28 AM Paul Floyd via Valgrind-users <val...@li...> wrote: > > > > On 05-12-24 14:19, Wojciech Bocer wrote: > > Hello, > > > > I have a problem with Valgrind taking a lot of time trying to > > determine if there are memory leaks before it exits. > > > Roughly speaking leak detection involves scanning though all accessible > memory using pointer-size alignment to look for any pointers to unfreed > memory blocks. This code does handle segfaults. > > I don't have any real idea why the combination of x86 and Docker gives > large numbers of segfaults and a major slowdown. > > I suggest that you get the source for Valgrind and set these macros in > mc_leakcheck.c to 1 > > > // Define to debug the memory-leak-detector. > #define VG_DEBUG_FIND_CHUNK 0 > #define VG_DEBUG_LEAKCHECK 0 > #define VG_DEBUG_CLIQUE 0 > > and then build Valgrind. > > A+ > Paul > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Paul F. <pj...@wa...> - 2024-12-09 07:27:23
|
On 05-12-24 14:19, Wojciech Bocer wrote: > Hello, > > I have a problem with Valgrind taking a lot of time trying to > determine if there are memory leaks before it exits. Roughly speaking leak detection involves scanning though all accessible memory using pointer-size alignment to look for any pointers to unfreed memory blocks. This code does handle segfaults. I don't have any real idea why the combination of x86 and Docker gives large numbers of segfaults and a major slowdown. I suggest that you get the source for Valgrind and set these macros in mc_leakcheck.c to 1 // Define to debug the memory-leak-detector. #define VG_DEBUG_FIND_CHUNK 0 #define VG_DEBUG_LEAKCHECK 0 #define VG_DEBUG_CLIQUE 0 and then build Valgrind. A+ Paul |
|
From: John R. <jr...@bi...> - 2024-12-06 21:57:09
|
> Obviously "skipped 195,035,136 bytes due to read errors" does not look good. So consult the source for valgrind (memcheck) for the string "skiped.*due to read errors" or similar. Run memcheck under a debugger such as gdb, plant a breakpoint on the code that corresponds to that message, and look a the tracebacks. (Compile and build memcheck with "-g" option to give debugging info.) A search of the web for "linux performance monitoring tool" yields several lists of multiple tools. Searching for "linux kernel perf" gives pointers to the 'perf' tool itself. Of course you may have to add such tools into your VM containers. |
|
From: Wojciech B. <woj...@gm...> - 2024-12-05 13:19:42
|
Hello, I have a problem with Valgrind taking a lot of time trying to determine if there are memory leaks before it exits. I'm running Valgrind 3.24.0 with a multi-process 32-bit application in Linux on x86_64. This is how I run it: valgrind --log-file=/tmp/valgrind/memcheck-%p.log --tool=memcheck --leak-check=summary --time-stamp=yes --track-fds=no --trace-signals=no --track-origins=no --trace-children=yes --error-limit=no --verbose my_program I also use "--trace-children-skip=..." to not trace processes I'm not interested in, omitted above for readability. Host: Fedora 41. VM: Fedora 39. Valgrind has been compiled from source and installed in the VM. Docker container: Fedora 41, run with docker-compose in privileged mode. Valgrind has been compiled from source and installed in the container. Scenarios: 1. Host -> VM -> I run Valgrind with "leak-check=summary" -> OK. 2. Host -> VM -> Docker Container -> I run Valgrind with "leak-check=no" -> OK. 3. Host -> VM -> Docker Container -> I run Valgrind with "leak-check=summary" -> NOT OK. "OK" above means that it took Valgrind "a moment" to analyze the memory and produce a leak report. "NOT OK" above means that it took a lot more (10 minutes per process or so). In order to produce the report I send SIGTERM to my program. All the child processes call exit(). The main process calls waitpid() and waits for all children processes. Main process then calls exit(). Scenario 1: All is fine when I run Valgrind in the VM. ==00:00:00:38.974 223162== ==00:00:00:38.974 223162== Searching for pointers to 472 not-freed blocks ==00:00:00:40.769 223162== Checked 265,221,516 bytes ==00:00:00:40.769 223162== Scenario 2: I run Valgrind in a container in a VM. When running with "leak-check=no" Valgrind also finishes quickly. Obviously I'm missing the "LEAK SUMMARY" which I need. Scenario 3: The problem only appears here, when: If I run my program and Valgrind in a docker container. If I enable "leak-check". ==00:00:10:37.904 769== Searching for pointers to 379 not-freed blocks ==00:00:36:34.041 769== Checked 265,208,940 bytes ==00:00:36:34.041 769== Skipped 195,035,136 bytes due to read errors Notice the timestamps difference between (1) and (3). The time it takes for Valgrind to search does not seem to depend on "leak-resolution" or "leak-check-heuristics" settings. Suspicious: Obviously "skipped 195,035,136 bytes due to read errors" does not look good. If I add "--trace-signals=yes", I have to kill valgrind, as it produces enormous log files for some of the processes. These log files contain repeated lines, similar to the one below, and that's the reason for their size (megabytes of text). ==00:00:01:52.043 12423== Searching for pointers to 378 not-freed blocks --00:00:01:52.237 12423-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002d1d, from kernel --00:00:01:52.237 12423-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002d1d, from kernel --00:00:01:52.237 12423-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002d1d, from kernel ... ==00:00:01:43.214 12425== Searching for pointers to 378 not-freed blocks --00:00:01:43.379 12425-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002d1d, from kernel --00:00:01:43.379 12425-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002d1d, from kernel ... ==00:00:02:02.470 12443== Searching for pointers to 576 not-freed blocks --00:00:02:02.677 12443-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002d1d, from kernel --00:00:02:02.677 12443-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002d1d, from kernel --00:00:02:02.677 12443-- sync signal handler: signal=7, si_code=2, EIP=0x0, eip=0x58002d1d, from kernel ... I was hoping you may offer some advice on what would be the next step in trying to figure out the root cause of the problem. Kind regards, Wojciech |
|
From: Paul F. <pj...@wa...> - 2024-11-16 08:22:41
|
On 15-11-24 08:34, Mathew T wrote:
> Hello,
>
> I’m seeking assistance with a challenging issue involving an
> executable on an ARM64 Ubuntu system. Here’s the problem and what I’ve
> done to investigate it so far:
>
> Problem Summary: I have an ARM64 executable that crashes with a
> segmentation fault(early to main function, looks like when loading .so
> libraries) when run independently. However, when running it with
> Valgrind, the program completes its execution, although Valgrind does
> report an Invalid free error.
Can you share the source? Even a cut down reproducer?
I've had a quick look at the openssl code. Maybe not the same as your
version.
void BN_clear_free(BIGNUM *a)
{
if (a == NULL)
return;
if (a->d != NULL && !BN_get_flags(a, BN_FLG_STATIC_DATA))
bn_free_d(a, 1);
if (BN_get_flags(a, BN_FLG_MALLOCED)) {
OPENSSL_cleanse(a, sizeof(*a));
OPENSSL_free(a);
}
}
It looks BIGNUM has a member 'd' that actually points to the allocated
block. I also presume that at the point of failure 'a' is valid and that
its flags field is also OK.
bn_free_d is probably inlined. I don't see why we don't see the CRYPTO
function in the callstack. Maybe that's not always used?
>
> Valgrind Output (partial):
> ===================
> plaintext
> Copy code
> ==2644== Invalid free() / delete / delete[] / realloc()
> ==2644== at 0x7127AD0: free (in
> /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
> ==2644== by 0x838C0CB: BN_clear_free (in
> /usr/lib/aarch64-linux-gnu/libcrypto.so.3)
> ==2644== by 0x7B8CEAB: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644== by 0x7B9121F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644== by 0x7B7DF3F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644== by 0x68C5623: call_init (dl-init.c:70)
> ==2644== by 0x68C5623: call_init (dl-init.c:26)
> ==2644== by 0x68C572B: _dl_init (dl-init.c:117)
> ==2644== by 0x68D7CC7: ??? (in
> /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1)
> ==2644== Address 0x1 is not stack'd, malloc'd or (recently) free'd
This looks like it's happening before main _dl_init. ld.so loads shared
libraries and runs any global init code (like C++ constructors).
> Additional Information:
> ====================
> The crash appears to be related to libcrypto and libssh libraries.
> libssh.so.4 and libcrypto.so.3 versions on the system match the
> versions the executable was compiled against.
> I have attempted to gather debug symbols for these libraries to
> analyze further, but only limited information is available from the
> system-provided packages.
Getting debuginfo would help.
> Questions:
> =========
> 1. Could the difference in behavior (running under Valgrind vs.
> standalone) indicate a specific type of issue, such as a memory
> alignment problem?
The memory layout is different when running under valgrind. Mainly the
stack is in a different place. Allocation alignment is probably the same.
> 2. Are there recommended methods or tools, other than Valgrind and
> GDB, that might help debug memory management issues specifically on
> ARM64?
Sanitizers?
> 3. Has anyone encountered similar issues when libcrypto or libssh
> functions are involved?
No, I don't use Linux arm64 much.
A+
Paul
|
|
From: Mathew T <mat...@gm...> - 2024-11-15 07:34:19
|
Hello, I’m seeking assistance with a challenging issue involving an executable on an ARM64 Ubuntu system. Here’s the problem and what I’ve done to investigate it so far: Problem Summary: I have an ARM64 executable that crashes with a segmentation fault(early to main function, looks like when loading .so libraries) when run independently. However, when running it with Valgrind, the program completes its execution, although Valgrind does report an Invalid free error. Technical Details: ================ System: Ubuntu ARM64( Jammy) Executable behavior: Runs with Valgrind but reports an Invalid free error. Segmentation fault when running directly, before the main function starts executing. Valgrind Output (partial): =================== plaintext Copy code ==2644== Invalid free() / delete / delete[] / realloc() ==2644== at 0x7127AD0: free (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so) ==2644== by 0x838C0CB: BN_clear_free (in /usr/lib/aarch64-linux-gnu/libcrypto.so.3) ==2644== by 0x7B8CEAB: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7) ==2644== by 0x7B9121F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7) ==2644== by 0x7B7DF3F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7) ==2644== by 0x68C5623: call_init (dl-init.c:70) ==2644== by 0x68C5623: call_init (dl-init.c:26) ==2644== by 0x68C572B: _dl_init (dl-init.c:117) ==2644== by 0x68D7CC7: ??? (in /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1) ==2644== Address 0x1 is not stack'd, malloc'd or (recently) free'd GDB Investigation: ============== Using gdb on the executable confirms that the crash happens before reaching main(). Here’s a backtrace from GDB: (gdb) bt #0 0x0000000007127ad0 in _vgr10050ZU_VgSoSynsomalloc_free () from /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so #1 0x000000000838c0cc in BN_clear_free () from /lib/aarch64-linux-gnu/libcrypto.so.3 #2 0x0000000007b8ceac in ?? () from /lib/aarch64-linux-gnu/libssh.so.4 #3 0x0000000007b91220 in ?? () from /lib/aarch64-linux-gnu/libssh.so.4 Additional Information: ==================== The crash appears to be related to libcrypto and libssh libraries. libssh.so.4 and libcrypto.so.3 versions on the system match the versions the executable was compiled against. I have attempted to gather debug symbols for these libraries to analyze further, but only limited information is available from the system-provided packages. Questions: ========= 1. Could the difference in behavior (running under Valgrind vs. standalone) indicate a specific type of issue, such as a memory alignment problem? 2. Are there recommended methods or tools, other than Valgrind and GDB, that might help debug memory management issues specifically on ARM64? 3. Has anyone encountered similar issues when libcrypto or libssh functions are involved? Thank you for any guidance or suggestions you can offer. Regards, Matthew |
|
From: Paul F. <pj...@wa...> - 2024-11-13 07:10:46
|
On 12-11-24 22:22, William Chan (BLOOMBERG/ 919 3RD A) wrote: > Hi, > > I have a program that induces a possibly lost warning via an interior > pointer but I deallocate the pointer properly. Is Valgrind supposed to > be able to know that an interior pointer is freed? I'm trying to > determine whether or not my possibly lost warning is safe to ignore. Unless something has gone wrong Memcheck redirects and records all calls to allocation and deallocation functions. "Interior pointers" are never freed, only the original pointers. Passing an interior pointer to operator delete or free would result in an "Invalid free() / delete / delete[] / realloc()" error. I think that "possibly lost" is a rather misleading name. There's no doubt that the memory is lost. The only doubt is to whether it is really a "definite" leak or a "still reachable" (via the interior pointer) one. See this item on SO for a C++ example. https://stackoverflow.com/questions/17630892/is-there-a-simple-example-of-false-positive-valgrind-possibly-lost-report We need more details in order to be sure. Can you share a small example? A+ Paul |
|
From: David A. <da...@li...> - 2024-11-12 23:55:44
|
On 11/12/24 13:22, William Chan (BLOOMBERG/ 919 3RD A) wrote: > Hi, > > I have a program that induces a possibly lost warning via an interior > pointer but I deallocate the pointer properly. Is Valgrind supposed to > be able to know that an interior pointer is freed? I'm trying to > determine whether or not my possibly lost warning is safe to ignore. I suggest that a principle of defensive programming is free(x); x = 0; /* or x = NULL if you prefer */ Whether this make a difference here ... no idea, sorry. David Anderson |
|
From: William C. (B. 9. 3. A) <wch...@bl...> - 2024-11-12 21:35:39
|
Hi, I have a program that induces a possibly lost warning via an interior pointer but I deallocate the pointer properly. Is Valgrind supposed to be able to know that an interior pointer is freed? I'm trying to determine whether or not my possibly lost warning is safe to ignore. Thanks, William |
|
From: Mark W. <ma...@kl...> - 2024-11-01 05:30:00
|
We are pleased to announce a new release of Valgrind, version 3.24.0, available from https://valgrind.org/downloads/current.html. See the release notes below for details of changes. Our thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy and productive debugging and profiling, -- The Valgrind Developers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Release 3.24.0 (31 Oct 2024) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD, AMD64/FreeBSD and ARM64/FreeBSD There is also preliminary support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. * ==================== CORE CHANGES =================== * Bad file descriptor usage now generates a real error with --track-fds=yes that is suppressible and shows up in the xml output with full execution backtrace. The warnings shown without using the option are deprecated and will be removed in a future valgrind version. * Ada name demangling is now supported in error messages. * ================== PLATFORM CHANGES ================= * S390X added support for the DFLTCC instruction provided by the deflate-conversion facility (z15/arch13). * S390X added support for the instructions provided by the MSA facility and MSA extensions 1-9. * ==================== TOOL CHANGES =================== * ==================== FIXED BUGS ==================== The following bugs have been fixed or resolved. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. 202770 open fd at exit --log-socket=127.0.0.1:1500 with --track-fds=yes 276780 An instruction in fftw (Fast Fourier Transform) is unhandled by valgrind: vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x2 311655 --log-file=FILE leads to apparent fd leak 317127 Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch 337388 fcntl works on Valgrind's own file descriptors 377966 arm64 unhandled instruction dc zva392146 aarch64: unhandled instruction 0xD5380001 (MRS rT, midr_el1) 391148 Unhandled AVX instruction vmovq %xmm9,%xmm1 392146 aarch64: unhandled instruction 0xD5380001 (MRS rT, midr_el1) 412377 SIGILL on cache flushes on arm64 417572 vex amd64->IR: unhandled instruction bytes: 0xC5 0x79 0xD6 0xED 0xC5 440180 s390x: Failed assertion in disassembler 444781 MIPS: wrong syscall numbers used 447989 Support Armv8.2 SHA-512 instructions 445235 Java/Ada/D demangling is probably broken 453044 gbserver_tests failures in aarch64 479661 Valgrind leaks file descriptors 486180 [Valgrind][MIPS] 'VexGuestArchState' has no member named 'guest_IP_AT_SYSCALL' 486293 memccpy false positives 486569 linux inotify_init syscall wrapper missing POST entry in syscall_table 487439 SIGILL in JDK11, JDK17 487993 Alignment error when using Eigen with Valgrind and -m32 488026 Use of `sizeof` instead of `strlen 488379 --track-fds=yes errors that cannot be suppressed with --xml-file= 488441 Add tests for --track-fds=yes --xml=yes and fd suppression tests 489040 massif trace change to show the location increasing the stack 489088 Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5 489338 arm64: Instruction fcvtas should round 322.5 to 323, but result is 322. 489676 vgdb handle EINTR and EAGAIN more consistently 490651 Stop using -flto-partition=one 491394 (vgModuleLocal_addDiCfSI): Assertion 'di->fsm.have_rx_map && di->fsm.rw_map_count' failed 492210 False positive on x86/amd64 with ZF taken directly from addition 492214 statx(fd, NULL, AT_EMPTY_PATH) is supported since Linux 6.11 but not supported in valgrind 492422 Please support DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD 492663 Valgrind ignores debug info for some binaries 493418 Add bad fd usage errors for --track-fds in ML_(fd_allowed) 493454 Missing FUSE_COMPATIBLE_MAY_BLOCK markers 493507 direct readlink syscall from PRE handler is incompatible with FUSE_COMPATIBLE_MAY_BLOCK 493959 s390x: Fix regtest failure for none/tests/s390x/op00 493970 s390x: Store/restore FPC upon helper call causes slowdown 494252 s390x: incorrect disassembly for LOCHI and friends 494960 Fixes and tweaks for gsl19test 495278 PowerPC instruction dcbf should allow the L field values of 4, 6 on ISA 3.0 and earlier, just ignore the value 495469 aligned_alloc and posix_memalign missing MALLOC_TRACE with returned pointer 495470 s390x: 3.24.0.RC1 missing file and regtest failure n-i-bz Improve messages for sigaltstack errors, use specific stack_t member names To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX where XXXXXX is the bug number as listed above. (3.24.0.RC1: 27 Oct 2024) |
|
From: Carl L. <ce...@li...> - 2024-10-28 19:59:47
|
Mark: PowerPC testing on Power 8, I am seeing 4 additional stderr failures versus Valgrind 3.23.0.RC2 == 749 tests, 7 stderr failures, 0 stdout failures, 13 stderrB failures, 0 stdoutB failures, 0 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat (stderr) none/tests/fdleak_cmsg_supp (stderr) New for Valgrind-3.24.0.RC1 none/tests/fdleak_cmsg_xml (stderr) New for Valgrind-3.24.0.RC1 none/tests/fdleak_ipv4_xml (stderr) New for Valgrind-3.24.0.RC1 none/tests/socket_close_xml (stderr) New for Valgrind-3.24.0.RC1 PowerPC testing on Power 9, I am seeing 4 additional stderr failures versus Valgrind 3.23.0.RC2 == 767 tests, 7 stderr failures, 0 stdout failures, 13 stderrB failures, 0 stdoutB failures, 0 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderr) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) memcheck/tests/leak-delta (stderr) memcheck/tests/linux/rfcomm (stderr) none/tests/fdleak_cmsg_supp (stderr) New for Valgrind-3.24.0.RC1 none/tests/fdleak_cmsg_xml (stderr) New for Valgrind-3.24.0.RC1 none/tests/fdleak_ipv4_xml (stderr) New for Valgrind-3.24.0.RC1 none/tests/socket_close_xml (stderr) New for Valgrind-3.24.0.RC1 PowerPC testing on Power 10, I am seeing 4 additional stderr failures versus Valgrind 3.23.0.RC2 == 753 tests, 5 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/linux/rfcomm (stderr) none/tests/fdleak_cmsg_supp (stderr) New for Valgrind-3.24.0.RC1 none/tests/fdleak_cmsg_xml (stderr) New for Valgrind-3.24.0.RC1 none/tests/fdleak_ipv4_xml (stderr) New for Valgrind-3.24.0.RC1 none/tests/socket_close_xml (stderr) New for Valgrind-3.24.0.RC1 I am not sure what is going on with these tests. I have not yet been able to dig into them. Carl On 10/27/24 4:58 PM, Mark Wielaard wrote: > There are still some pending patches, but lets do an RC1 for some > wider testing. > > An RC1 tarball for 3.24.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.24.0.RC1.tar.bz2 > (md5sum = a11f33c94dcb0f545a27464934b6fef8) > (sha1sum = b87105b23d3b6d0e212d5729235d0d8225ff8851) > https://sourceware.org/pub/valgrind/valgrind-3.24.0.RC1.tar.bz2.asc > > Please give it a try in configurations that are important for you and > report any problems you have, either on this mailing list, or > (preferably) via our bug tracker at > https://bugs.kde.org/enter_bug.cgi?product=valgrind > > If nothing critical emerges a final release will happen on Thursday 31 > October. > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Mark W. <ma...@kl...> - 2024-10-27 23:59:07
|
There are still some pending patches, but lets do an RC1 for some wider testing. An RC1 tarball for 3.24.0 is now available at https://sourceware.org/pub/valgrind/valgrind-3.24.0.RC1.tar.bz2 (md5sum = a11f33c94dcb0f545a27464934b6fef8) (sha1sum = b87105b23d3b6d0e212d5729235d0d8225ff8851) https://sourceware.org/pub/valgrind/valgrind-3.24.0.RC1.tar.bz2.asc Please give it a try in configurations that are important for you and report any problems you have, either on this mailing list, or (preferably) via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind If nothing critical emerges a final release will happen on Thursday 31 October. |
|
From: Paul F. <pj...@wa...> - 2024-10-27 15:34:45
|
On 26-10-24 13:36, Daniel Feenberg wrote: > > > This is very disappointing. Such moves may be frequent in other > languages, but I don't see it happening to much in my Fortran 95 code. I > suppose if subroutine arguments are copy-in/copy-out, that would be a > source of spurious messages, as could code in libgfortran,but Valgrind > typically has the source and could drop those messages. > > I did eventually locate the problem in my code, by adding a large number > of write statements scattered thoughout the code, and noting the > earliest one to trigger Valgrind. I think that you grossly underestimate how much copying of uninitialized memory goes on. Any data structure that has a hole or padding thjat gets copied means there is an uninitialized read. Also fields that are intentionally unused, which is quite common with large union based data structures. This might be viable with a client request that only turns on the instrumentation for a limited part of the code. Also note that memory sanitizer also does the same thing as memcheck. A+ Paul |
|
From: Daniel F. <fee...@nb...> - 2024-10-26 11:36:18
|
On Fri, 25 Oct 2024, Paul Floyd via Valgrind-users wrote: > > > On 24-10-24 14:33, Daniel Feenberg via Valgrind-users wrote: ... >> origins" would do that. Is there an option or other way to ask Valgrind to >> be a little stricter, and flag the use of an unidentified variable in an >> assignment, not just in a condition? > > Uninitialized read errors are not triggered simply by reading uninitialized > memory. There are many cases where uninitialized memory gets copied in a > harmless manner. That would be overwhelming. Instead we only trigger errors This is very disappointing. Such moves may be frequent in other languages, but I don't see it happening to much in my Fortran 95 code. I suppose if subroutine arguments are copy-in/copy-out, that would be a source of spurious messages, as could code in libgfortran,but Valgrind typically has the source and could drop those messages. I did eventually locate the problem in my code, by adding a large number of write statements scattered thoughout the code, and noting the earliest one to trigger Valgrind. Daniel Feenberg |
|
From: John R. <jr...@bi...> - 2024-10-25 15:29:00
|
On 10/24/24, Daniel Feenberg via Valgrind-users wrote:
> Is there an option or other way to ask
> Valgrind to be a little stricter, and flag the use of an unidentified
> variable in an assignment, not just in a condition?
No. You (and many other new users) have stumbled onto *the* colossal
deficiency of valgrind. Namely: despite the supreme importance of
the *OPTION* to request that valgrind behave this way, valgrind cannot.
"If a tree falls in the forest but there is no one to hear it fall,
then does it make a sound?" Memcheck says, "No, there is no sound."
Or perhaps Memcheck would say, "There are so many trees which fall
that very probably you will give up trying to identify the one that
matters to you."
Your best bet is to find a compiler option which generates code
to check for any use of an uninit variable, and a runtime support
library that is compiled with such checking. For the sake of
efficiency, then such a check must be heuristic, but in practice
it can be very good. In gcc or clang for C or C++, then the
compiler option -fsanitize=undefined (or related) can be
effective in many cases.
Because you are working in Fortran, then having the compiler and
runtime system initialize everything to the bit pattern for some
flavor of denorm or NaN (and check for it!) might work, even
for integer variables. A 32-bit pattern flavored like
(0xFFF8 << 16) | (0xFFFF & (address >> 3)) ,
repeated to fill all otherwise-uninit space, comes to mind.
[Some 50+ years ago the Michigan Terminal System for IBM
System 360 model 67 initialized all bytes to 0x80 (or 0x81),
and this was quite helpful in identifying uninits.]
Then there is the problem of uninit local (on-stack) variables.
The gcc option -mfentry generates extra code to call a subroutine
immediately upon entry to every function, and with a little hacking
it is possible to identify the sizeof the local frame, then act.
Unfortunately, zeroing the entire local stack frame (or setting
the bytes to another known value) immediately upon allocation
tends to be very expensive: a factor of 2X, 3X, or more
in total run time.
--
|
|
From: Paul F. <pj...@wa...> - 2024-10-25 06:56:25
|
On 24-10-24 14:33, Daniel Feenberg via Valgrind-users wrote: > > I am a bit inexperienced with Valgrind which reports an uninitialized > variable in my 34,000 line program. But the message comes from a branch > deep in libgfortran. After some experimentation, I created the following > example program which demonstrates my difficulty: > > cat -n test.for > 1 program test > 2 integer i,j > 3 j=i+1 > 4 write(*,*) j > 5 stop > 6 end > > I compile and run with: > > gfortran -g stuff.for > valgrind --track-origins=yes ./a.out > > and get a great deal of output pointing to line 4. But the first use of > the uninitialized value is in line 3. In this case the error is obvious, > but IRL I haven't been able to identify the source. I thought "track- > origins" would do that. Is there an option or other way to ask Valgrind > to be a little stricter, and flag the use of an unidentified variable in > an assignment, not just in a condition? --track-origins=yes tells memcheck to record the origins of uninitilalized memory. It has done that and added ==4095841== Uninitialised value was created by a stack allocation ==4095841== at 0x401176: MAIN__ (test.for:1) With all errors Valgrind will also read debuginfo if available to give you the source and line and when possible the name of the variable. In this case it hasn't determined the name of the variable - I don't know why. Uninitialized read errors are not triggered simply by reading uninitialized memory. There are many cases where uninitialized memory gets copied in a harmless manner. That would be overwhelming. Instead we only trigger errors when the uninitialized memory affects the observable behaviour of the test exe. Hence "Conditional jump or move depends on uninitialised value(s)". So you have to do some digging to search for the place in the code where the variable should have been initialized. A+ Paul |
|
From: Daniel F. <fee...@nb...> - 2024-10-24 15:10:07
|
I am a bit inexperienced with Valgrind which reports an uninitialized
variable in my 34,000 line program. But the message comes from a branch
deep in libgfortran. After some experimentation, I created the following
example program which demonstrates my difficulty:
cat -n test.for
1 program test
2 integer i,j
3 j=i+1
4 write(*,*) j
5 stop
6 end
I compile and run with:
gfortran -g stuff.for
valgrind --track-origins=yes ./a.out
and get a great deal of output pointing to line 4. But the first use of
the uninitialized value is in line 3. In this case the error is obvious,
but IRL I haven't been able to identify the source. I thought
"track-origins" would do that. Is there an option or other way to ask
Valgrind to be a little stricter, and flag the use of an unidentified
variable in an assignment, not just in a condition?
Here is the output with --exit-on-first-error=yes, otherwise there is an
avalanch of text:
==4095841== Memcheck, a memory error detector
==4095841== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==4095841== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==4095841== Command: ./a.out
==4095841==
==4095841== Conditional jump or move depends on uninitialised value(s)
==4095841== at 0x4AD2B8E: ??? (in /usr/lib64/libgfortran.so.5.0.0)
==4095841== by 0x4AD6C6B: ??? (in /usr/lib64/libgfortran.so.5.0.0)
==4095841== by 0x4AD7C66: ??? (in /usr/lib64/libgfortran.so.5.0.0)
==4095841== by 0x4011DC: MAIN__ (test.for:4)
==4095841== by 0x401233: main (test.for:6)
==4095841== Uninitialised value was created by a stack allocation
==4095841== at 0x401176: MAIN__ (test.for:1)
==4095841==
==4095841==
==4095841== Exit program on first error (--exit-on-first-error=yes)
Thank you and any help much appreciated.
Daniel Feenberg
|
|
From: Pepper G. <he...@pe...> - 2024-10-24 11:54:55
|
Hi,
I'm having an issue with callgrind, and unfortunately I didn't find any
further information in the docs:
The instruction count is not what I expect and differs from single stepping
the binary.
I'm on x86_64-linux-gnu
I created a simple hello world example:
global _start
section .text
_start:
mov rax, 1 ; write(
mov rdi, 1 ; STDOUT_FILENO,
mov rsi, msg ; "Hello, world!\n",
mov rdx, msglen ; sizeof("Hello, world!\n")
syscall ; );
mov rax, 60 ; exit(
mov rdi, 0 ; EXIT_SUCCESS
syscall ; );
section .rodata
msg: db "Hello, world!", 10
msglen: equ $ - msg
Which has 8 instructions:
$ objdump -d hello
hello: file format elf64-x86-64
Disassembly of section .text:
0000000000401000 <_start>:
401000: b8 01 00 00 00 mov $0x1,%eax
401005: bf 01 00 00 00 mov $0x1,%edi
40100a: 48 be 00 20 40 00 00 movabs $0x402000,%rsi
401011: 00 00 00
401014: ba 0e 00 00 00 mov $0xe,%edx
401019: 0f 05 syscall
40101b: b8 3c 00 00 00 mov $0x3c,%eax
401020: bf 00 00 00 00 mov $0x0,%edi
401025: 0f 05 syscall
Running "valgrind --tool=callgrind ./hello" gives me only 5 instructions:
Hello, world!
==443229==
==443229== Events : Ir
==443229== Collected : 5
==443229==
==443229== I refs: 5
When I create a dump "valgrind --tool=callgrind --dump-instr=yes
--simulate-cache=yes --collect-jumps=yes ./hello"
and check the machie code out using KCachegrind:
# Ir Hex Assembly Instructions Source Position
40 1000 █ 20.00 b8 01 00 00 00 mov $0x1, %eax (unknown)
40 1005 █ 20.00 bf 01 00 00 00 mov $0x1, %edi (unknown)
40 100A █ 20.00 48 be 00 20 40 00 00 movabs $0x402000, %rsi
(unknown)
40 1011 20.00 00 00 00
40 1014 █ 20.00 ba 0e 00 00 00 mov $0xe, %edx (unknown)
40 1019 █ 20.00 0f 05 syscall (unknown)
40 101B b8 3c 00 00 00 mov $0x3c, %eax
40 1020 bf 00 00 00 00 mov $0x0, %edi
So it seems it doesn't capture the last syscall and doesn't count the last
two mov instructions.
I also checked with c files:
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
return 0;
}
where valgrind gives me 139,482:
Hello, world!
==444986==
==444986== Events : Ir
==444986== Collected : 139482
==444986==
==444986== I refs: 139,482
whilst when I use fork, execv,
ptrace(PTRACE_TRACEME, 0, 0, 0)
ptrace(PTRACE_SINGLESTEP, pid, 0, 0)
to single step the binary, and count the steps, I get 126,042.
Am I missing something, or is callgrind counting something else than steps?
How can I make these numbers line up?
KR
Pepper
|
|
From: Georgi K. <Ge...@ko...> - 2024-09-11 12:54:56
|
Hi, Any plans to support that OS version? I've tried and I couldn't compile it: I get an error it's not supported. Both the releases and the git trunk. Best Regards, Georgi K |
188 messages has been excluded from this view by a project administrator.
