Menu
▾
▴
valgrind-users
|
From: Silva J. <joa...@al...> - 2017-11-29 13:14:07
|
Hi, >From Valgrind's 3.13.0 NEWS, I see that: * The amount of memory that Valgrind can use has been increased from 64GB to 128GB. In particular this means your application can allocate up to about 60GB when running on Memcheck. * Valgrind's default load address has been changed from 0x3800'0000 to 0x5800'0000, so as to make it possible to load larger executables. This should make it possible to load executables of size at least 1200MB. But I get this error: valgrind: mmap(0xa64000, 1793339392) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. when trying to analyse an executable with 13 MB that occupies 2.6 GB virtual memory (1.7 GB resident). This program is written in Ada/SPARK and C/C++ and most of the memory (99%) is statically allocated. Does anyone know what's wrong? Thanks. João M. S. Silva |
|
From: Ivo R. <iv...@iv...> - 2017-11-29 13:42:21
|
2017-11-29 13:37 GMT+01:00 Silva João <joa...@al...>: > valgrind: mmap(0xa64000, 1793339392) failed in UME with error 22 (Invalid > argument). This may be caused by other mmap arguments than just size. Please report some details about your system and also strace output for the valgrind run. Particularly interesting is the mmap syscall which results in EINVAL. Beware that valgrind binary executes the actual Valgrind analysis tool, so use something like 'strace -f'. Also running valgrind with some debug turned on would help, try '-d -d -d' for start. I. |
|
From: Silva J. <joa...@al...> - 2017-11-29 14:39:16
|
> This may be caused by other mmap arguments than just size.
> Please report some details about your system and also strace output
> for the valgrind run.
System details:
28 x Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
9 GB RAM
> Particularly interesting is the mmap syscall which results in EINVAL.
> Beware that valgrind binary executes the actual Valgrind analysis tool,
> so use
> something like 'strace -f'.
I don't think there is any syscall resulting in EIVAL. Please see below.
> Also running valgrind with some debug turned on would help, try '-d -d
> -d' for start.
Please see below.
João M. S. Silva
Output from strace -f:
execve("/home/AltranUK/jsilva.fs/bin/valgrind", ["/home/AltranUK/jsilva.fs/bin/val"..., "/u/wh/rel/ifaplrel/pw_fwp_engine"...], [/* 51 vars */]) = 0
brk(0) = 0x19a5000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbcfebb8000
open("/opt/Citrix/VDA/lib64/libctxXrandrhook.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\7\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0555, st_size=6208, ...}) = 0
mmap(NULL, 2101312, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbcfe797000
mprotect(0x7fbcfe798000, 2093056, PROT_NONE) = 0
mmap(0x7fbcfe997000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7fbcfe997000
close(3) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=98922, ...}) = 0
mmap(NULL, 98922, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbcfeb9f000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\34\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2118128, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbcfeb9e000
mmap(NULL, 3932672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbcfe3d6000
mprotect(0x7fbcfe58d000, 2093056, PROT_NONE) = 0
mmap(0x7fbcfe78c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b6000) = 0x7fbcfe78c000
mmap(0x7fbcfe792000, 16896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbcfe792000
close(3) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbcfeb9c000
arch_prctl(ARCH_SET_FS, 0x7fbcfeb9c740) = 0
mprotect(0x7fbcfe78c000, 16384, PROT_READ) = 0
mprotect(0x7fbcfe997000, 4096, PROT_READ) = 0
mprotect(0x7fbcfebb9000, 4096, PROT_READ) = 0
munmap(0x7fbcfeb9f000, 98922) = 0
open("/u/wh/rel/ifaplrel/pw_fwp_engine.eab", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\320i@\0\0\0\0\0"..., 4096) = 4096
close(3) = 0
brk(0) = 0x19a5000
brk(0x19c6000) = 0x19c6000
brk(0) = 0x19c6000
readlink("/proc/self/exe", "/home/AltranUK/jsilva.fs/bin/val"..., 500) = 37
execve("/home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux", ["/home/AltranUK/jsilva.fs/bin/val"..., "/u/wh/rel/ifaplrel/pw_fwp_engine"...], [/* 52 vars */]) = 0
open("/proc/self/maps", O_RDONLY) = 3
read(3, "58000000-58236000 r-xp 00000000 "..., 100000) = 564
read(3, "", 99436) = 0
close(3) = 0
mmap(0x1002001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x1002001000
getrlimit(RLIMIT_DATA, {rlim_cur=RLIM64_INFINITY, rlim_max=RLIM64_INFINITY}) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
getcwd("/home/AltranUK/jsilva.fs/SVN/wip_58", 499) = 36
open("/home/AltranUK/jsilva.fs/.valgrindrc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./.valgrindrc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/u/wh/rel/ifaplrel/pw_fwp_engine.eab", O_RDONLY) = 3
stat("/u/wh/rel/ifaplrel/pw_fwp_engine.eab", {st_mode=S_IFREG|0777, st_size=13012024, ...}) = 0
getxattr("/u/wh/rel/ifaplrel/pw_fwp_engine.eab", "security.capability", 0x0, 0) = -1 ENODATA (No data available)
geteuid() = 16777221
getegid() = 16777268
getgroups(0, NULL) = 5
getgroups(5, [39, 16777267, 16777268, 16777269, 16777270]) = 5
fstat(3, {st_mode=S_IFREG|0777, st_size=13012024, ...}) = 0
pread(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\320i@\0\0\0\0\0"..., 4096, 0) = 4096
pread(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\320i@\0\0\0\0\0"..., 64, 0) = 64
pread(3, "\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0@\0\0\0\0\0@\0@\0\0\0\0\0"..., 504, 64) = 504
pread(3, "/lib64/ld-linux-x86-64.so.2\0", 28, 568) = 28
open("/lib64/ld-linux-x86-64.so.2", O_RDONLY) = 4
pread(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\21\0\0\0\0\0\0"..., 64, 0) = 64
pread(4, "\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 392, 64) = 392
mmap(0x400000, 4583424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x400000
fstat(3, {st_mode=S_IFREG|0777, st_size=13012024, ...}) = 0
readlink("/proc/self/fd/3", "/u/wh/rel/ifaplrel/pw_fwp_engine"..., 4096) = 36
mmap(0xa5e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x45e000) = 0xa5e000
fstat(3, {st_mode=S_IFREG|0777, st_size=13012024, ...}) = 0
readlink("/proc/self/fd/3", "/u/wh/rel/ifaplrel/pw_fwp_engine"..., 4096) = 36
write(2, "valgrind: mmap(0xa64000, 1793339"..., 85valgrind: mmap(0xa64000, 1793339392) failed in UME with error 22 (Invalid argument).
) = 85
write(2, "valgrind: this can be caused by "..., 88valgrind: this can be caused by executables with very large text, data or bss segments.
) = 88
exit_group(1) = ?
+++ exited with 1 +++
Output from valgrind -d -d -d:
--87803:1:debuglog DebugLog system started by Stage 1, level 3 logging requested
--87803:1:launcher no tool requested, defaulting to 'memcheck'
--87803:2:launcher selecting platform for '/u/wh/rel/ifaplrel/pw_fwp_engine.eab'
--87803:2:launcher selecting platform for '/u/wh/rel/ifaplrel/pw_fwp_engine.eab'
--87803:2:launcher opened '/u/wh/rel/ifaplrel/pw_fwp_engine.eab'
--87803:2:launcher read 4096 bytes from '/u/wh/rel/ifaplrel/pw_fwp_engine.eab'
--87803:2:launcher selected platform 'amd64-linux'
--87803:1:launcher selected platform 'amd64-linux'
--87803:1:launcher launching /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux
--87803:1:debuglog DebugLog system started by Stage 2 (main), level 3 logging requested
--87803:1: main Welcome to Valgrind version 3.13.0 debug logging
--87803:1: main Checking current stack is plausible
--87803:1: main Checking initial stack was noted
--87803:1: main Starting the address space manager
--87803:2: aspacem sp_at_startup = 0x7ffda58b2a30 (supplied)
--87803:2: aspacem minAddr = 0x0004000000 (computed)
--87803:2: aspacem maxAddr = 0x1fffffffff (computed)
--87803:2: aspacem cStart = 0x0004000000 (computed)
--87803:2: aspacem vStart = 0x1002000000 (computed)
--87803:2: aspacem suggested_clstack_end = 0x1fff000fff (computed)
--87803:2: aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments)
--87803:2: aspacem 0 segment names in 0 slots
--87803:2: aspacem freelist is empty
--87803:2: aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed
--87803:2: aspacem 1: 0004000000-1001ffffff 65504m
--87803:2: aspacem 2: RSVN 1002000000-1002000fff 4096 ----- SmFixed
--87803:2: aspacem 3: 1002001000-1fffffffff 65503m
--87803:2: aspacem 4: RSVN 2000000000-ffffffffffffffff 16383e ----- SmFixed
--87803:2: aspacem >>>
--87803:2: aspacem Reading /proc/self/maps
--87803:2: aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps (16 segments)
--87803:2: aspacem 1 segment names in 1 slots
--87803:2: aspacem freelist is empty
--87803:2: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux
--87803:2: aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed
--87803:2: aspacem 1: 0004000000-0057ffffff 1344m
--87803:2: aspacem 2: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=29594718 o=0 (0,4)
--87803:2: aspacem 3: 0058236000-0058434fff 2093056
--87803:2: aspacem 4: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=29594718 o=2314240 (0,4)
--87803:2: aspacem 5: ANON 0058438000-0059e39fff 26m rw---
--87803:2: aspacem 6: 0059e3a000-1001ffffff 64129m
--87803:2: aspacem 7: RSVN 1002000000-1002000fff 4096 ----- SmFixed
--87803:2: aspacem 8: 1002001000-1fffffffff 65503m
--87803:2: aspacem 9: RSVN 2000000000-7ffda5891fff 130934g ----- SmFixed
--87803:2: aspacem 10: ANON 7ffda5892000-7ffda58b3fff 139264 rw---
--87803:2: aspacem 11: RSVN 7ffda58b4000-7ffda58c1fff 57344 ----- SmFixed
--87803:2: aspacem 12: ANON 7ffda58c2000-7ffda58c3fff 8192 r-x--
--87803:2: aspacem 13: RSVN 7ffda58c4000-ffffffffff5fffff 16383e ----- SmFixed
--87803:2: aspacem 14: ANON ffffffffff600000-ffffffffff600fff 4096 r-x--
--87803:2: aspacem 15: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed
--87803:2: aspacem >>>
--87803:1: main Address space manager is running
--87803:1: main Starting the dynamic memory manager
--87803:1:mallocfr newSuperblock at 0x1002001000 (pszB 4194272) owner VALGRIND/core
--87803:1:mallocfr deferred_reclaimSuperblock at 0x1002001000 (pszB 4194272) (prev 0x0) owner VALGRIND/core
--87803:1: main Dynamic memory manager is running
--87803:1: main Initialise m_debuginfo
--87803:1: main VG_(libdir) = /home/AltranUK/jsilva.fs/lib/valgrind
--87803:1: main Getting launcher's name ...
--87803:1: main ... /home/AltranUK/jsilva.fs/bin/valgrind
--87803:1: main Get hardware capabilities ...
--87803:1: cache warning: Unknown Intel cache config value (0x63), ignoring
--87803:1: cache Autodetected cache info is sensible
--87803:1: cache Cache info:
--87803:1: cache #levels = 3
--87803:1: cache #caches = 4
--87803:1: cache cache #0:
--87803:1: cache kind = data
--87803:1: cache level = 1
--87803:1: cache size = 32768 bytes
--87803:1: cache linesize = 64 bytes
--87803:1: cache assoc = 8
--87803:1: cache cache #1:
--87803:1: cache kind = insn
--87803:1: cache level = 1
--87803:1: cache size = 32768 bytes
--87803:1: cache linesize = 64 bytes
--87803:1: cache assoc = 8
--87803:1: cache cache #2:
--87803:1: cache kind = unified
--87803:1: cache level = 2
--87803:1: cache size = 262144 bytes
--87803:1: cache linesize = 64 bytes
--87803:1: cache assoc = 8
--87803:1: cache cache #3:
--87803:1: cache kind = unified
--87803:1: cache level = 3
--87803:1: cache size = 36700160 bytes
--87803:1: cache linesize = 64 bytes
--87803:1: cache assoc = 20
--87803:1: main ... arch = AMD64, hwcaps = amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--87803:1: main Getting the working directory at startup
--87803:1: main ... /home/AltranUK/jsilva.fs/SVN/wip_58
--87803:1: main Split up command line
--87803:1: main (early_) Process Valgrind's command line options
--87803:1: main Create initial image
--87803:1: initimg Loading client
valgrind: mmap(0xa64000, 1793339392) failed in UME with error 22 (Invalid argument).
valgrind: this can be caused by executables with very large text, data or bss segments.
|
|
From: Ivo R. <iv...@iv...> - 2017-11-29 14:55:29
Attachments:
01-enable-debug-printf.patch
|
Thank you for a quick reply. The error message observed is actually what check_mmap() in coregrind/m_ume/elf.c reports. I suspect that we run into issue with VG_(am_get_advisory)() but I want to be sure. Please could you grab Valgrind source, apply the attached patch to it and build it as per http://valgrind.org/downloads/repository.html. This should create additional debug output which would point at the culprit. I. |
|
From: Silva J. <joa...@al...> - 2017-11-29 16:16:08
|
> The error message observed is actually what check_mmap() in > coregrind/m_ume/elf.c reports. > I suspect that we run into issue with VG_(am_get_advisory)() but I want > to be > sure. > > Please could you grab Valgrind source, apply the attached patch to it > and build it as per https://urldefense.proofpoint.com/v2/url?u=http- > 3A__valgrind.org_downloads_repository.html&d=DwIBaQ&c=cxWN2QSDopt5SklNfb > jIjg&r=kFgLKUA0sRpjkz87cv1MIbzoNFQTvL7qNSsQc4Al5Ps&m=vg7yTij7uoBqsisvbrE > Rr4wliD4LHT21JAvwKSjFdX8&s=8L1bxPA6b3GXxRmVjJZC5dI- > MCdSzDCqthYxICjT_vw&e=. > This should create additional debug output which would point at the > culprit. I'm not sure it worked (I was already using Valgrind that I built, so I patched, ran make and make install): --92903:1:debuglog DebugLog system started by Stage 1, level 3 logging requested --92903:1:launcher no tool requested, defaulting to 'memcheck' --92903:2:launcher selecting platform for '/u/wh/rel/ifaplrel/pw_fwp_engine.eab' --92903:2:launcher selecting platform for '/u/wh/rel/ifaplrel/pw_fwp_engine.eab' --92903:2:launcher opened '/u/wh/rel/ifaplrel/pw_fwp_engine.eab' --92903:2:launcher read 4096 bytes from '/u/wh/rel/ifaplrel/pw_fwp_engine.eab' --92903:2:launcher selected platform 'amd64-linux' --92903:1:launcher selected platform 'amd64-linux' --92903:1:launcher launching /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux --92903:1:debuglog DebugLog system started by Stage 2 (main), level 3 logging requested --92903:1: main Welcome to Valgrind version 3.13.0 debug logging --92903:1: main Checking current stack is plausible --92903:1: main Checking initial stack was noted --92903:1: main Starting the address space manager --92903:2: aspacem sp_at_startup = 0x7ffc6d909130 (supplied) --92903:2: aspacem minAddr = 0x0004000000 (computed) --92903:2: aspacem maxAddr = 0x1fffffffff (computed) --92903:2: aspacem cStart = 0x0004000000 (computed) --92903:2: aspacem vStart = 0x1002000000 (computed) --92903:2: aspacem suggested_clstack_end = 0x1fff000fff (computed) --92903:2: aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments) --92903:2: aspacem 0 segment names in 0 slots --92903:2: aspacem freelist is empty --92903:2: aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --92903:2: aspacem 1: 0004000000-1001ffffff 65504m --92903:2: aspacem 2: RSVN 1002000000-1002000fff 4096 ----- SmFixed --92903:2: aspacem 3: 1002001000-1fffffffff 65503m --92903:2: aspacem 4: RSVN 2000000000-ffffffffffffffff 16383e ----- SmFixed --92903:2: aspacem >>> --92903:2: aspacem Reading /proc/self/maps --92903:2: aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps (16 segments) --92903:2: aspacem 1 segment names in 1 slots --92903:2: aspacem freelist is empty --92903:2: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux --92903:2: aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --92903:2: aspacem 1: 0004000000-0057ffffff 1344m --92903:2: aspacem 2: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=2635334 o=0 (0,4) --92903:2: aspacem 3: 0058236000-0058434fff 2093056 --92903:2: aspacem 4: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=2635334 o=2314240 (0,4) --92903:2: aspacem 5: ANON 0058438000-0059e39fff 26m rw--- --92903:2: aspacem 6: 0059e3a000-1001ffffff 64129m --92903:2: aspacem 7: RSVN 1002000000-1002000fff 4096 ----- SmFixed --92903:2: aspacem 8: 1002001000-1fffffffff 65503m --92903:2: aspacem 9: RSVN 2000000000-7ffc6d8e8fff 130929g ----- SmFixed --92903:2: aspacem 10: ANON 7ffc6d8e9000-7ffc6d90afff 139264 rw--- --92903:2: aspacem 11: RSVN 7ffc6d90b000-7ffc6d972fff 425984 ----- SmFixed --92903:2: aspacem 12: ANON 7ffc6d973000-7ffc6d974fff 8192 r-x-- --92903:2: aspacem 13: RSVN 7ffc6d975000-ffffffffff5fffff 16383e ----- SmFixed --92903:2: aspacem 14: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- --92903:2: aspacem 15: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed --92903:2: aspacem >>> --92903:1: main Address space manager is running --92903:1: main Starting the dynamic memory manager --92903:1:mallocfr newSuperblock at 0x1002001000 (pszB 4194272) owner VALGRIND/core --92903:1:mallocfr deferred_reclaimSuperblock at 0x1002001000 (pszB 4194272) (prev 0x0) owner VALGRIND/core --92903:1: main Dynamic memory manager is running --92903:1: main Initialise m_debuginfo --92903:1: main VG_(libdir) = /home/AltranUK/jsilva.fs/lib/valgrind --92903:1: main Getting launcher's name ... --92903:1: main ... /home/AltranUK/jsilva.fs/bin/valgrind --92903:1: main Get hardware capabilities ... --92903:1: cache warning: Unknown Intel cache config value (0x63), ignoring --92903:1: cache Autodetected cache info is sensible --92903:1: cache Cache info: --92903:1: cache #levels = 3 --92903:1: cache #caches = 4 --92903:1: cache cache #0: --92903:1: cache kind = data --92903:1: cache level = 1 --92903:1: cache size = 32768 bytes --92903:1: cache linesize = 64 bytes --92903:1: cache assoc = 8 --92903:1: cache cache #1: --92903:1: cache kind = insn --92903:1: cache level = 1 --92903:1: cache size = 32768 bytes --92903:1: cache linesize = 64 bytes --92903:1: cache assoc = 8 --92903:1: cache cache #2: --92903:1: cache kind = unified --92903:1: cache level = 2 --92903:1: cache size = 262144 bytes --92903:1: cache linesize = 64 bytes --92903:1: cache assoc = 8 --92903:1: cache cache #3: --92903:1: cache kind = unified --92903:1: cache level = 3 --92903:1: cache size = 36700160 bytes --92903:1: cache linesize = 64 bytes --92903:1: cache assoc = 20 --92903:1: main ... arch = AMD64, hwcaps = amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi --92903:1: main Getting the working directory at startup --92903:1: main ... /home/AltranUK/jsilva.fs/SVN/wip_58 --92903:1: main Split up command line --92903:1: main (early_) Process Valgrind's command line options --92903:1: main Create initial image --92903:1: initimg Loading client --92903:0: ume mmap_file_fixed_client #1 --92903:0: aspacem <<< SHOW_SEGMENTS: after #1 (19 segments) --92903:0: aspacem 2 segment names in 2 slots --92903:0: aspacem freelist is empty --92903:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux --92903:0: aspacem (1,67,1) /u/wh/rel/ifaplrel/pw_fwp_engine.eab --92903:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed --92903:0: aspacem 1: file 0000400000-000085efff 4583424 r-x-- d=0xfd00 i=712737 o=0 (1,67) --92903:0: aspacem 2: RSVN 000085f000-0003ffffff 55m ----- SmFixed --92903:0: aspacem 3: 0004000000-0057ffffff 1344m --92903:0: aspacem 4: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=2635334 o=0 (0,4) --92903:0: aspacem 5: 0058236000-0058434fff 2093056 --92903:0: aspacem 6: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=2635334 o=2314240 (0,4) --92903:0: aspacem 7: ANON 0058438000-0059e39fff 26m rw--- --92903:0: aspacem 8: 0059e3a000-1001ffffff 64129m --92903:0: aspacem 9: RSVN 1002000000-1002000fff 4096 ----- SmFixed --92903:0: aspacem 10: ANON 1002001000-1002400fff 4194304 rwx-- --92903:0: aspacem 11: 1002401000-1fffffffff 65499m --92903:0: aspacem 12: RSVN 2000000000-7ffc6d8e8fff 130929g ----- SmFixed --92903:0: aspacem 13: ANON 7ffc6d8e9000-7ffc6d90afff 139264 rw--- --92903:0: aspacem 14: RSVN 7ffc6d90b000-7ffc6d972fff 425984 ----- SmFixed --92903:0: aspacem 15: ANON 7ffc6d973000-7ffc6d974fff 8192 r-x-- --92903:0: aspacem 16: RSVN 7ffc6d975000-ffffffffff5fffff 16383e ----- SmFixed --92903:0: aspacem 17: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- --92903:0: aspacem 18: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed --92903:0: aspacem >>> --92903:0: ume mmap_file_fixed_client #1 --92903:0: aspacem <<< SHOW_SEGMENTS: after #1 (21 segments) --92903:0: aspacem 2 segment names in 2 slots --92903:0: aspacem freelist is empty --92903:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux --92903:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab --92903:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed --92903:0: aspacem 1: file 0000400000-000085efff 4583424 r-x-- d=0xfd00 i=712737 o=0 (1,67) --92903:0: aspacem 2: RSVN 000085f000-0000a5dfff 2093056 ----- SmFixed --92903:0: aspacem 3: file 0000a5e000-0000a63fff 24576 rw--- d=0xfd00 i=712737 o=4579328 (1,67) --92903:0: aspacem 4: RSVN 0000a64000-0003ffffff 53m ----- SmFixed --92903:0: aspacem 5: 0004000000-0057ffffff 1344m --92903:0: aspacem 6: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=2635334 o=0 (0,4) --92903:0: aspacem 7: 0058236000-0058434fff 2093056 --92903:0: aspacem 8: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=2635334 o=2314240 (0,4) --92903:0: aspacem 9: ANON 0058438000-0059e39fff 26m rw--- --92903:0: aspacem 10: 0059e3a000-1001ffffff 64129m --92903:0: aspacem 11: RSVN 1002000000-1002000fff 4096 ----- SmFixed --92903:0: aspacem 12: ANON 1002001000-1002400fff 4194304 rwx-- --92903:0: aspacem 13: 1002401000-1fffffffff 65499m --92903:0: aspacem 14: RSVN 2000000000-7ffc6d8e8fff 130929g ----- SmFixed --92903:0: aspacem 15: ANON 7ffc6d8e9000-7ffc6d90afff 139264 rw--- --92903:0: aspacem 16: RSVN 7ffc6d90b000-7ffc6d972fff 425984 ----- SmFixed --92903:0: aspacem 17: ANON 7ffc6d973000-7ffc6d974fff 8192 r-x-- --92903:0: aspacem 18: RSVN 7ffc6d975000-ffffffffff5fffff 16383e ----- SmFixed --92903:0: aspacem 19: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- --92903:0: aspacem 20: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed --92903:0: aspacem >>> --92903:0: ume mmap_anon_fixed_client #2 --92903:0: aspacem <<< SHOW_SEGMENTS: after #2 (21 segments) --92903:0: aspacem 2 segment names in 2 slots --92903:0: aspacem freelist is empty --92903:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux --92903:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab --92903:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed --92903:0: aspacem 1: file 0000400000-000085efff 4583424 r-x-- d=0xfd00 i=712737 o=0 (1,67) --92903:0: aspacem 2: RSVN 000085f000-0000a5dfff 2093056 ----- SmFixed --92903:0: aspacem 3: file 0000a5e000-0000a63fff 24576 rw--- d=0xfd00 i=712737 o=4579328 (1,67) --92903:0: aspacem 4: RSVN 0000a64000-0003ffffff 53m ----- SmFixed --92903:0: aspacem 5: 0004000000-0057ffffff 1344m --92903:0: aspacem 6: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=2635334 o=0 (0,4) --92903:0: aspacem 7: 0058236000-0058434fff 2093056 --92903:0: aspacem 8: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=2635334 o=2314240 (0,4) --92903:0: aspacem 9: ANON 0058438000-0059e39fff 26m rw--- --92903:0: aspacem 10: 0059e3a000-1001ffffff 64129m --92903:0: aspacem 11: RSVN 1002000000-1002000fff 4096 ----- SmFixed --92903:0: aspacem 12: ANON 1002001000-1002400fff 4194304 rwx-- --92903:0: aspacem 13: 1002401000-1fffffffff 65499m --92903:0: aspacem 14: RSVN 2000000000-7ffc6d8e8fff 130929g ----- SmFixed --92903:0: aspacem 15: ANON 7ffc6d8e9000-7ffc6d90afff 139264 rw--- --92903:0: aspacem 16: RSVN 7ffc6d90b000-7ffc6d972fff 425984 ----- SmFixed --92903:0: aspacem 17: ANON 7ffc6d973000-7ffc6d974fff 8192 r-x-- --92903:0: aspacem 18: RSVN 7ffc6d975000-ffffffffff5fffff 16383e ----- SmFixed --92903:0: aspacem 19: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- --92903:0: aspacem 20: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed --92903:0: aspacem >>> valgrind: mmap(0xa64000, 1793339392) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. The difference seems to be the SHOW_SEGMENTS? João M. S. Silva |
|
From: Ivo R. <iv...@iv...> - 2017-11-29 16:46:24
|
2017-11-29 17:15 GMT+01:00 Silva João <joa...@al...>: > I'm not sure it worked (I was already using Valgrind that I built, so I patched, ran make and make install): It worked pretty well. Valgrind tries to map an ELF file (/u/wh/rel/ifaplrel/pw_fwp_engine.eab) and one of its program headers has two parts: data and bss. The data part (few kBs) backed by the file has been mmap'ed to segment 3 (shown in "after #1"): ... > --92903:1: initimg Loading client > --92903:0: ume mmap_file_fixed_client #1 > --92903:0: aspacem <<< SHOW_SEGMENTS: after #1 (19 segments) > --92903:0: aspacem 2 segment names in 2 slots > --92903:0: aspacem freelist is empty > --92903:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux > --92903:0: aspacem (1,67,1) /u/wh/rel/ifaplrel/pw_fwp_engine.eab > --92903:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed > --92903:0: aspacem 1: file 0000400000-000085efff 4583424 r-x-- d=0xfd00 i=712737 o=0 (1,67) > --92903:0: aspacem 2: RSVN 000085f000-0003ffffff 55m ----- SmFixed > --92903:0: aspacem 3: 0004000000-0057ffffff 1344m > --92903:0: aspacem 4: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=2635334 o=0 (0,4) > --92903:0: aspacem 5: 0058236000-0058434fff 2093056 > --92903:0: aspacem 6: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=2635334 o=2314240 (0,4) > --92903:0: aspacem 7: ANON 0058438000-0059e39fff 26m rw--- > --92903:0: aspacem 8: 0059e3a000-1001ffffff 64129m > --92903:0: aspacem 9: RSVN 1002000000-1002000fff 4096 ----- SmFixed > --92903:0: aspacem 10: ANON 1002001000-1002400fff 4194304 rwx-- > --92903:0: aspacem 11: 1002401000-1fffffffff 65499m > --92903:0: aspacem 12: RSVN 2000000000-7ffc6d8e8fff 130929g ----- SmFixed > --92903:0: aspacem 13: ANON 7ffc6d8e9000-7ffc6d90afff 139264 rw--- > --92903:0: aspacem 14: RSVN 7ffc6d90b000-7ffc6d972fff 425984 ----- SmFixed > --92903:0: aspacem 15: ANON 7ffc6d973000-7ffc6d974fff 8192 r-x-- > --92903:0: aspacem 16: RSVN 7ffc6d975000-ffffffffff5fffff 16383e ----- SmFixed > --92903:0: aspacem 17: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- > --92903:0: aspacem 18: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed > --92903:0: aspacem >>> > --92903:0: ume mmap_file_fixed_client #1 > --92903:0: aspacem <<< SHOW_SEGMENTS: after #1 (21 segments) > --92903:0: aspacem 2 segment names in 2 slots > --92903:0: aspacem freelist is empty > --92903:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux > --92903:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab > --92903:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed > --92903:0: aspacem 1: file 0000400000-000085efff 4583424 r-x-- d=0xfd00 i=712737 o=0 (1,67) > --92903:0: aspacem 2: RSVN 000085f000-0000a5dfff 2093056 ----- SmFixed > --92903:0: aspacem 3: file 0000a5e000-0000a63fff 24576 rw--- d=0xfd00 i=712737 o=4579328 (1,67) > --92903:0: aspacem 4: RSVN 0000a64000-0003ffffff 53m ----- SmFixed > --92903:0: aspacem 5: 0004000000-0057ffffff 1344m > --92903:0: aspacem 6: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=2635334 o=0 (0,4) > --92903:0: aspacem 7: 0058236000-0058434fff 2093056 > --92903:0: aspacem 8: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=2635334 o=2314240 (0,4) > --92903:0: aspacem 9: ANON 0058438000-0059e39fff 26m rw--- > --92903:0: aspacem 10: 0059e3a000-1001ffffff 64129m > --92903:0: aspacem 11: RSVN 1002000000-1002000fff 4096 ----- SmFixed > --92903:0: aspacem 12: ANON 1002001000-1002400fff 4194304 rwx-- > --92903:0: aspacem 13: 1002401000-1fffffffff 65499m > --92903:0: aspacem 14: RSVN 2000000000-7ffc6d8e8fff 130929g ----- SmFixed > --92903:0: aspacem 15: ANON 7ffc6d8e9000-7ffc6d90afff 139264 rw--- > --92903:0: aspacem 16: RSVN 7ffc6d90b000-7ffc6d972fff 425984 ----- SmFixed > --92903:0: aspacem 17: ANON 7ffc6d973000-7ffc6d974fff 8192 r-x-- > --92903:0: aspacem 18: RSVN 7ffc6d975000-ffffffffff5fffff 16383e ----- SmFixed > --92903:0: aspacem 19: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- > --92903:0: aspacem 20: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed > --92903:0: aspacem >>> Now Valgrind tries to get finish with the bss of that program header. That needs to come directly after the data part. For some reason it determined its size is 1793339392 bytes. However there is not enough free address space at address 0x0000a64000 to accommodate that amount of bytes. Thus we see the failure. > --92903:0: ume mmap_anon_fixed_client #2 > --92903:0: aspacem <<< SHOW_SEGMENTS: after #2 (21 segments) > --92903:0: aspacem 2 segment names in 2 slots > --92903:0: aspacem freelist is empty > --92903:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux > --92903:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab > --92903:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed > --92903:0: aspacem 1: file 0000400000-000085efff 4583424 r-x-- d=0xfd00 i=712737 o=0 (1,67) > --92903:0: aspacem 2: RSVN 000085f000-0000a5dfff 2093056 ----- SmFixed > --92903:0: aspacem 3: file 0000a5e000-0000a63fff 24576 rw--- d=0xfd00 i=712737 o=4579328 (1,67) > --92903:0: aspacem 4: RSVN 0000a64000-0003ffffff 53m ----- SmFixed > --92903:0: aspacem 5: 0004000000-0057ffffff 1344m > --92903:0: aspacem 6: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=2635334 o=0 (0,4) > --92903:0: aspacem 7: 0058236000-0058434fff 2093056 > --92903:0: aspacem 8: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=2635334 o=2314240 (0,4) > --92903:0: aspacem 9: ANON 0058438000-0059e39fff 26m rw--- > --92903:0: aspacem 10: 0059e3a000-1001ffffff 64129m > --92903:0: aspacem 11: RSVN 1002000000-1002000fff 4096 ----- SmFixed > --92903:0: aspacem 12: ANON 1002001000-1002400fff 4194304 rwx-- > --92903:0: aspacem 13: 1002401000-1fffffffff 65499m > --92903:0: aspacem 14: RSVN 2000000000-7ffc6d8e8fff 130929g ----- SmFixed > --92903:0: aspacem 15: ANON 7ffc6d8e9000-7ffc6d90afff 139264 rw--- > --92903:0: aspacem 16: RSVN 7ffc6d90b000-7ffc6d972fff 425984 ----- SmFixed > --92903:0: aspacem 17: ANON 7ffc6d973000-7ffc6d974fff 8192 r-x-- > --92903:0: aspacem 18: RSVN 7ffc6d975000-ffffffffff5fffff 16383e ----- SmFixed > --92903:0: aspacem 19: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- > --92903:0: aspacem 20: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed > --92903:0: aspacem >>> > valgrind: mmap(0xa64000, 1793339392) failed in UME with error 22 (Invalid argument). > valgrind: this can be caused by executables with very large text, data or bss segments. Please can you double check whether pw_fwp_engine.eab really contains such an extra large program header? For example 'readelf -l' might help. I. |
|
From: Silva J. <joa...@al...> - 2017-11-29 16:56:18
|
Thanks.
> Please can you double check whether pw_fwp_engine.eab really contains
> such an extra large program header?
> For example 'readelf -l' might help.
This is the result of readelf -l:
Elf file type is EXEC (Executable file)
Entry point 0x4069d0
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040
0x00000000000001f8 0x00000000000001f8 R E 8
INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238
0x000000000000001c 0x000000000000001c R 1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x000000000045e870 0x000000000045e870 R E 200000
LOAD 0x000000000045e870 0x0000000000a5e870 0x0000000000a5e870
0x0000000000004c98 0x000000006ae482b0 RW 200000
DYNAMIC 0x000000000045e890 0x0000000000a5e890 0x0000000000a5e890
0x0000000000000260 0x0000000000000260 RW 8
NOTE 0x0000000000000254 0x0000000000400254 0x0000000000400254
0x0000000000000020 0x0000000000000020 R 4
TLS 0x000000000045e870 0x0000000000a5e870 0x0000000000a5e870
0x0000000000000008 0x0000000000000008 R 8
GNU_EH_FRAME 0x00000000003b2570 0x00000000007b2570 0x00000000007b2570
0x000000000001e2f4 0x000000000001e2f4 R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 10
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table
03 .tdata .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag
06 .tdata
07 .eh_frame_hdr
08
João M. S. Silva
|
|
From: Ivo R. <iv...@iv...> - 2017-11-29 17:19:34
|
2017-11-29 17:55 GMT+01:00 Silva João <joa...@al...>: > This is the result of readelf -l: ... > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040 > 0x00000000000001f8 0x00000000000001f8 R E 8 > INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238 > 0x000000000000001c 0x000000000000001c R 1 > [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] > LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 > 0x000000000045e870 0x000000000045e870 R E 200000 > LOAD 0x000000000045e870 0x0000000000a5e870 0x0000000000a5e870 > 0x0000000000004c98 0x000000006ae482b0 RW 200000 This program header shows: FileSize: 0x4c98 MemSize: 0x000000006ae482b0 (~1,7 GB) So Valgrind is interpreting this file correctly. I have no idea why this file wants to allocate ~1,7 GB of bss. If that is even remotely correct than Valgrind built as-is cannot map this ELF file at an absolute address. You can work around this problem by redefining Valgrind's load address to a higher one. It's currently 0x58000000 (check with the SEGMENT OUTPUT from previous conversation). Right before it there is a free address space of ~1344m. You need to enlarge this to be big enough to accommodate for your large BSS segment. Have a look at configure.ac (run ./autogen.sh && ./configure). if that works for you, you can submit a patch to have Valgrind's load address configurable with configure, for example. And also supply a better error message and diagnostics about this problem next time. I. |
|
From: Ivo R. <iv...@iv...> - 2017-11-30 08:28:30
|
2017-11-29 19:04 GMT+01:00 Silva João <joa...@al...>: >> I have no idea why this file wants to allocate ~1,7 GB of bss. > > All memory is allocated statically in Ada/SPARK. There is no dynamic memory allocation except for the usage of libxerces in C/C++. BSS is statically "allocated" memory. > >> You can work around this problem by redefining Valgrind's load address >> to a higher one. >> It's currently 0x58000000 (check with the SEGMENT OUTPUT from previous >> conversation). > > I didn't find a SEGMENT OUTPUT occurrence in our conversation. Oh, have a look here where segment 3. has been created and listed in the second SHOW_SEGMENTS output. --92903:0: ume mmap_file_fixed_client #1 --92903:0: aspacem <<< SHOW_SEGMENTS: after #1 (19 segments) --92903:0: aspacem 2 segment names in 2 slots --92903:0: aspacem freelist is empty --92903:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux --92903:0: aspacem (1,67,1) /u/wh/rel/ifaplrel/pw_fwp_engine.eab --92903:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed --92903:0: aspacem 1: file 0000400000-000085efff 4583424 r-x-- d=0xfd00 i=712737 o=0 (1,67) --92903:0: aspacem 2: RSVN 000085f000-0003ffffff 55m ----- SmFixed --92903:0: aspacem 3: 0004000000-0057ffffff 1344m --92903:0: aspacem 4: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=2635334 o=0 (0,4) --92903:0: aspacem 5: 0058236000-0058434fff 2093056 --92903:0: aspacem 6: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=2635334 o=2314240 (0,4) --92903:0: aspacem 7: ANON 0058438000-0059e39fff 26m rw--- --92903:0: aspacem 8: 0059e3a000-1001ffffff 64129m --92903:0: aspacem 9: RSVN 1002000000-1002000fff 4096 ----- SmFixed --92903:0: aspacem 10: ANON 1002001000-1002400fff 4194304 rwx-- --92903:0: aspacem 11: 1002401000-1fffffffff 65499m --92903:0: aspacem 12: RSVN 2000000000-7ffc6d8e8fff 130929g ----- SmFixed --92903:0: aspacem 13: ANON 7ffc6d8e9000-7ffc6d90afff 139264 rw--- --92903:0: aspacem 14: RSVN 7ffc6d90b000-7ffc6d972fff 425984 ----- SmFixed --92903:0: aspacem 15: ANON 7ffc6d973000-7ffc6d974fff 8192 r-x-- --92903:0: aspacem 16: RSVN 7ffc6d975000-ffffffffff5fffff 16383e ----- SmFixed --92903:0: aspacem 17: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- --92903:0: aspacem 18: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed --92903:0: aspacem >>> --92903:0: ume mmap_file_fixed_client #1 --92903:0: aspacem <<< SHOW_SEGMENTS: after #1 (21 segments) --92903:0: aspacem 2 segment names in 2 slots --92903:0: aspacem freelist is empty --92903:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux --92903:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab --92903:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed --92903:0: aspacem 1: file 0000400000-000085efff 4583424 r-x-- d=0xfd00 i=712737 o=0 (1,67) --92903:0: aspacem 2: RSVN 000085f000-0000a5dfff 2093056 ----- SmFixed --92903:0: aspacem 3: file 0000a5e000-0000a63fff 24576 rw--- d=0xfd00 i=712737 o=4579328 (1,67) --92903:0: aspacem 4: RSVN 0000a64000-0003ffffff 53m ----- SmFixed --92903:0: aspacem 5: 0004000000-0057ffffff 1344m --92903:0: aspacem 6: FILE 0058000000-0058235fff 2318336 r-x-- d=0xfd02 i=2635334 o=0 (0,4) --92903:0: aspacem 7: 0058236000-0058434fff 2093056 --92903:0: aspacem 8: FILE 0058435000-0058437fff 12288 rw--- d=0xfd02 i=2635334 o=2314240 (0,4) --92903:0: aspacem 9: ANON 0058438000-0059e39fff 26m rw--- --92903:0: aspacem 10: 0059e3a000-1001ffffff 64129m --92903:0: aspacem 11: RSVN 1002000000-1002000fff 4096 ----- SmFixed --92903:0: aspacem 12: ANON 1002001000-1002400fff 4194304 rwx-- --92903:0: aspacem 13: 1002401000-1fffffffff 65499m --92903:0: aspacem 14: RSVN 2000000000-7ffc6d8e8fff 130929g ----- SmFixed --92903:0: aspacem 15: ANON 7ffc6d8e9000-7ffc6d90afff 139264 rw--- --92903:0: aspacem 16: RSVN 7ffc6d90b000-7ffc6d972fff 425984 ----- SmFixed --92903:0: aspacem 17: ANON 7ffc6d973000-7ffc6d974fff 8192 r-x-- --92903:0: aspacem 18: RSVN 7ffc6d975000-ffffffffff5fffff 16383e ----- SmFixed --92903:0: aspacem 19: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- --92903:0: aspacem 20: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed --92903:0: aspacem >>> > >> Right before it there is a free address space of ~1344m. You need to >> enlarge this to be big >> enough to accommodate for your large BSS segment. >> Have a look at configure.ac (run ./autogen.sh && ./configure). > > What would be the right keyword to look for? I don't seem to find anything relevant with keywords: BSS, SEGMENT, etc. Search for 0x58000000, in the corresponding platform section (should be amd64-linux in your case). >> if that works for you, you can submit a patch to have Valgrind's load >> address configurable with configure, for example. >> And also supply a better error message and diagnostics about this >> problem next time. > > OK, I will try to. Awesome! Looking forward to it. I. |
|
From: Silva J. <joa...@al...> - 2017-12-01 13:09:19
|
> Oh, have a look here where segment 3. has been created and listed in > the second SHOW_SEGMENTS output. OK. It seems to change position sometimes, it's now in 6: --63000:0: aspacem 6: FILE 0077000000-0077235fff 2318336 r-x-- d=0xfd02 i=25256897 o=0 (0,4) I have set valt_load_address_pri_norml="0x80000000" but it's too much, it cannot build: /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1405:(.text+0x8df): relocation truncated to fit: R_X86_64_32S against `.bss' /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1411:(.text+0x90b): relocation truncated to fit: R_X86_64_32S against `.bss' /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1415:(.text+0x927): relocation truncated to fit: R_X86_64_32S against `.bss' memcheck_amd64_linux-mc_leakcheck.o: In function `lc_scan_memory': /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1154:(.text+0x128f): relocation truncated to fit: R_X86_64_32S against `.rodata' memcheck_amd64_linux-mc_leakcheck.o: In function `print_results': /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1511:(.text+0x18a5): relocation truncated to fit: R_X86_64_32S against `.bss' /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1512:(.text+0x18ac): relocation truncated to fit: R_X86_64_32S against `.bss' /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1514:(.text+0x18bf): relocation truncated to fit: R_X86_64_32S against `.bss' /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1515:(.text+0x18c6): relocation truncated to fit: R_X86_64_32S against `.bss' /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1564:(.text+0x1a46): relocation truncated to fit: R_X86_64_32S against `.bss' /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1565:(.text+0x1a4e): relocation truncated to fit: R_X86_64_32S against `.bss' /home/AltranUK/jsilva.fs/src/valgrind-3.13.0/memcheck/mc_leakcheck.c:1641:(.text+0x1b5d): additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status I've tried 0x77000000 but it's not enough for the program BSS. I'll have to try intermediate values. João M. S. Silva |
|
From: Silva J. <joa...@al...> - 2017-12-01 15:16:50
|
Also, is there a way to force correct compilation when I change the .ac file? Because I need to make clean and make again to make this change effective. I tried ./configure --enable-maintenance-mode but without success. It seems the makefile ignores the fact that the .ac was changed. Yes, I am running autogen.sh and then configure.sh before running make. João M. S. Silva > -----Original Message----- > From: Silva João > Sent: 1 de dezembro de 2017 13:06 > To: 'Ivo Raisr' <iv...@iv...> > Cc: Valgrind Users <val...@li...> > Subject: RE: [Valgrind-users] failed in UME with error 22 > > > Oh, have a look here where segment 3. has been created and listed in > > the second SHOW_SEGMENTS output. > > OK. It seems to change position sometimes, it's now in 6: > > --63000:0: aspacem 6: FILE 0077000000-0077235fff 2318336 r-x-- > d=0xfd02 i=25256897 o=0 (0,4) > > I have set valt_load_address_pri_norml="0x80000000" but it's too much, > it cannot build: > > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1405:(.text+0x8df): relocation truncated > to fit: R_X86_64_32S against `.bss' > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1411:(.text+0x90b): relocation truncated > to fit: R_X86_64_32S against `.bss' > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1415:(.text+0x927): relocation truncated > to fit: R_X86_64_32S against `.bss' > memcheck_amd64_linux-mc_leakcheck.o: In function `lc_scan_memory': > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1154:(.text+0x128f): relocation truncated > to fit: R_X86_64_32S against `.rodata' > memcheck_amd64_linux-mc_leakcheck.o: In function `print_results': > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1511:(.text+0x18a5): relocation truncated > to fit: R_X86_64_32S against `.bss' > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1512:(.text+0x18ac): relocation truncated > to fit: R_X86_64_32S against `.bss' > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1514:(.text+0x18bf): relocation truncated > to fit: R_X86_64_32S against `.bss' > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1515:(.text+0x18c6): relocation truncated > to fit: R_X86_64_32S against `.bss' > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1564:(.text+0x1a46): relocation truncated > to fit: R_X86_64_32S against `.bss' > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1565:(.text+0x1a4e): relocation truncated > to fit: R_X86_64_32S against `.bss' > /home/AltranUK/jsilva.fs/src/valgrind- > 3.13.0/memcheck/mc_leakcheck.c:1641:(.text+0x1b5d): additional > relocation overflows omitted from the output > collect2: error: ld returned 1 exit status > > I've tried 0x77000000 but it's not enough for the program BSS. > > I'll have to try intermediate values. > > João M. S. Silva |
|
From: Silva J. <joa...@al...> - 2017-12-05 10:43:16
|
Hi,
I was able to build Valgrind and run the program with value 0x7d000000:
valt_load_address_pri_norml="0x7d000000"
valt_load_address_pri_norml="0x7d000000"
valt_load_address_pri_norml="0x7d000000"
valt_load_address_sec_norml="0x7d000000"
In order for this parameter in the .ac file to take effect I found out than reapplying the patch you sent forces make to rebuild the executable correctly (otherwise the change gets ignored, probably a bug in Valgrind configure.sh or makefile).
Now I get this, not sure whether the problem is real or comes from having tweaked valt_load_address_*_norml:
--44156:0: ume mmap_file_fixed_client #1
--44156:0: aspacem <<< SHOW_SEGMENTS: after #1 (19 segments)
--44156:0: aspacem 2 segment names in 2 slots
--44156:0: aspacem freelist is empty
--44156:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux
--44156:0: aspacem (1,67,1) /u/wh/rel/ifaplrel/pw_fwp_engine.eab
--44156:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed
--44156:0: aspacem 1: file 0000400000-00008adfff 4907008 r-x-- d=0xfd00 i=712737 o=0 (1,67)
--44156:0: aspacem 2: RSVN 00008ae000-0003ffffff 55m ----- SmFixed
--44156:0: aspacem 3: 0004000000-007cffffff 1936m
--44156:0: aspacem 4: FILE 007d000000-007d27cfff 2609152 r-x-- d=0xfd02 i=2648346 o=0 (0,4)
--44156:0: aspacem 5: 007d27d000-007d47cfff 2097152
--44156:0: aspacem 6: FILE 007d47d000-007d47ffff 12288 rw--- d=0xfd02 i=2648346 o=2609152 (0,4)
--44156:0: aspacem 7: ANON 007d480000-007ee81fff 26m rw---
--44156:0: aspacem 8: 007ee82000-1001ffffff 63537m
--44156:0: aspacem 9: RSVN 1002000000-1002000fff 4096 ----- SmFixed
--44156:0: aspacem 10: ANON 1002001000-1002400fff 4194304 rwx--
--44156:0: aspacem 11: 1002401000-1fffffffff 65499m
--44156:0: aspacem 12: RSVN 2000000000-7ffe2448efff 130936g ----- SmFixed
--44156:0: aspacem 13: ANON 7ffe2448f000-7ffe244b0fff 139264 rw---
--44156:0: aspacem 14: RSVN 7ffe244b1000-7ffe24527fff 487424 ----- SmFixed
--44156:0: aspacem 15: ANON 7ffe24528000-7ffe24529fff 8192 r-x--
--44156:0: aspacem 16: RSVN 7ffe2452a000-ffffffffff5fffff 16383e ----- SmFixed
--44156:0: aspacem 17: ANON ffffffffff600000-ffffffffff600fff 4096 r-x--
--44156:0: aspacem 18: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed
--44156:0: aspacem >>>
--44156:0: ume mmap_file_fixed_client #1
--44156:0: aspacem <<< SHOW_SEGMENTS: after #1 (21 segments)
--44156:0: aspacem 2 segment names in 2 slots
--44156:0: aspacem freelist is empty
--44156:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux
--44156:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab
--44156:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed
--44156:0: aspacem 1: file 0000400000-00008adfff 4907008 r-x-- d=0xfd00 i=712737 o=0 (1,67)
--44156:0: aspacem 2: RSVN 00008ae000-0000aacfff 2093056 ----- SmFixed
--44156:0: aspacem 3: file 0000aad000-0000ab1fff 20480 rw--- d=0xfd00 i=712737 o=4902912 (1,67)
--44156:0: aspacem 4: RSVN 0000ab2000-0003ffffff 53m ----- SmFixed
--44156:0: aspacem 5: 0004000000-007cffffff 1936m
--44156:0: aspacem 6: FILE 007d000000-007d27cfff 2609152 r-x-- d=0xfd02 i=2648346 o=0 (0,4)
--44156:0: aspacem 7: 007d27d000-007d47cfff 2097152
--44156:0: aspacem 8: FILE 007d47d000-007d47ffff 12288 rw--- d=0xfd02 i=2648346 o=2609152 (0,4)
--44156:0: aspacem 9: ANON 007d480000-007ee81fff 26m rw---
--44156:0: aspacem 10: 007ee82000-1001ffffff 63537m
--44156:0: aspacem 11: RSVN 1002000000-1002000fff 4096 ----- SmFixed
--44156:0: aspacem 12: ANON 1002001000-1002400fff 4194304 rwx--
--44156:0: aspacem 13: 1002401000-1fffffffff 65499m
--44156:0: aspacem 14: RSVN 2000000000-7ffe2448efff 130936g ----- SmFixed
--44156:0: aspacem 15: ANON 7ffe2448f000-7ffe244b0fff 139264 rw---
--44156:0: aspacem 16: RSVN 7ffe244b1000-7ffe24527fff 487424 ----- SmFixed
--44156:0: aspacem 17: ANON 7ffe24528000-7ffe24529fff 8192 r-x--
--44156:0: aspacem 18: RSVN 7ffe2452a000-ffffffffff5fffff 16383e ----- SmFixed
--44156:0: aspacem 19: ANON ffffffffff600000-ffffffffff600fff 4096 r-x--
--44156:0: aspacem 20: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed
--44156:0: aspacem >>>
--44156:0: ume mmap_anon_fixed_client #2
--44156:0: aspacem <<< SHOW_SEGMENTS: after #2 (21 segments)
--44156:0: aspacem 2 segment names in 2 slots
--44156:0: aspacem freelist is empty
--44156:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux
--44156:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab
--44156:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed
--44156:0: aspacem 1: file 0000400000-00008adfff 4907008 r-x-- d=0xfd00 i=712737 o=0 (1,67)
--44156:0: aspacem 2: RSVN 00008ae000-0000aacfff 2093056 ----- SmFixed
--44156:0: aspacem 3: file 0000aad000-0000ab1fff 20480 rw--- d=0xfd00 i=712737 o=4902912 (1,67)
--44156:0: aspacem 4: anon 0000ab2000-0078832fff 1917m rw---
--44156:0: aspacem 5: 0078833000-007cffffff 71m
--44156:0: aspacem 6: FILE 007d000000-007d27cfff 2609152 r-x-- d=0xfd02 i=2648346 o=0 (0,4)
--44156:0: aspacem 7: 007d27d000-007d47cfff 2097152
--44156:0: aspacem 8: FILE 007d47d000-007d47ffff 12288 rw--- d=0xfd02 i=2648346 o=2609152 (0,4)
--44156:0: aspacem 9: ANON 007d480000-007ee81fff 26m rw---
--44156:0: aspacem 10: 007ee82000-1001ffffff 63537m
--44156:0: aspacem 11: RSVN 1002000000-1002000fff 4096 ----- SmFixed
--44156:0: aspacem 12: ANON 1002001000-1002400fff 4194304 rwx--
--44156:0: aspacem 13: 1002401000-1fffffffff 65499m
--44156:0: aspacem 14: RSVN 2000000000-7ffe2448efff 130936g ----- SmFixed
--44156:0: aspacem 15: ANON 7ffe2448f000-7ffe244b0fff 139264 rw---
--44156:0: aspacem 16: RSVN 7ffe244b1000-7ffe24527fff 487424 ----- SmFixed
--44156:0: aspacem 17: ANON 7ffe24528000-7ffe24529fff 8192 r-x--
--44156:0: aspacem 18: RSVN 7ffe2452a000-ffffffffff5fffff 16383e ----- SmFixed
--44156:0: aspacem 19: ANON ffffffffff600000-ffffffffff600fff 4096 r-x--
--44156:0: aspacem 20: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed
--44156:0: aspacem >>>
--44156:0: ume mmap_file_fixed_client #1
--44156:0: aspacem <<< SHOW_SEGMENTS: after #1 (22 segments)
--44156:0: aspacem 3 segment names in 3 slots
--44156:0: aspacem freelist is empty
--44156:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux
--44156:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab
--44156:0: aspacem (2,108,1) /usr/lib64/ld-2.17.so
--44156:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed
--44156:0: aspacem 1: file 0000400000-00008adfff 4907008 r-x-- d=0xfd00 i=712737 o=0 (1,67)
--44156:0: aspacem 2: RSVN 00008ae000-0000aacfff 2093056 ----- SmFixed
--44156:0: aspacem 3: file 0000aad000-0000ab1fff 20480 rw--- d=0xfd00 i=712737 o=4902912 (1,67)
--44156:0: aspacem 4: anon 0000ab2000-0078832fff 1917m rw---
--44156:0: aspacem 5: file 0078833000-0078852fff 131072 r-x-- d=0xfd00 i=201446298 o=0 (2,108)
--44156:0: aspacem 6: 0078853000-007cffffff 71m
--44156:0: aspacem 7: FILE 007d000000-007d27cfff 2609152 r-x-- d=0xfd02 i=2648346 o=0 (0,4)
--44156:0: aspacem 8: 007d27d000-007d47cfff 2097152
--44156:0: aspacem 9: FILE 007d47d000-007d47ffff 12288 rw--- d=0xfd02 i=2648346 o=2609152 (0,4)
--44156:0: aspacem 10: ANON 007d480000-007ee81fff 26m rw---
--44156:0: aspacem 11: 007ee82000-1001ffffff 63537m
--44156:0: aspacem 12: RSVN 1002000000-1002000fff 4096 ----- SmFixed
--44156:0: aspacem 13: ANON 1002001000-1002400fff 4194304 rwx--
--44156:0: aspacem 14: 1002401000-1fffffffff 65499m
--44156:0: aspacem 15: RSVN 2000000000-7ffe2448efff 130936g ----- SmFixed
--44156:0: aspacem 16: ANON 7ffe2448f000-7ffe244b0fff 139264 rw---
--44156:0: aspacem 17: RSVN 7ffe244b1000-7ffe24527fff 487424 ----- SmFixed
--44156:0: aspacem 18: ANON 7ffe24528000-7ffe24529fff 8192 r-x--
--44156:0: aspacem 19: RSVN 7ffe2452a000-ffffffffff5fffff 16383e ----- SmFixed
--44156:0: aspacem 20: ANON ffffffffff600000-ffffffffff600fff 4096 r-x--
--44156:0: aspacem 21: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed
--44156:0: aspacem >>>
--44156:0: ume mmap_file_fixed_client #1
--44156:0: aspacem <<< SHOW_SEGMENTS: after #1 (24 segments)
--44156:0: aspacem 3 segment names in 3 slots
--44156:0: aspacem freelist is empty
--44156:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux
--44156:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab
--44156:0: aspacem (2,108,3) /usr/lib64/ld-2.17.so
--44156:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed
--44156:0: aspacem 1: file 0000400000-00008adfff 4907008 r-x-- d=0xfd00 i=712737 o=0 (1,67)
--44156:0: aspacem 2: RSVN 00008ae000-0000aacfff 2093056 ----- SmFixed
--44156:0: aspacem 3: file 0000aad000-0000ab1fff 20480 rw--- d=0xfd00 i=712737 o=4902912 (1,67)
--44156:0: aspacem 4: anon 0000ab2000-0078832fff 1917m rw---
--44156:0: aspacem 5: file 0078833000-0078852fff 131072 r-x-- d=0xfd00 i=201446298 o=0 (2,108)
--44156:0: aspacem 6: 0078853000-0078a52fff 2097152
--44156:0: aspacem 7: file 0078a53000-0078a54fff 8192 rw--- d=0xfd00 i=201446298 o=131072 (2,108)
--44156:0: aspacem 8: 0078a55000-007cffffff 69m
--44156:0: aspacem 9: FILE 007d000000-007d27cfff 2609152 r-x-- d=0xfd02 i=2648346 o=0 (0,4)
--44156:0: aspacem 10: 007d27d000-007d47cfff 2097152
--44156:0: aspacem 11: FILE 007d47d000-007d47ffff 12288 rw--- d=0xfd02 i=2648346 o=2609152 (0,4)
--44156:0: aspacem 12: ANON 007d480000-007ee81fff 26m rw---
--44156:0: aspacem 13: 007ee82000-1001ffffff 63537m
--44156:0: aspacem 14: RSVN 1002000000-1002000fff 4096 ----- SmFixed
--44156:0: aspacem 15: ANON 1002001000-1002400fff 4194304 rwx--
--44156:0: aspacem 16: 1002401000-1fffffffff 65499m
--44156:0: aspacem 17: RSVN 2000000000-7ffe2448efff 130936g ----- SmFixed
--44156:0: aspacem 18: ANON 7ffe2448f000-7ffe244b0fff 139264 rw---
--44156:0: aspacem 19: RSVN 7ffe244b1000-7ffe24527fff 487424 ----- SmFixed
--44156:0: aspacem 20: ANON 7ffe24528000-7ffe24529fff 8192 r-x--
--44156:0: aspacem 21: RSVN 7ffe2452a000-ffffffffff5fffff 16383e ----- SmFixed
--44156:0: aspacem 22: ANON ffffffffff600000-ffffffffff600fff 4096 r-x--
--44156:0: aspacem 23: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed
--44156:0: aspacem >>>
--44156:0: ume mmap_anon_fixed_client #2
--44156:0: aspacem <<< SHOW_SEGMENTS: after #2 (25 segments)
--44156:0: aspacem 3 segment names in 3 slots
--44156:0: aspacem freelist is empty
--44156:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux
--44156:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab
--44156:0: aspacem (2,108,3) /usr/lib64/ld-2.17.so
--44156:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed
--44156:0: aspacem 1: file 0000400000-00008adfff 4907008 r-x-- d=0xfd00 i=712737 o=0 (1,67)
--44156:0: aspacem 2: RSVN 00008ae000-0000aacfff 2093056 ----- SmFixed
--44156:0: aspacem 3: file 0000aad000-0000ab1fff 20480 rw--- d=0xfd00 i=712737 o=4902912 (1,67)
--44156:0: aspacem 4: anon 0000ab2000-0078832fff 1917m rw---
--44156:0: aspacem 5: file 0078833000-0078852fff 131072 r-x-- d=0xfd00 i=201446298 o=0 (2,108)
--44156:0: aspacem 6: 0078853000-0078a52fff 2097152
--44156:0: aspacem 7: file 0078a53000-0078a54fff 8192 rw--- d=0xfd00 i=201446298 o=131072 (2,108)
--44156:0: aspacem 8: anon 0078a55000-0078a55fff 4096 rw---
--44156:0: aspacem 9: 0078a56000-007cffffff 69m
--44156:0: aspacem 10: FILE 007d000000-007d27cfff 2609152 r-x-- d=0xfd02 i=2648346 o=0 (0,4)
--44156:0: aspacem 11: 007d27d000-007d47cfff 2097152
--44156:0: aspacem 12: FILE 007d47d000-007d47ffff 12288 rw--- d=0xfd02 i=2648346 o=2609152 (0,4)
--44156:0: aspacem 13: ANON 007d480000-007ee81fff 26m rw---
--44156:0: aspacem 14: 007ee82000-1001ffffff 63537m
--44156:0: aspacem 15: RSVN 1002000000-1002000fff 4096 ----- SmFixed
--44156:0: aspacem 16: ANON 1002001000-1002400fff 4194304 rwx--
--44156:0: aspacem 17: 1002401000-1fffffffff 65499m
--44156:0: aspacem 18: RSVN 2000000000-7ffe2448efff 130936g ----- SmFixed
--44156:0: aspacem 19: ANON 7ffe2448f000-7ffe244b0fff 139264 rw---
--44156:0: aspacem 20: RSVN 7ffe244b1000-7ffe24527fff 487424 ----- SmFixed
--44156:0: aspacem 21: ANON 7ffe24528000-7ffe24529fff 8192 r-x--
--44156:0: aspacem 22: RSVN 7ffe2452a000-ffffffffff5fffff 16383e ----- SmFixed
--44156:0: aspacem 23: ANON ffffffffff600000-ffffffffff600fff 4096 r-x--
--44156:0: aspacem 24: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed
--44156:0: aspacem >>>
==44156== Memcheck, a memory error detector
==44156== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==44156== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==44156== Command: /u/wh/rel/ifaplrel/pw_fwp_engine.eab
==44156==
==44156== Warning: set address range perms: large range [0xab2000, 0x78833000) (defined)
==44156== Thread 2 FDP_MRP_Recover_:
==44156== Invalid write of size 4
==44156== at 0x78BB33: system__stack_usage__fill_stack (in /u/wh/rel/ifaplrel/pw_fwp_engine.eab)
==44156== by 0x75C49B: system__tasking__stages__task_wrapper (in /u/wh/rel/ifaplrel/pw_fwp_engine.eab)
==44156== by 0x79E1CDC4: start_thread (in /usr/lib64/libpthread-2.17.so)
==44156== by 0x7ADCC76C: clone (in /usr/lib64/libc-2.17.so)
==44156== Address 0x78972a08 is on thread 2's stack
==44156== 272 bytes below stack pointer
==44156==
Any further hints?
Thanks,
João M. S. Silva
> -----Original Message-----
> From: Silva João
> Sent: 1 de dezembro de 2017 14:43
> To: 'Ivo Raisr' <iv...@iv...>
> Cc: 'Valgrind Users' <val...@li...>
> Subject: RE: [Valgrind-users] failed in UME with error 22
>
> Also, is there a way to force correct compilation when I change the .ac
> file?
>
> Because I need to make clean and make again to make this change
> effective.
>
> I tried ./configure --enable-maintenance-mode but without success. It
> seems the makefile ignores the fact that the .ac was changed.
>
> Yes, I am running autogen.sh and then configure.sh before running make.
>
> João M. S. Silva
>
>
> > -----Original Message-----
> > From: Silva João
> > Sent: 1 de dezembro de 2017 13:06
> > To: 'Ivo Raisr' <iv...@iv...>
> > Cc: Valgrind Users <val...@li...>
> > Subject: RE: [Valgrind-users] failed in UME with error 22
> >
> > > Oh, have a look here where segment 3. has been created and listed in
> > > the second SHOW_SEGMENTS output.
> >
> > OK. It seems to change position sometimes, it's now in 6:
> >
> > --63000:0: aspacem 6: FILE 0077000000-0077235fff 2318336 r-x--
> > d=0xfd02 i=25256897 o=0 (0,4)
> >
> > I have set valt_load_address_pri_norml="0x80000000" but it's too much,
> > it cannot build:
> >
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1405:(.text+0x8df): relocation
> truncated
> > to fit: R_X86_64_32S against `.bss'
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1411:(.text+0x90b): relocation
> truncated
> > to fit: R_X86_64_32S against `.bss'
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1415:(.text+0x927): relocation
> truncated
> > to fit: R_X86_64_32S against `.bss'
> > memcheck_amd64_linux-mc_leakcheck.o: In function `lc_scan_memory':
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1154:(.text+0x128f): relocation
> truncated
> > to fit: R_X86_64_32S against `.rodata'
> > memcheck_amd64_linux-mc_leakcheck.o: In function `print_results':
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1511:(.text+0x18a5): relocation
> truncated
> > to fit: R_X86_64_32S against `.bss'
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1512:(.text+0x18ac): relocation
> truncated
> > to fit: R_X86_64_32S against `.bss'
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1514:(.text+0x18bf): relocation
> truncated
> > to fit: R_X86_64_32S against `.bss'
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1515:(.text+0x18c6): relocation
> truncated
> > to fit: R_X86_64_32S against `.bss'
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1564:(.text+0x1a46): relocation
> truncated
> > to fit: R_X86_64_32S against `.bss'
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1565:(.text+0x1a4e): relocation
> truncated
> > to fit: R_X86_64_32S against `.bss'
> > /home/AltranUK/jsilva.fs/src/valgrind-
> > 3.13.0/memcheck/mc_leakcheck.c:1641:(.text+0x1b5d): additional
> > relocation overflows omitted from the output
> > collect2: error: ld returned 1 exit status
> >
> > I've tried 0x77000000 but it's not enough for the program BSS.
> >
> > I'll have to try intermediate values.
> >
> > João M. S. Silva
|
|
From: Ivo R. <iv...@iv...> - 2017-12-05 11:43:48
|
2017-12-05 11:42 GMT+01:00 Silva João <joa...@al...>: > Hi, > > I was able to build Valgrind and run the program with value 0x7d000000: > > valt_load_address_pri_norml="0x7d000000" > valt_load_address_pri_norml="0x7d000000" > valt_load_address_pri_norml="0x7d000000" > valt_load_address_sec_norml="0x7d000000" > > In order for this parameter in the .ac file to take effect I found out than reapplying the patch you sent forces make to rebuild the executable correctly (otherwise the change gets ignored, probably a bug in Valgrind configure.sh or makefile). Are you running ./autogen.sh && ./configure so that changes from configure.ac get in effect? You can also do 'make distclean' before './autogen.sh && ./configure' so as to clean up everything. > Now I get this, not sure whether the problem is real or comes from having tweaked valt_load_address_*_norml: ... > --44156:0: aspacem <<< SHOW_SEGMENTS: after #2 (25 segments) > --44156:0: aspacem 3 segment names in 3 slots > --44156:0: aspacem freelist is empty > --44156:0: aspacem (0,4,3) /home/AltranUK/jsilva.fs/lib/valgrind/memcheck-amd64-linux > --44156:0: aspacem (1,67,3) /u/wh/rel/ifaplrel/pw_fwp_engine.eab > --44156:0: aspacem (2,108,3) /usr/lib64/ld-2.17.so > --44156:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed > --44156:0: aspacem 1: file 0000400000-00008adfff 4907008 r-x-- d=0xfd00 i=712737 o=0 (1,67) > --44156:0: aspacem 2: RSVN 00008ae000-0000aacfff 2093056 ----- SmFixed > --44156:0: aspacem 3: file 0000aad000-0000ab1fff 20480 rw--- d=0xfd00 i=712737 o=4902912 (1,67) > --44156:0: aspacem 4: anon 0000ab2000-0078832fff 1917m rw--- > --44156:0: aspacem 5: file 0078833000-0078852fff 131072 r-x-- d=0xfd00 i=201446298 o=0 (2,108) > --44156:0: aspacem 6: 0078853000-0078a52fff 2097152 > --44156:0: aspacem 7: file 0078a53000-0078a54fff 8192 rw--- d=0xfd00 i=201446298 o=131072 (2,108) > --44156:0: aspacem 8: anon 0078a55000-0078a55fff 4096 rw--- > --44156:0: aspacem 9: 0078a56000-007cffffff 69m > --44156:0: aspacem 10: FILE 007d000000-007d27cfff 2609152 r-x-- d=0xfd02 i=2648346 o=0 (0,4) > --44156:0: aspacem 11: 007d27d000-007d47cfff 2097152 > --44156:0: aspacem 12: FILE 007d47d000-007d47ffff 12288 rw--- d=0xfd02 i=2648346 o=2609152 (0,4) > --44156:0: aspacem 13: ANON 007d480000-007ee81fff 26m rw--- > --44156:0: aspacem 14: 007ee82000-1001ffffff 63537m > --44156:0: aspacem 15: RSVN 1002000000-1002000fff 4096 ----- SmFixed > --44156:0: aspacem 16: ANON 1002001000-1002400fff 4194304 rwx-- > --44156:0: aspacem 17: 1002401000-1fffffffff 65499m > --44156:0: aspacem 18: RSVN 2000000000-7ffe2448efff 130936g ----- SmFixed > --44156:0: aspacem 19: ANON 7ffe2448f000-7ffe244b0fff 139264 rw--- > --44156:0: aspacem 20: RSVN 7ffe244b1000-7ffe24527fff 487424 ----- SmFixed > --44156:0: aspacem 21: ANON 7ffe24528000-7ffe24529fff 8192 r-x-- > --44156:0: aspacem 22: RSVN 7ffe2452a000-ffffffffff5fffff 16383e ----- SmFixed > --44156:0: aspacem 23: ANON ffffffffff600000-ffffffffff600fff 4096 r-x-- > --44156:0: aspacem 24: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed > --44156:0: aspacem >>> > ==44156== Memcheck, a memory error detector > ==44156== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==44156== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info > ==44156== Command: /u/wh/rel/ifaplrel/pw_fwp_engine.eab > ==44156== > ==44156== Warning: set address range perms: large range [0xab2000, 0x78833000) (defined) This is expected due to ~1,7 GB of BSS (see segment 4.). > ==44156== Thread 2 FDP_MRP_Recover_: > ==44156== Invalid write of size 4 > ==44156== at 0x78BB33: system__stack_usage__fill_stack (in /u/wh/rel/ifaplrel/pw_fwp_engine.eab) > ==44156== by 0x75C49B: system__tasking__stages__task_wrapper (in /u/wh/rel/ifaplrel/pw_fwp_engine.eab) > ==44156== by 0x79E1CDC4: start_thread (in /usr/lib64/libpthread-2.17.so) > ==44156== by 0x7ADCC76C: clone (in /usr/lib64/libc-2.17.so) > ==44156== Address 0x78972a08 is on thread 2's stack > ==44156== 272 bytes below stack pointer This is probably a valid complaint. Does the program complete afterwards? To check for that problem, start Valgrind with vgdb enabled as per: http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver Assuming this problem is the first one reported, pass "--vgdb-error=1". After gdb stops on encountering that particular problem, print the Valgrind address space layout (SEGMENTS) with: (gdb) monitor v.info memory [aspacemgr] (as per http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.valgrind-monitor-commands) Also print the registers, in particular stack pointer (rsp) and the function disassembly (disas in gdb). You can either correlate this output by yourself or post it here. Good luck! I. P.S. I would rather double check again why pw_fwp_engine.eab is allocating such as huge BSS segment. That executable is quite a tiny one (approx 4MB file size)? |
|
From: Silva J. <joa...@al...> - 2017-12-05 15:42:15
|
> Are you running ./autogen.sh && ./configure so that changes from > configure.ac get in effect? > You can also do 'make distclean' before './autogen.sh && ./configure' > so as to clean up everything. Yes, I am but it doesn't work. I guess this might be a bug in configure or the makefile? Running make clean requires to build everything again, which takes some minutes. > > ==44156== Thread 2 FDP_MRP_Recover_: > > ==44156== Invalid write of size 4 > > ==44156== at 0x78BB33: system__stack_usage__fill_stack (in > /u/wh/rel/ifaplrel/pw_fwp_engine.eab) > > ==44156== by 0x75C49B: system__tasking__stages__task_wrapper (in > /u/wh/rel/ifaplrel/pw_fwp_engine.eab) > > ==44156== by 0x79E1CDC4: start_thread (in /usr/lib64/libpthread- > 2.17.so) > > ==44156== by 0x7ADCC76C: clone (in /usr/lib64/libc-2.17.so) > > ==44156== Address 0x78972a08 is on thread 2's stack > > ==44156== 272 bytes below stack pointer > > This is probably a valid complaint. > Does the program complete afterwards? It does not stop, but seems to stay in a "numb" state. But if running outside of Valgrind it seems to run OK. > To check for that problem, start Valgrind with vgdb enabled as per: > Assuming this problem is the first one reported, pass "--vgdb-error=1". > > After gdb stops on encountering that particular problem, print the > Valgrind address space layout (SEGMENTS) with: > (gdb) monitor v.info memory [aspacemgr] > > Also print the registers, in particular stack pointer (rsp) and the > function disassembly (disas in gdb). > > You can either correlate this output by yourself or post it here. These are the results: (gdb) monitor v.info memory 2,110,115,840 bytes have already been mmap-ed ANONYMOUS. --50867-- core : 8,388,608/ 8,388,608 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 3,927,928/ 3,804,944 max/curr, 23732/ 29302048 totalloc-blocks/bytes, 23720 searches 8 rzB --50867-- dinfo : 26,296,320/ 19,283,968 max/curr mmap'd, 2/15 unsplit/split sb unmmap'd, 25,664,864/ 16,859,824 max/curr, 331843/ 102928896 totalloc-blocks/bytes, 346351 searches 8 rzB --50867-- client : 4,194,304/ 4,194,304 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 1,738,032/ 1,738,032 max/curr, 11/ 1738032 totalloc-blocks/bytes, 10 searches 24 rzB --50867-- demangle: 65,536/ 65,536 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 800/ 544 max/curr, 24/ 3584 totalloc-blocks/bytes, 23 searches 8 rzB --50867-- ttaux : 221,184/ 221,184 max/curr mmap'd, 0/1 unsplit/split sb unmmap'd, 167,616/ 115,584 max/curr, 695/ 306496 totalloc-blocks/bytes, 694 searches 8 rzB (gdb) monitor v.info memory aspacemgr 2,110,115,840 bytes have already been mmap-ed ANONYMOUS. --50867-- core : 8,388,608/ 8,388,608 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 3,927,928/ 3,804,944 max/curr, 23747/ 29435632 totalloc-blocks/bytes, 23735 searches 8 rzB --50867-- dinfo : 26,296,320/ 19,283,968 max/curr mmap'd, 2/15 unsplit/split sb unmmap'd, 25,664,864/ 16,859,824 max/curr, 331843/ 102928896 totalloc-blocks/bytes, 346351 searches 8 rzB --50867-- client : 4,194,304/ 4,194,304 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 1,738,032/ 1,738,032 max/curr, 11/ 1738032 totalloc-blocks/bytes, 10 searches 24 rzB --50867-- demangle: 65,536/ 65,536 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 800/ 544 max/curr, 24/ 3584 totalloc-blocks/bytes, 23 searches 8 rzB --50867-- ttaux : 221,184/ 221,184 max/curr mmap'd, 0/1 unsplit/split sb unmmap'd, 167,616/ 115,584 max/curr, 695/ 306496 totalloc-blocks/bytes, 694 searches 8 rzB (gdb) p $rsp $1 = (access void) 0x78972b18 (gdb) disas Dump of assembler code for function system__stack_usage__fill_stack: 0x000000000078bae0 <+0>: movslq 0x2c(%rdi),%rdx 0x000000000078bae4 <+4>: mov 0x20(%rdi),%rsi 0x000000000078bae8 <+8>: lea -0xc(%rsp),%r8 0x000000000078baed <+13>: mov %rsi,%rcx 0x000000000078baf0 <+16>: sub %rdx,%rcx 0x000000000078baf3 <+19>: mov %rdx,%rax 0x000000000078baf6 <+22>: lea -0x10c(%rsp),%rdx 0x000000000078bafe <+30>: cmp %rdx,%rcx 0x000000000078bb01 <+33>: ja 0x78bb40 <system__stack_usage__fill_stack+96> 0x000000000078bb03 <+35>: cmp %rdx,%rsi 0x000000000078bb06 <+38>: mov %rcx,0x38(%rdi) 0x000000000078bb0a <+42>: jbe 0x78bb18 <system__stack_usage__fill_stack+56> 0x000000000078bb0c <+44>: lea -0x100(%r8),%eax 0x000000000078bb13 <+51>: sub %ecx,%eax 0x000000000078bb15 <+53>: mov %eax,0x2c(%rdi) 0x000000000078bb18 <+56>: lea 0x3(%rax),%edx 0x000000000078bb1b <+59>: test %eax,%eax 0x000000000078bb1d <+61>: mov %rcx,0x48(%rdi) 0x000000000078bb21 <+65>: cmovns %eax,%edx 0x000000000078bb24 <+68>: sar $0x2,%edx 0x000000000078bb27 <+71>: test %edx,%edx 0x000000000078bb29 <+73>: movslq %edx,%rax 0x000000000078bb2c <+76>: jle 0x78bb3d <system__stack_usage__fill_stack+93> 0x000000000078bb2e <+78>: xchg %ax,%ax 0x000000000078bb30 <+80>: mov 0x30(%rdi),%edx => 0x000000000078bb33 <+83>: mov %edx,-0x4(%rcx,%rax,4) 0x000000000078bb37 <+87>: sub $0x1,%rax 0x000000000078bb3b <+91>: jne 0x78bb30 <system__stack_usage__fill_stack+80> 0x000000000078bb3d <+93>: retq 0x000000000078bb3e <+94>: xchg %ax,%ax 0x000000000078bb40 <+96>: movl $0x0,0x2c(%rdi) 0x000000000078bb47 <+103>: retq End of assembler dump. I've never gone so deep in analyzing Valgrind's output, so this is a bit unknown to me :P > P.S. I would rather double check again why pw_fwp_engine.eab is > allocating such as huge BSS segment. That executable is quite a tiny > one (approx 4MB file size)? It's from what I said before: in this program all memory is allocated statically. No dynamic memory allocation is allowed. This, in Ada/SPARK. The C/C++ parts, which relate to the utilization of libxerces may use dynamic memory. This is the part we want to analyze. So every bit of memory that the program needs is allocated from the beginning. For instance, the arrays are allocated with the worst case length. João M. S. Silva |
|
From: Philippe W. <phi...@sk...> - 2017-12-05 19:15:38
|
On Tue, 2017-12-05 at 15:41 +0000, Silva João wrote: > > > ==44156== Thread 2 FDP_MRP_Recover_: > > > ==44156== Invalid write of size 4 > > > ==44156== at 0x78BB33: system__stack_usage__fill_stack (in > > > > /u/wh/rel/ifaplrel/pw_fwp_engine.eab) > > > ==44156== by 0x75C49B: system__tasking__stages__task_wrapper (in > > > > /u/wh/rel/ifaplrel/pw_fwp_engine.eab) > > > ==44156== by 0x79E1CDC4: start_thread (in /usr/lib64/libpthread- > > > > 2.17.so) > > > ==44156== by 0x7ADCC76C: clone (in /usr/lib64/libc-2.17.so) > > > ==44156== Address 0x78972a08 is on thread 2's stack > > > ==44156== 272 bytes below stack pointer > > > > This is probably a valid complaint. The above error is triggered because you are using the gnat 'used stack' measurement package. This package 'paints' the stack to see what has been consumed. It paints more than the program really uses (of course :), and so it is completely normal that memcheck reports an error. > > Does the program complete afterwards? > > It does not stop, but seems to stay in a "numb" state. > > But if running outside of Valgrind it seems to run OK. > > > To check for that problem, start Valgrind with vgdb enabled as per: > > Assuming this problem is the first one reported, pass "--vgdb-error=1". As discussed above, the error 'looks' normal, and should IMO be ignored (you might want to disable the stack measurement functionality). To see why your program is blocked, use vgdb as suggested by Ivo. Then do 'info task' to see the status of the Ada tasks, and if they are blocked, and on what. As you are using Ada/SPARK, I guess you use a special tasking profile (e.g. ravenscar or similar). I have no idea how such tasking profile interacts with the single thread at a time model of Valgrind. You might try --fair-sched=yes to see if that helps. Also, try also --tool=none, just to see if the problem/blockage status is linked to memcheck, or to the valgrind scheduling and Ada/SPARK interaction. Philippe |
|
From: Silva J. <joa...@al...> - 2017-12-06 13:00:28
|
Thanks. > The above error is triggered because you are using the gnat 'used stack' > measurement package. This package 'paints' the stack to see what has > been consumed. It paints more than the program really uses (of course > :), > and so it is completely normal that memcheck reports an error. OK, I have removed switch -fstack-usage and the error vanished. > As discussed above, the error 'looks' normal, and should IMO be ignored > (you might want to disable the stack measurement functionality). > > To see why your program is blocked, use vgdb as suggested by Ivo. > Then do 'info task' to see the status of the Ada tasks, and if they > are blocked, and on what. From info task, all tasks are in "Runnable" state. There are 39 in this list. From gdb the program seems blocked reading a file (libc read()). But when I list (l) in gdb it does not show the correct line. It seems the synchronization with the source file is not correct. > As you are using Ada/SPARK, I guess you use a special tasking profile > (e.g. ravenscar or similar). I have no idea how such tasking profile > interacts with the single thread at a time model of Valgrind. > > You might try --fair-sched=yes to see if that helps. I tried but without success. > Also, try also --tool=none, just to see if the problem/blockage status > is linked to memcheck, or to the valgrind scheduling and Ada/SPARK > interaction. With nulgrind it still "hangs" so I seems related to the tread issue you mention. João M. S. Silva |
|
From: Philippe W. <phi...@sk...> - 2017-12-06 18:29:23
|
On Wed, 2017-12-06 at 13:00 +0000, Silva João wrote: > From info task, all tasks are in "Runnable" state. There are 39 in this list. > > From gdb the program seems blocked reading a file (libc read()). If you have 39 tasks in Runnable state, I guess that they are not all blocked in libc read ? So, you might investigate which task(s) are really still doing something by doing e.g. thread apply all bt and/or put breakpoints at places that you know should be soon encountered by the runnable tasks and continue the execution. And then control-c, and redo the above to see if some tasks are/have still progressed. Also, from gdb, you can do monitor v.info scheduler to have the valgrind status of the tasks/threads. You can also use the option --trace-sched=yes to see how and if valgrind still schedules the threads. Note that at my work, we are using valgrind + Ada tasks without any particular problem. > > But when I list (l) in gdb it does not show the correct line. It seems the synchronization with the source file is not correct. > > > As you are using Ada/SPARK, I guess you use a special tasking profile > > (e.g. ravenscar or similar). I have no idea how such tasking profile > > interacts with the single thread at a time model of Valgrind. > > > > You might try --fair-sched=yes to see if that helps. > > I tried but without success. > > > Also, try also --tool=none, just to see if the problem/blockage status > > is linked to memcheck, or to the valgrind scheduling and Ada/SPARK > > interaction. > > With nulgrind it still "hangs" so I seems related to the tread issue you mention. Possibly also, the change in the way the threads are scheduled causes an application deadlock. You might thus also try --tool=helgrind just in case this would reveal some non thread safe bug ... Philippe |
|
From: Silva J. <joa...@al...> - 2017-12-07 12:40:10
|
> If you have 39 tasks in Runnable state, I guess that they are not all > blocked in libc read ? > So, you might investigate which task(s) are really still doing something > by doing e.g. > thread apply all bt > and/or put breakpoints at places that you know should be soon > encountered > by the runnable tasks and continue the execution. > And then control-c, and redo the above to see if some tasks are/have > still > progressed. > > Also, from gdb, you can do > monitor v.info scheduler > to have the valgrind status of the tasks/threads. Thanks for the commands. All 38 threads are waiting on the 1st one (pthread_cond_wait). The first one is blocked on the file read. > You can also use the option --trace-sched=yes to see how and if valgrind > still schedules the threads. > > Note that at my work, we are using valgrind + Ada tasks without > any particular problem. The trace-sched option produces a lot of output continuously: --20282-- SCHED[1]: releasing lock (VG_(scheduler):timeslice) -> VgTs_Yielding --20282-- SCHED[1]: acquired lock (VG_(scheduler):timeslice) --20282-- SCHED[1]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys --20282-- SCHED[1]: acquired lock (VG_(client_syscall)[async]) > Possibly also, the change in the way the threads are scheduled causes an > application deadlock. > > You might thus also try --tool=helgrind just in case this would reveal > some > non thread safe bug ... There seems to be some thread errors like: Lock at 0xD92BC0 was first observed Possible data race during read of size 8 at 0x7B459FD8 by thread #1 This conflicts with a previous write of size 8 by thread #2 Or can these be false positives? João M. S. Silva |
|
From: Philippe W. <phi...@sk...> - 2017-12-07 19:40:00
|
On Thu, 2017-12-07 at 12:39 +0000, Silva João wrote: > > If you have 39 tasks in Runnable state, I guess that they are not all > > blocked in libc read ? > > So, you might investigate which task(s) are really still doing something > > by doing e.g. > > thread apply all bt > > and/or put breakpoints at places that you know should be soon > > encountered > > by the runnable tasks and continue the execution. > > And then control-c, and redo the above to see if some tasks are/have > > still > > progressed. > > > > Also, from gdb, you can do > > monitor v.info scheduler > > to have the valgrind status of the tasks/threads. > > Thanks for the commands. > > All 38 threads are waiting on the 1st one (pthread_cond_wait). The first one is blocked on the file read. Then you have to understand what this task is doing. Isn't the backtrace pointing at what the code is doing and what this read could be ? Look at the file descriptor on which it is reading and see what this fd is ? Is it a real file ? (unlikely to be blocking then) Is it a pipe ? A tcp/ip connection ? Use lsof if you cannot determine in gdb what this fd is for. And then you have to guess why this read does not return. > > > You can also use the option --trace-sched=yes to see how and if valgrind > > still schedules the threads. > > > > Note that at my work, we are using valgrind + Ada tasks without > > any particular problem. > > The trace-sched option produces a lot of output continuously: > > --20282-- SCHED[1]: releasing lock (VG_(scheduler):timeslice) -> VgTs_Yielding > --20282-- SCHED[1]: acquired lock (VG_(scheduler):timeslice) > --20282-- SCHED[1]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys > --20282-- SCHED[1]: acquired lock (VG_(client_syscall)[async]) This shows that on valgrind side, task 1 is not blocked and valgrind still let it run.. Now, you might understand what is happening with the above suggestions (gdb backtrace, lsof, ...). If the above does not clarify, you might learn more/have a hint by adding --trace-syscalls=yes --trace-signals=yes You might also compare the syscalls executed natively and under valgrind by using strace. In this comparison, you will have to take into account that valgrind changes the way threads are scheduled, and valgrind introduces some syscalls for its own internal kitchen. So, the comparison is not mechanical ... > > > Possibly also, the change in the way the threads are scheduled causes an > > application deadlock. > > > > You might thus also try --tool=helgrind just in case this would reveal > > some > > non thread safe bug ... > > There seems to be some thread errors like: > > Lock at 0xD92BC0 was first observed > Possible data race during read of size 8 at 0x7B459FD8 by thread #1 > This conflicts with a previous write of size 8 by thread #2 > > Or can these be false positives? This can be false positive of course, and of course, this can be a true positive :). With only an address, no access to the code, no backtrace, no reproducer, there is not much feedback we can give. Let me just tell that at my work, we have added for helgrind a few suppression entries related to the 'low level implementation of the gnat runtime', to suppress false positive created by the low level inner working of the runtime. To see what you case is, the minimum needed would be the stack traces of the error msg. In summary, at this point, it looks like you have to debug your application when running under valgrind, and then you might determine if what you see is a real application bug, or a valgrind bug/limitation e.g. in the valgrind scheduler/signal handling/syscall handling or whatever. At this state, without further info, let's assume you have an application bug :) Philippe |
|
From: Silva J. <joa...@al...> - 2017-12-10 21:10:05
|
Then you have to understand what this task is doing. Isn't the backtrace pointing at what the code is doing and what this read could be ? Look at the file descriptor on which it is reading and see what this fd is ? Is it a real file ? (unlikely to be blocking then) Is it a pipe ? A tcp/ip connection ? Use lsof if you cannot determine in gdb what this fd is for. [JMSS] It's a file. After I added some prints for debugging, the main thread seem to get unblocked (?) This can be false positive of course, and of course, this can be a true positive :). With only an address, no access to the code, no backtrace, no reproducer, there is not much feedback we can give. Let me just tell that at my work, we have added for helgrind a few suppression entries related to the 'low level implementation of the gnat runtime', to suppress false positive created by the low level inner working of the runtime. To see what you case is, the minimum needed would be the stack traces of the error msg. In summary, at this point, it looks like you have to debug your application when running under valgrind, and then you might determine if what you see is a real application bug, or a valgrind bug/limitation e.g. in the valgrind scheduler/signal handling/syscall handling or whatever. At this state, without further info, let's assume you have an application bug :) [JMSS] Yes, I think that we are now able to debug the application. It seems to run under nulgrind, helgrind and memcheck, so it should be "good" to go. [JMSS] I'll try to provide the patch for the configuration now. João M. S. Silva |
|
From: SILVA J. <joa...@al...> - 2018-02-26 21:52:58
|
Hi again,
Our program now seems to have enlarged and now occupies:
valgrind: mmap(0xa2d000, 2154274816) failed in UME with error 22 (Invalid argument).
valgrind: this can be caused by executables with very large text, data or bss segments.
However, I cannot relocate it anymore:
$ grep 0x7f000000 configure.ac
valt_load_address_pri_norml="0x7f000000"
valt_load_address_pri_norml="0x7f000000"
valt_load_address_pri_norml="0x7f000000"
valt_load_address_pri_norml="0x7f000000"
valt_load_address_sec_norml="0x7f000000"
This value, 0x7f000000, is too much:
../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_mallocfree.o): In function `sanity_check_malloc_arena':
/home/AltranUK/jsilva.fs/src/valgrind/coregrind/m_mallocfree.c:1321:(.text+0xe19): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[3]: *** [memcheck-amd64-linux] Error 1
Is there an alternative to create more space for the program?
Thanks.
João M. S. Silva
> -----Original Message-----
> From: Silva João
> Sent: 10 de dezembro de 2017 21:10
> To: Philippe Waroquiers <phi...@sk...>; Ivo Raisr
> <iv...@iv...>
> Cc: Valgrind Users <val...@li...>
> Subject: RE: [Valgrind-users] failed in UME with error 22
>
> Then you have to understand what this task is doing.
> Isn't the backtrace pointing at what the code is doing and what this
> read could be ?
> Look at the file descriptor on which it is reading and see what this fd
> is ?
> Is it a real file ? (unlikely to be blocking then)
> Is it a pipe ? A tcp/ip connection ?
> Use lsof if you cannot determine in gdb what this fd is for.
>
> [JMSS] It's a file. After I added some prints for debugging, the main
> thread seem to get unblocked (?)
>
> This can be false positive of course, and of course, this can be a true
> positive :).
> With only an address, no access to the code, no backtrace, no
> reproducer,
> there is not much feedback we can give.
>
> Let me just tell that at my work, we have added for helgrind a few
> suppression
> entries related to the 'low level implementation of the gnat runtime',
> to
> suppress false positive created by the low level inner working of the
> runtime.
>
> To see what you case is, the minimum needed would be the stack traces of
> the error msg.
>
> In summary, at this point, it looks like you have to debug your
> application
> when running under valgrind, and then you might determine if what you
> see
> is a real application bug, or a valgrind bug/limitation e.g. in the
> valgrind
> scheduler/signal handling/syscall handling or whatever.
>
> At this state, without further info, let's assume you have
> an application bug :)
>
> [JMSS] Yes, I think that we are now able to debug the application. It
> seems to run under nulgrind, helgrind and memcheck, so it should be
> "good" to go.
>
> [JMSS] I'll try to provide the patch for the configuration now.
>
> João M. S. Silva
|
|
From: Philippe W. <phi...@sk...> - 2018-02-22 06:33:36
|
I would suggest to stop doing such huge static allocations,
and replace these huge static allocations by dynamic allocation
done at elaboration time.
This should give you several benefits:
* you should be able to run under Valgrind without the below problems
* you will get additional verifications/safety net when running under
valgrind, as valgrind does not check static data as well as
dynamic data.
* you can at startup decide on how much memory you use, without the need
to recompile.
If your coding standard strictly forbids dynamic allocation even at elaboration
time, then use e.g. gnatprep to have 2 modes:
* a static data version
* a dynamic version
(the changes to switch between the 2 versions should be limited to the
variable declarations, thanks to the compiler using implicit .all
Apart of the above, I have no idea what the below linker error means,
and how to fix it.
Philippe
On Wed, 2018-02-21 at 12:11 +0000, SILVA João wrote:
> Hi again,
>
> Our program now seems to have enlarged and now occupies:
>
> valgrind: mmap(0xa2d000, 2154274816) failed in UME with error 22 (Invalid argument).
> valgrind: this can be caused by executables with very large text, data or bss segments.
>
> However, I cannot relocate it anymore:
>
> $ grep 0x7f000000 configure.ac
> valt_load_address_pri_norml="0x7f000000"
> valt_load_address_pri_norml="0x7f000000"
> valt_load_address_pri_norml="0x7f000000"
> valt_load_address_pri_norml="0x7f000000"
> valt_load_address_sec_norml="0x7f000000"
>
> This value, 0x7f000000, is too much:
>
> ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_mallocfree.o): In function `sanity_check_malloc_arena':
> /home/AltranUK/jsilva.fs/src/valgrind/coregrind/m_mallocfree.c:1321:(.text+0xe19): additional relocation overflows omitted from the output
> collect2: error: ld returned 1 exit status
> make[3]: *** [memcheck-amd64-linux] Error 1
>
> Is there an alternative to create more space for the program?
>
> Thanks.
>
> João M. S. Silva
>
> > -----Original Message-----
> > From: Silva João
> > Sent: 10 de dezembro de 2017 21:10
> > To: Philippe Waroquiers <phi...@sk...>; Ivo Raisr
> > <iv...@iv...>
> > Cc: Valgrind Users <val...@li...>
> > Subject: RE: [Valgrind-users] failed in UME with error 22
> >
> > Then you have to understand what this task is doing.
> > Isn't the backtrace pointing at what the code is doing and what this
> > read could be ?
> > Look at the file descriptor on which it is reading and see what this fd
> > is ?
> > Is it a real file ? (unlikely to be blocking then)
> > Is it a pipe ? A tcp/ip connection ?
> > Use lsof if you cannot determine in gdb what this fd is for.
> >
> > [JMSS] It's a file. After I added some prints for debugging, the main
> > thread seem to get unblocked (?)
> >
> > This can be false positive of course, and of course, this can be a true
> > positive :).
> > With only an address, no access to the code, no backtrace, no
> > reproducer,
> > there is not much feedback we can give.
> >
> > Let me just tell that at my work, we have added for helgrind a few
> > suppression
> > entries related to the 'low level implementation of the gnat runtime',
> > to
> > suppress false positive created by the low level inner working of the
> > runtime.
> >
> > To see what you case is, the minimum needed would be the stack traces of
> > the error msg.
> >
> > In summary, at this point, it looks like you have to debug your
> > application
> > when running under valgrind, and then you might determine if what you
> > see
> > is a real application bug, or a valgrind bug/limitation e.g. in the
> > valgrind
> > scheduler/signal handling/syscall handling or whatever.
> >
> > At this state, without further info, let's assume you have
> > an application bug :)
> >
> > [JMSS] Yes, I think that we are now able to debug the application. It
> > seems to run under nulgrind, helgrind and memcheck, so it should be
> > "good" to go.
> >
> > [JMSS] I'll try to provide the patch for the configuration now.
> >
> > João M. S. Silva
|
|
From: SILVA J. <joa...@al...> - 2018-02-23 18:55:10
|
The reason we allocate everything statically is safety. What about you, Ivo, any other hints on creating space for this executable? This seems a limitation of Valgrind, should I create a bug report? It's a software limit, while the limit should be the hardware, right? João M. S. Silva > -----Original Message----- > From: Philippe Waroquiers [mailto:phi...@sk...] > Sent: 22 de fevereiro de 2018 06:34 > To: SILVA João <joa...@al...>; Ivo Raisr <iv...@iv...> > Cc: Valgrind Users <val...@li...> > Subject: Re: [Valgrind-users] failed in UME with error 22 > > I would suggest to stop doing such huge static allocations, > and replace these huge static allocations by dynamic allocation > done at elaboration time. > This should give you several benefits: > * you should be able to run under Valgrind without the below problems > * you will get additional verifications/safety net when running under > valgrind, as valgrind does not check static data as well as > dynamic data. > * you can at startup decide on how much memory you use, without the > need > to recompile. > > If your coding standard strictly forbids dynamic allocation even at > elaboration > time, then use e.g. gnatprep to have 2 modes: > * a static data version > * a dynamic version > (the changes to switch between the 2 versions should be limited to the > variable declarations, thanks to the compiler using implicit .all > > > Apart of the above, I have no idea what the below linker error means, > and how to fix it. > > Philippe > > > On Wed, 2018-02-21 at 12:11 +0000, SILVA João wrote: > > Hi again, > > > > Our program now seems to have enlarged and now occupies: > > > > valgrind: mmap(0xa2d000, 2154274816) failed in UME with error 22 > (Invalid argument). > > valgrind: this can be caused by executables with very large text, data > or bss segments. > > > > However, I cannot relocate it anymore: > > > > $ grep 0x7f000000 configure.ac > > valt_load_address_pri_norml="0x7f000000" > > valt_load_address_pri_norml="0x7f000000" > > valt_load_address_pri_norml="0x7f000000" > > valt_load_address_pri_norml="0x7f000000" > > valt_load_address_sec_norml="0x7f000000" > > > > This value, 0x7f000000, is too much: > > > > ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > m_mallocfree.o): In function `sanity_check_malloc_arena': > > > /home/AltranUK/jsilva.fs/src/valgrind/coregrind/m_mallocfree.c:1321:(.te > xt+0xe19): additional relocation overflows omitted from the output > > collect2: error: ld returned 1 exit status > > make[3]: *** [memcheck-amd64-linux] Error 1 > > > > Is there an alternative to create more space for the program? > > > > Thanks. > > > > João M. S. Silva > > > > > -----Original Message----- > > > From: Silva João > > > Sent: 10 de dezembro de 2017 21:10 > > > To: Philippe Waroquiers <phi...@sk...>; Ivo Raisr > > > <iv...@iv...> > > > Cc: Valgrind Users <val...@li...> > > > Subject: RE: [Valgrind-users] failed in UME with error 22 > > > > > > Then you have to understand what this task is doing. > > > Isn't the backtrace pointing at what the code is doing and what this > > > read could be ? > > > Look at the file descriptor on which it is reading and see what this > fd > > > is ? > > > Is it a real file ? (unlikely to be blocking then) > > > Is it a pipe ? A tcp/ip connection ? > > > Use lsof if you cannot determine in gdb what this fd is for. > > > > > > [JMSS] It's a file. After I added some prints for debugging, the > main > > > thread seem to get unblocked (?) > > > > > > This can be false positive of course, and of course, this can be a > true > > > positive :). > > > With only an address, no access to the code, no backtrace, no > > > reproducer, > > > there is not much feedback we can give. > > > > > > Let me just tell that at my work, we have added for helgrind a few > > > suppression > > > entries related to the 'low level implementation of the gnat > runtime', > > > to > > > suppress false positive created by the low level inner working of > the > > > runtime. > > > > > > To see what you case is, the minimum needed would be the stack > traces of > > > the error msg. > > > > > > In summary, at this point, it looks like you have to debug your > > > application > > > when running under valgrind, and then you might determine if what > you > > > see > > > is a real application bug, or a valgrind bug/limitation e.g. in the > > > valgrind > > > scheduler/signal handling/syscall handling or whatever. > > > > > > At this state, without further info, let's assume you have > > > an application bug :) > > > > > > [JMSS] Yes, I think that we are now able to debug the application. > It > > > seems to run under nulgrind, helgrind and memcheck, so it should be > > > "good" to go. > > > > > > [JMSS] I'll try to provide the patch for the configuration now. > > > > > > João M. S. Silva |
|
From: Ivo R. <iv...@iv...> - 2018-02-23 19:42:35
|
2018-02-23 19:54 GMT+01:00 SILVA João <joa...@al...>: > The reason we allocate everything statically is safety. > > What about you, Ivo, any other hints on creating space for this executable? Unfortunately I have run out of ideas, I am sorry. > > This seems a limitation of Valgrind, should I create a bug report? It's a software limit, while the limit should be the hardware, right? Valgrind does many things to your application. Different virtual address memory organization is one of them. In short, V. has to squeeze application and Valgrind into one process' address space. I don't think the current design of aspacemgr could allow for the flexibility you need. Feel free to have a look, perhaps you will be able to come up with another idea. I. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X