Raspbian

  1. Bug #2051392
  2. Activity log

Activity log for bug #2051392

Date Who What changed Old value New value Message
2024-01-26 19:31:33 Pjfloyd bug added bug
2024-01-26 19:32:03 Pjfloyd description Valgrind should redirect functions the functions in libarmmem, mainly to check for overlaps but also partly to avoid false positives due to SIMD optimizations reading beyond the terminating nul (Valgrind has a second mechanism to avoid such false positives, but that doesn't work in this case). It would also help if the shared library contained its soname. See https://bugs.kde.org/show_bug.cgi?id=398569 for more details. To check, run ./vg-in-place --trace-symtab=yes --log-file=sym.log memcheck/tests/memccpy2 (vg-in-place is for running Valgrind in its own source directory, any executable should do for the test). Look for the libarmmem The key part is this table --- Reading (ELF, standard) dynamic symbol table (14 entries) --- raw symbol [ 1]: LOC SEC : svma 0x0000000374, sz 0 NONAME raw symbol [ 2]: LOC SEC : svma 0x0000014024, sz 0 NONAME raw symbol [ 3]: WEA FUN : svma 0x0000000000, sz 0 __cxa_finalize ignore -- size=0: __cxa_finalize raw symbol [ 4]: WEA NOT : svma 0x0000000000, sz 0 _ITM_deregisterTMCloneTable raw symbol [ 5]: WEA NOT : svma 0x0000000000, sz 0 __gmon_start__ raw symbol [ 6]: WEA NOT : svma 0x0000000000, sz 0 _ITM_registerTMCloneTable raw symbol [ 7]: GLO NOT : svma 0x00000030f8, sz 0 memset raw symbol [ 8]: GLO NOT : svma 0x00000030e4, sz 0 mempcpy raw symbol [ 9]: GLO NOT : svma 0x00000031c0, sz 0 strlen raw symbol [ 10]: GLO NOT : svma 0x000000216c, sz 0 memmove raw symbol [ 11]: GLO NOT : svma 0x00000030e4, sz 0 __mempcpy "GLO NOT" means "global notype". Valgrind will ignore notype objects. "sz 0" is also a problem as Valgrind will ignore objects with a size of 0. raw symbol [ 12]: GLO NOT : svma 0x0000000b58, sz 0 memcpy raw symbol [ 13]: GLO NOT : svma 0x00000004d0, sz 0 memcmp Valgrind also needs some modifications, but that requires libarmmem to be fixed first. Valgrind should redirect the functions in libarmmem, mainly to check for overlaps but also partly to avoid false positives due to SIMD optimizations reading beyond the terminating nul (Valgrind has a second mechanism to avoid such false positives, but that doesn't work in this case). It would also help if the shared library contained its soname. See https://bugs.kde.org/show_bug.cgi?id=398569 for more details. To check, run ./vg-in-place --trace-symtab=yes --log-file=sym.log memcheck/tests/memccpy2 (vg-in-place is for running Valgrind in its own source directory, any executable should do for the test). Look for the libarmmem The key part is this table --- Reading (ELF, standard) dynamic symbol table (14 entries) --- raw symbol [ 1]: LOC SEC : svma 0x0000000374, sz 0 NONAME raw symbol [ 2]: LOC SEC : svma 0x0000014024, sz 0 NONAME raw symbol [ 3]: WEA FUN : svma 0x0000000000, sz 0 __cxa_finalize     ignore -- size=0: __cxa_finalize raw symbol [ 4]: WEA NOT : svma 0x0000000000, sz 0 _ITM_deregisterTMCloneTable raw symbol [ 5]: WEA NOT : svma 0x0000000000, sz 0 __gmon_start__ raw symbol [ 6]: WEA NOT : svma 0x0000000000, sz 0 _ITM_registerTMCloneTable raw symbol [ 7]: GLO NOT : svma 0x00000030f8, sz 0 memset raw symbol [ 8]: GLO NOT : svma 0x00000030e4, sz 0 mempcpy raw symbol [ 9]: GLO NOT : svma 0x00000031c0, sz 0 strlen raw symbol [ 10]: GLO NOT : svma 0x000000216c, sz 0 memmove raw symbol [ 11]: GLO NOT : svma 0x00000030e4, sz 0 __mempcpy "GLO NOT" means "global notype". Valgrind will ignore notype objects. "sz 0" is also a problem as Valgrind will ignore objects with a size of 0. raw symbol [ 12]: GLO NOT : svma 0x0000000b58, sz 0 memcpy raw symbol [ 13]: GLO NOT : svma 0x00000004d0, sz 0 memcmp Valgrind also needs some modifications, but that requires libarmmem to be fixed first.
2024-01-26 19:33:05 Pjfloyd description Valgrind should redirect the functions in libarmmem, mainly to check for overlaps but also partly to avoid false positives due to SIMD optimizations reading beyond the terminating nul (Valgrind has a second mechanism to avoid such false positives, but that doesn't work in this case). It would also help if the shared library contained its soname. See https://bugs.kde.org/show_bug.cgi?id=398569 for more details. To check, run ./vg-in-place --trace-symtab=yes --log-file=sym.log memcheck/tests/memccpy2 (vg-in-place is for running Valgrind in its own source directory, any executable should do for the test). Look for the libarmmem The key part is this table --- Reading (ELF, standard) dynamic symbol table (14 entries) --- raw symbol [ 1]: LOC SEC : svma 0x0000000374, sz 0 NONAME raw symbol [ 2]: LOC SEC : svma 0x0000014024, sz 0 NONAME raw symbol [ 3]: WEA FUN : svma 0x0000000000, sz 0 __cxa_finalize     ignore -- size=0: __cxa_finalize raw symbol [ 4]: WEA NOT : svma 0x0000000000, sz 0 _ITM_deregisterTMCloneTable raw symbol [ 5]: WEA NOT : svma 0x0000000000, sz 0 __gmon_start__ raw symbol [ 6]: WEA NOT : svma 0x0000000000, sz 0 _ITM_registerTMCloneTable raw symbol [ 7]: GLO NOT : svma 0x00000030f8, sz 0 memset raw symbol [ 8]: GLO NOT : svma 0x00000030e4, sz 0 mempcpy raw symbol [ 9]: GLO NOT : svma 0x00000031c0, sz 0 strlen raw symbol [ 10]: GLO NOT : svma 0x000000216c, sz 0 memmove raw symbol [ 11]: GLO NOT : svma 0x00000030e4, sz 0 __mempcpy "GLO NOT" means "global notype". Valgrind will ignore notype objects. "sz 0" is also a problem as Valgrind will ignore objects with a size of 0. raw symbol [ 12]: GLO NOT : svma 0x0000000b58, sz 0 memcpy raw symbol [ 13]: GLO NOT : svma 0x00000004d0, sz 0 memcmp Valgrind also needs some modifications, but that requires libarmmem to be fixed first. Valgrind should redirect the functions in libarmmem, mainly to check for overlaps but also partly to avoid false positives due to SIMD optimizations reading beyond the terminating nul (Valgrind has a second mechanism to avoid such false positives, but that doesn't work in this case). It would also help if the shared library contained its soname. See https://bugs.kde.org/show_bug.cgi?id=398569 for more details. To check, run ./vg-in-place --trace-symtab=yes --log-file=sym.log memcheck/tests/memccpy2 (vg-in-place is for running Valgrind in its own source directory, any executable should do for the test). Look for the libarmmem section starting with ------ start ELF OBJECT ------------------------------------------------------- ------ name = /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so The key part is this table --- Reading (ELF, standard) dynamic symbol table (14 entries) --- raw symbol [ 1]: LOC SEC : svma 0x0000000374, sz 0 NONAME raw symbol [ 2]: LOC SEC : svma 0x0000014024, sz 0 NONAME raw symbol [ 3]: WEA FUN : svma 0x0000000000, sz 0 __cxa_finalize     ignore -- size=0: __cxa_finalize raw symbol [ 4]: WEA NOT : svma 0x0000000000, sz 0 _ITM_deregisterTMCloneTable raw symbol [ 5]: WEA NOT : svma 0x0000000000, sz 0 __gmon_start__ raw symbol [ 6]: WEA NOT : svma 0x0000000000, sz 0 _ITM_registerTMCloneTable raw symbol [ 7]: GLO NOT : svma 0x00000030f8, sz 0 memset raw symbol [ 8]: GLO NOT : svma 0x00000030e4, sz 0 mempcpy raw symbol [ 9]: GLO NOT : svma 0x00000031c0, sz 0 strlen raw symbol [ 10]: GLO NOT : svma 0x000000216c, sz 0 memmove raw symbol [ 11]: GLO NOT : svma 0x00000030e4, sz 0 __mempcpy "GLO NOT" means "global notype". Valgrind will ignore notype objects. "sz 0" is also a problem as Valgrind will ignore objects with a size of 0. raw symbol [ 12]: GLO NOT : svma 0x0000000b58, sz 0 memcpy raw symbol [ 13]: GLO NOT : svma 0x00000004d0, sz 0 memcmp Valgrind also needs some modifications, but that requires libarmmem to be fixed first.
2024-01-27 08:44:27 Pjfloyd summary libarmmem symbol issues prevent Valgrid redirs libarmmem symbol issues prevent Valgrind redirs
2024-01-27 08:52:52 Pjfloyd attachment added Initial patch https://bugs.launchpad.net/raspbian/+bug/2051392/+attachment/5742754/+files/patch
2024-01-27 09:25:12 Pjfloyd bug watch added https://bugs.kde.org/show_bug.cgi?id=398569
2024-01-27 12:09:41 Pjfloyd attachment added Improved patch https://bugs.launchpad.net/raspbian/+bug/2051392/+attachment/5742765/+files/patch2
2024-02-06 16:50:24 Pjfloyd description Valgrind should redirect the functions in libarmmem, mainly to check for overlaps but also partly to avoid false positives due to SIMD optimizations reading beyond the terminating nul (Valgrind has a second mechanism to avoid such false positives, but that doesn't work in this case). It would also help if the shared library contained its soname. See https://bugs.kde.org/show_bug.cgi?id=398569 for more details. To check, run ./vg-in-place --trace-symtab=yes --log-file=sym.log memcheck/tests/memccpy2 (vg-in-place is for running Valgrind in its own source directory, any executable should do for the test). Look for the libarmmem section starting with ------ start ELF OBJECT ------------------------------------------------------- ------ name = /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so The key part is this table --- Reading (ELF, standard) dynamic symbol table (14 entries) --- raw symbol [ 1]: LOC SEC : svma 0x0000000374, sz 0 NONAME raw symbol [ 2]: LOC SEC : svma 0x0000014024, sz 0 NONAME raw symbol [ 3]: WEA FUN : svma 0x0000000000, sz 0 __cxa_finalize     ignore -- size=0: __cxa_finalize raw symbol [ 4]: WEA NOT : svma 0x0000000000, sz 0 _ITM_deregisterTMCloneTable raw symbol [ 5]: WEA NOT : svma 0x0000000000, sz 0 __gmon_start__ raw symbol [ 6]: WEA NOT : svma 0x0000000000, sz 0 _ITM_registerTMCloneTable raw symbol [ 7]: GLO NOT : svma 0x00000030f8, sz 0 memset raw symbol [ 8]: GLO NOT : svma 0x00000030e4, sz 0 mempcpy raw symbol [ 9]: GLO NOT : svma 0x00000031c0, sz 0 strlen raw symbol [ 10]: GLO NOT : svma 0x000000216c, sz 0 memmove raw symbol [ 11]: GLO NOT : svma 0x00000030e4, sz 0 __mempcpy "GLO NOT" means "global notype". Valgrind will ignore notype objects. "sz 0" is also a problem as Valgrind will ignore objects with a size of 0. raw symbol [ 12]: GLO NOT : svma 0x0000000b58, sz 0 memcpy raw symbol [ 13]: GLO NOT : svma 0x00000004d0, sz 0 memcmp Valgrind also needs some modifications, but that requires libarmmem to be fixed first. Valgrind should redirect the functions in libarmmem, mainly to check for overlaps but also partly to avoid false positives due to SIMD optimizations reading beyond the terminating nul (Valgrind has a second mechanism to avoid such false positives, but that doesn't work in this case). It would also help if the shared library contained its soname. See https://bugs.kde.org/show_bug.cgi?id=398569 for more details. To check, run ./vg-in-place --trace-symtab=yes --log-file=sym.log memcheck/tests/memccpy2 (vg-in-place is for running Valgrind in its own source directory, any executable should do for the test). Look for the libarmmem section starting with ------ start ELF OBJECT ------------------------------------------------------- ------ name = /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so The key part is this table --- Reading (ELF, standard) dynamic symbol table (14 entries) --- raw symbol [ 1]: LOC SEC : svma 0x0000000374, sz 0 NONAME raw symbol [ 2]: LOC SEC : svma 0x0000014024, sz 0 NONAME raw symbol [ 3]: WEA FUN : svma 0x0000000000, sz 0 __cxa_finalize     ignore -- size=0: __cxa_finalize raw symbol [ 4]: WEA NOT : svma 0x0000000000, sz 0 _ITM_deregisterTMCloneTable raw symbol [ 5]: WEA NOT : svma 0x0000000000, sz 0 __gmon_start__ raw symbol [ 6]: WEA NOT : svma 0x0000000000, sz 0 _ITM_registerTMCloneTable raw symbol [ 7]: GLO NOT : svma 0x00000030f8, sz 0 memset raw symbol [ 8]: GLO NOT : svma 0x00000030e4, sz 0 mempcpy raw symbol [ 9]: GLO NOT : svma 0x00000031c0, sz 0 strlen raw symbol [ 10]: GLO NOT : svma 0x000000216c, sz 0 memmove raw symbol [ 11]: GLO NOT : svma 0x00000030e4, sz 0 __mempcpy raw symbol [ 12]: GLO NOT : svma 0x0000000b58, sz 0 memcpy raw symbol [ 13]: GLO NOT : svma 0x00000004d0, sz 0 memcmp "GLO NOT" means "global notype". Valgrind will ignore notype objects. "sz 0" is also a problem as Valgrind will ignore objects with a size of 0. Valgrind also needs some modifications, but that requires libarmmem to be fixed first.