Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(9) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
|
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 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: 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-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: Ivo R. <iv...@iv...> - 2017-12-01 05:33:54
|
We have extended the submission deadline for proposals until 6th December. Kind regards, Ivo Raisr 2017-10-13 12:37 GMT+02:00 Ivo Raisr <iv...@iv...>: > Debugging Tools developer room at FOSDEM 2018 > (Brussels, Belgium, February 3th). > > FOSDEM is a free software event that offers open source communities a > place to meet, share ideas and collaborate. It is renown for being > highly developer-oriented and brings together 5000+ hackers from all > over the world. It is held in the city of Brussels (Belgium). > http://fosdem.org/ > > FOSDEM 2018 will take place during the weekend of Saturday, February 3th > and Sunday February 4th 2018. On Saturday we will have a devroom for > Debugging Tools, jointly organized by the Valgrind and GDB projects. > Devrooms are a place for development teams to meet, discuss, hack and publicly > present the project's latest improvements and future directions. > > We will have a whole day to hang out together as community > embracing debugging tools, such as Valgrind, gdb, RR, Infinity, radare... > Please join us, regardless of whether you are a core hacker, > a plugin hacker, a user, a packager or a hacker on a > project that integrates, extends or complements debugging tools. > > ** Call for Participation > > We would like to organize a series of talks/discussions on various > topics relevant to both core hackers, new developers, users, packagers > and cross project functionality. Please do submit a talk proposal by > Friday December 1st 2017, so we can make a list of activities during the > day. > > Some possible topics for talks/discussions are: > > - The recently added functional changes (for users). > - Get feedback on what what kinds of new functionality would be > useful. Which tools and functionality users would like to see. > - Discuss release/bugfixing strategy/policy (core hackers, packagers). > - Connecting debugging tools together. > - Latest DWARF extensions, going from binary back to source. > - Multi, multi, multi... threads, processes and targets. > - Debugging anything, everywhere. Dealing with complex systems. > - Dealing with the dynamic loader and the kernel. > - Intercepting and interposing functions and events. > - Adding GDB features, such as designing GDB python scripts for your > data structures. > - Advances in gdbserver and the GDB remote serial protocol. > - Adding Valgrind features (adding syscalls for a platform or VEX > instructions for an architecture port). > - Infrastructure changes to the Valgrind JIT framework. > - Your interesting use case with a debugging tool. > > ** How to Submit > > There are two ways. > The first one is to use the FOSDEM 'pentabarf' tool to submit your proposal: > https://penta.fosdem.org/submission/FOSDEM18 > > - If necessary, create a Pentabarf account and activate it. > Please reuse your account from previous years if you have > already created it. > > - In the "Person" section, provide First name, Last name > (in the "General" tab), Email (in the "Contact" tab) > and Bio ("Abstract" field in the "Description" tab). > > - Submit a proposal by clicking on "Create event". > > - Important! Select the "Debugging Tools devroom" track > (on the "General" tab). > > - Provide the title of your talk ("Event title" in the "General" tab). > > - Provide a description of the subject of the talk and the > intended audience (in the "Abstract" field of the "Description" tab) > > - Provide a rough outline of the talk or goals of the session (a short > list of bullet points covering topics that will be discussed) in the > "Full description" field in the "Description" tab > > The second way is to email your talk proposal to > deb...@fo... alias. > > Julian, Philippe, Mark, Ivosh, and Pedro will review the proposals and > organize the > schedule for the day. Please feel free to suggest or discuss any ideas > for the devroom on deb...@fo... alias. > > ** Recording of Talks > > As usually the FOSDEM organisers plan to have live streaming and > recording fully working, both for remote/later viewing of talks, and > so that people can watch streams in the hallways when rooms are full. > This obviously requires speakers to consent to being recorded and > streamed. If you plan to be a speaker, please understand that by > doing so you implicitly give consent for your talk to be recorded and > streamed. The recordings will be published under the same licence as > all FOSDEM content (CC-BY). > > Important dates: > > Talk/Discussion Submission deadline: Friday 1 Dec 2017 > Devroom Schedule announcement: Friday 15 Dec 2017 > Devroom day: Saturday 3 Feb 2018 > > Hope to see you all at FOSDEM 2018 in the joint Debugging Tools devroom. > Brussels (Belgium), Saturday February 3th 2018. > > On behalf of the devroom committee, > Ivo Raisr |
|
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: 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: 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 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: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 14:55:29
|
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 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 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 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: rNoz <rno...@gm...> - 2017-11-29 09:20:21
|
Do you know why when I execute `valgrind --tool=helgrind ls` (ls or other program) I get "ls: symbol lookup error: /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so: undefined symbol: pthread_mutexattr_gettype"? Version: valgrind-3.13.0-3 ldd /usr/bin/valgrind gives: - linux-vdso.so1 - libc.so.6 - /lib64/ld-linux-x86-64.so.2 I think it started to fail since I upgrade the system (valgrind and its dependencies). I wanted to try the latest valgrind version that works with libc-2.25. But I cannot test it now a previous version because plenty of programs depends on libc 2.26. So, I tried in a fast way: I installed valgrind 3.12.0 (removing the required libc-2.26 dep), and copied libc-2.25 to /usr/lib. Now, it runs `valgrind --tool=helgrind ls` without that error, but another binary (the real program that I wanted to use with valgrind) fails with the same error: valgrind --tool=helgrind ./build/openclprog ==31334== Helgrind, a thread error detector ==31334== Copyright (C) 2007-2015, and GNU GPL'd, by OpenWorks LLP et al. ==31334== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==31334== Command: ./build/openclprog ==31334== Selected platform: Intel(R) OpenCL sel_device changed to: 0 (to fit number of devices) Selected device: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz ./build/openclprog : symbol lookup error: /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so: undefined symbol: pthread_mutexattr_gettype ==31334== ==31334== For counts of detected and suppressed errors, rerun with: -v ==31334== Use --history-level=approx or =none to gain increased speed, at ==31334== the cost of reduced accuracy of conflicting-access information ==31334== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Differences in ldd between ls and openclprog: /usr/bin/ls: linux-vdso.so.1 (0x00007ffd9f936000) libcap.so.2 => /usr/lib/libcap.so.2 (0x00007ff40d2a3000) libc.so.6 => /usr/lib/libc.so.6 (0x00007ff40ceeb000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff40d6d3000) openclprog: linux-vdso.so.1 (0x00007ffc78bde000) libOpenCL.so.1 => /usr/lib/libOpenCL.so.1 (0x00007fc5e5173000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fc5e4deb000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fc5e4a9b000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fc5e4883000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fc5e44cb000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fc5e42c3000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fc5e55bb000) I tried to build openclprog in C++11 and C++17 and in both cases fail. Also, I tried in another computer with a different CPU and GPU (but still AMD) and gives the same error (valgrind 3.12.0). Any clue? |
|
From: Tom H. <to...@co...> - 2017-11-28 13:01:13
|
On 28/11/17 12:05, Jeffrey Walton wrote: > I suspect it is a valid finding but it kind of strikes me as odd that > x86_64 without any -march or -m options is using SSE4. In fact, we > build without -march and -m options because that's how distros want > it. That's fine - glibc has multiple versions of memcmp and other similar routines and selects the best one dynamically at run time based on the capabilities of the CPU that it is running one. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Jeffrey W. <nol...@gm...> - 2017-11-28 12:05:34
|
Hi Everyone, We are catching an uninitialized read finding using Valgrind Git Master. The head of the finding is shown below. I suspect it is a valid finding but it kind of strikes me as odd that x86_64 without any -march or -m options is using SSE4. In fact, we build without -march and -m options because that's how distros want it. It feels like I should work on the capabilities problem first rather than chasing the uninitialized read. I can envision a situation where some component assumes a higher ISA is available so it performs an operation on a data structure that should not happen. My question is, where should I begin to look for the root cause? Is this STL or libstdc++? Or maybe glibc? ********** Here's how all files are compiled. $ make valgrind -j 10 g++ -DNDEBUG -g3 -O1 -fPIC -pthread -pipe -DCRYPTOPP_VALGRIND -c cryptlib.cpp g++ -DNDEBUG -g3 -O1 -fPIC -pthread -pipe -DCRYPTOPP_VALGRIND -c cpu.cpp g++ -DNDEBUG -g3 -O1 -fPIC -pthread -pipe -DCRYPTOPP_VALGRIND -c integer.cpp ... ********** Testing SymmetricCipher algorithm Salsa20. ......==2518== Conditional jump or move depends on uninitialised value(s) ==2518== at 0x4C34C26: __memcmp_sse4_1 (vg_replace_strmem.c:1099) ==2518== by 0x48B435: compare (char_traits.h:310) ==2518== by 0x48B435: __gnu_cxx::__enable_if<std::__is_char<char>::__value, bool>::__type std::operator==<char>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (basic_string.h:6006) ==2518== by 0x4F8BAD: operator!=<char, std::char_traits<char>, std::allocator<char> > (basic_string.h:6045) ==2518== by 0x4F8BAD: CryptoPP::Test::TestSymmetricCipher(std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&, CryptoPP::NameValuePairs const&) (datatest.cpp:514) ... ********** And here is the data test that is failing. Its a torture test, and the "r131072" say "create a string that is 128KB of all 0's": Key: 0F62B5085BAE0154A7FA4DA0F34699EC3F92E5388BDE3184D72A7DD02376C91C IV: 288FF65DC42B92F9 Plaintext: r131072 00 CiphertextXorDigest: E00EBCCD70D69152725F9987982178A2 ... (32 byte omitted) Test: EncryptXorDigest |
|
From: John R. <jr...@bi...> - 2017-11-24 04:36:32
|
> To be more specific, here is my target device spec:
> Processor : ARM926EJ-S rev 5 (v5l) BogoMIPS : 119.19 Features : swp half thumb fastmult edsp java
> CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 5
> So i tried your suggestion, which is "Delete the -mcpu entirely". Another error pops up:
>
> m_dispatch/dispatch-arm-linux.S: Assembler messages:
> m_dispatch/dispatch-arm-linux.S:157: Error: constant expression required -- `movw r1,#:lower16:vgPlain_stats__n_xindirs_32'
> m_dispatch/dispatch-arm-linux.S:158: Error: constant expression required -- `movt r1,#:upper16:vgPlain_stats__n_xindirs_32'
> m_dispatch/dispatch-arm-linux.S:166: Error: constant expression required -- `movw r4,#:lower16:vgPlain_tt_fast'
> m_dispatch/dispatch-arm-linux.S:169: Error: constant expression required -- `movt r4,#:upper16:vgPlain_tt_fast'
> m_dispatch/dispatch-arm-linux.S:182: Error: constant expression required -- `movw r1,#:lower16:vgPlain_stats__n_xindir_misses_32'
> m_dispatch/dispatch-arm-linux.S:183: Error: constant expression required -- `movt r1,#:upper16:vgPlain_stats__n_xindir_misses_32'
> Makefile:3224: recipe for target 'm_dispatch/libcoregrind_arm_linux_a-dispatch-arm-linux.o' failed
0. Running valgrind on Fedora or Debian on a RaspberryPi-3B is so easy and inexpensive
that the app must not be portable. Perhaps it is tied to some special hardware that
is available only on the board with your ARM926EJ-S rev 5 (v5l) ? Why not run on
armv7*, using the software model that simulates the device?
Remember: memcheck is 40 to 50 times slower than straight execution
(the 926EJ has small and slow caches),
so if the device has any hard timing constraints then you may be out of luck;
but often you can change the timing constraints in a software model.
Why not manipulate the device on the 936EJ over the network from the RaspberryPi?
Use what the hardware hackers did to develop the device and/or its software driver.
1. Because the 926EJ is armv5l, then it doesn't do threads very well. Valgrind
assumes that threads work well, so if the app uses threads then you will fail
if you try to run memcheck on the 926EJ. Get armv7*.
2. Looking at the code, the first 2 and last 2 complaints from the assembler
refer to blocks like:
/* stats only */
movw r1, #:lower16:vgPlain_stats__n_xindirs_32
movt r1, #:upper16:vgPlain_stats__n_xindirs_32
ldr r2, [r1, #0]
add r2, r2, #1
str r2, [r1, #0]
and indeed, r1 and r2 are dead after that. So one option is to comment-out
the block of code, and remember that the statistics will be incorrect.
[But you never looked at them before.]
3. The other two complaints refer to:
/* try a fast lookup in the translation cache */
// r0 = next guest, r1,r2,r3,r4 scratch
movw r1, #VG_TT_FAST_MASK // r1 = VG_TT_FAST_MASK
movw r4, #:lower16:VG_(tt_fast)
and r2, r1, r0, LSR #1 // r2 = entry #
movt r4, #:upper16:VG_(tt_fast) // r4 = &VG_(tt_fast)
which can be re-written to use an explicit pointer; something like:
ldr r4, p_tt_fast // r4 = &VG_(tt_fast)
movw r1, #VG_TT_FAST_MASK // r1 = VG_TT_FAST_MASK
and r2, r1, r0, LSR #1 // r2 = entry #
<<snip>>
b postamble
p_tt_fast:
.word VG_(tt_fast)
This will be 1 or 2 cycles slower: a couple percent overall.
--
|
|
From: Toàn T. <min...@gm...> - 2017-11-24 03:15:29
|
Hi John Reiser, Thank you for your reply. To be more specific, here is my target device spec: *Processor : ARM926EJ-S rev 5 (v5l) BogoMIPS : 119.19 Features : swp half thumb fastmult edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 5 * Since it uses ARM926EJ-S processor, in an attempt to fix *error: bad value (cortex-a8) for -mcpu= switch,* I replace cortex-a8 with arm926ej-s for all files in valgrind-3.13.0 folder. I am able to bypass this error but another error pops up: m_dispatch/dispatch-arm-linux.S: Assembler messages: m_dispatch/dispatch-arm-linux.S:104: Error: selected processor does not support `movw r1,#47' m_dispatch/dispatch-arm-linux.S:105: Error: selected processor does not support `movw r2,#0' m_dispatch/dispatch-arm-linux.S:157: Error: selected processor does not support `movw r1,#:lower16:vgPlain_stats__n_xindirs_32' m_dispatch/dispatch-arm-linux.S:158: Error: selected processor does not support `movt r1,#:upper16:vgPlain_stats__n_xindirs_32' m_dispatch/dispatch-arm-linux.S:165: Error: selected processor does not support `movw r1,#(((1<<15))-1)' m_dispatch/dispatch-arm-linux.S:166: Error: selected processor does not support `movw r4,#:lower16:vgPlain_tt_fast' m_dispatch/dispatch-arm-linux.S:169: Error: selected processor does not support `movt r4,#:upper16:vgPlain_tt_fast' m_dispatch/dispatch-arm-linux.S:182: Error: selected processor does not support `movw r1,#:lower16:vgPlain_stats__n_xindir_misses_32' m_dispatch/dispatch-arm-linux.S:183: Error: selected processor does not support `movt r1,#:upper16:vgPlain_stats__n_xindir_misses_32' Makefile:3224: recipe for target 'm_dispatch/libcoregrind_arm_linux_a-dispatch-arm-linux.o' faile So i tried your suggestion, which is "Delete the -mcpu entirely". Another error pops up: m_dispatch/dispatch-arm-linux.S: Assembler messages: m_dispatch/dispatch-arm-linux.S:157: Error: constant expression required -- `movw r1,#:lower16:vgPlain_stats__n_xindirs_32' m_dispatch/dispatch-arm-linux.S:158: Error: constant expression required -- `movt r1,#:upper16:vgPlain_stats__n_xindirs_32' m_dispatch/dispatch-arm-linux.S:166: Error: constant expression required -- `movw r4,#:lower16:vgPlain_tt_fast' m_dispatch/dispatch-arm-linux.S:169: Error: constant expression required -- `movt r4,#:upper16:vgPlain_tt_fast' m_dispatch/dispatch-arm-linux.S:182: Error: constant expression required -- `movw r1,#:lower16:vgPlain_stats__n_xindir_misses_32' m_dispatch/dispatch-arm-linux.S:183: Error: constant expression required -- `movt r1,#:upper16:vgPlain_stats__n_xindir_misses_32' Makefile:3224: recipe for target 'm_dispatch/libcoregrind_arm_linux_a-dispatch-arm-linux.o' failed I desperately need a tool to check memory leak for binary file on my device. Is there any workaround for this? Toan Tran. On Fri, Nov 24, 2017 at 12:30 AM, John Reiser <jr...@bi...> wrote: > Hi everyone, I'm having a problem while trying to cross compile Valgrind >> for ARM. >> > > armv6 and lower are not supported because the hardware lacks reasonable > support > for threads. It is [was] possible to run memcheck of a single-thread > program > on amrv6. Search the mailing list archives and bug reports of a few years > ago > for the patches; I contributed one set. Beware that it is *VERY SLOW* > and it is likely that you will run out of RAM when checking any real > program. > > It is foolish even to try running memcheck on anything less than > a RaspberryPi-3B (1GB RAM, 1GHz CPU, $35.) You have much better things to > do. > Linux distributions such as Fedora and Debian already package valgrind for > armv7*. > > priv/main_globals.c:1: *error: bad value (cortex-a8) for -mcpu= switch * >> Makefile:1254: recipe for target 'priv/libvex_arm_linux_a-main_globals.o' >> failed >> > > -mcpu=cortex-a8 does not match -march=arm. Delete the -mcpu entirely. > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: John R. <jr...@bi...> - 2017-11-23 17:30:15
|
> Hi everyone, I'm having a problem while trying to cross compile Valgrind for ARM. armv6 and lower are not supported because the hardware lacks reasonable support for threads. It is [was] possible to run memcheck of a single-thread program on amrv6. Search the mailing list archives and bug reports of a few years ago for the patches; I contributed one set. Beware that it is *VERY SLOW* and it is likely that you will run out of RAM when checking any real program. It is foolish even to try running memcheck on anything less than a RaspberryPi-3B (1GB RAM, 1GHz CPU, $35.) You have much better things to do. Linux distributions such as Fedora and Debian already package valgrind for armv7*. > priv/main_globals.c:1: *error: bad value (cortex-a8) for -mcpu= switch * > Makefile:1254: recipe for target 'priv/libvex_arm_linux_a-main_globals.o' failed -mcpu=cortex-a8 does not match -march=arm. Delete the -mcpu entirely. |
|
From: Toàn T. <min...@gm...> - 2017-11-23 07:10:43
|
Hi everyone, I'm having a problem while trying to cross compile Valgrind for ARM. These are my whole process step by step: 1/ export PATH=$PATH:/usr/local/arm_linux_4.2/bin/ (export PATH to my cross compiler) 2/ Extract valgrind-3.13.0 3/ cd to valgrind-3.13.0 folder 4/ Run command: sed -i -e "s#armv7#arm#g" configure (to allow cross compile for ARM) 5/ sudo ./configure --host=arm-none-linux-gnueabi 6/ sudo make and the following error pops up: arm-none-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../include -I../VEX/pub -I../VEX/pub -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_vanilla=1 -Ipriv -O2 -g -std=gnu99 -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual -Wwrite-strings -Wformat -Wformat-security -fno-stack-protector -fno-strict-aliasing -fno-builtin -marm -mcpu=cortex-a8 -Wbad-function-cast -fstrict-aliasing -MT priv/libvex_arm_linux_a-main_globals.o -MD -MP -MF priv/.deps/libvex_arm_linux_a-main_globals.Tpo -c -o priv/libvex_arm_linux_a-main_globals.o `test -f 'priv/main_globals.c' || echo './'`priv/main_globals.c priv/main_globals.c:1: *error: bad value (cortex-a8) for -mcpu= switch * Makefile:1254: recipe for target 'priv/libvex_arm_linux_a-main_globals.o' failed What am I doing wrong and how to fix this? Your help is very much appreciated. |
|
From: Toàn T. <min...@gm...> - 2017-11-23 07:06:41
|
Hi everyone, I'm having a problem while trying to cross compile Valgrind for ARM. These are my whole process step by step: 1/ export PATH=$PATH:/usr/local/arm_linux_4.2/bin/ (export PATH to my cross compiler) 2/ Extract valgrind-3.13.0 3/ cd to valgrind-3.13.0 folder 4/ Run command: sed -i -e "s#armv7#arm#g" configure (to allow cross compile for ARM) 5/ sudo ./configure --host=arm-none-linux-gnueabi 6/ sudo make and the following error pops up: arm-none-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../include -I../VEX/pub -I../VEX/pub -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_vanilla=1 -Ipriv -O2 -g -std=gnu99 -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual -Wwrite-strings -Wformat -Wformat-security -fno-stack-protector -fno-strict-aliasing -fno-builtin -marm -mcpu=cortex-a8 -Wbad-function-cast -fstrict-aliasing -MT priv/libvex_arm_linux_a-main_globals.o -MD -MP -MF priv/.deps/libvex_arm_linux_a-main_globals.Tpo -c -o priv/libvex_arm_linux_a-main_globals.o `test -f 'priv/main_globals.c' || echo './'`priv/main_globals.c priv/main_globals.c:1: *error: bad value (cortex-a8) for -mcpu= switch * Makefile:1254: recipe for target 'priv/libvex_arm_linux_a-main_globals.o' failed What am I doing wrong and how to fix this? Your help is very much appreciated. |
|
From: Mark W. <ma...@kl...> - 2017-11-21 20:29:36
|
Hi all, The Talk/Discussion Submission deadline is Friday 1 Dec 2017. See the details below. Debugging Tools developer room at FOSDEM 2018 (Brussels, Belgium, February 3th). FOSDEM is a free software event that offers open source communities a place to meet, share ideas and collaborate. It is renown for being highly developer-oriented and brings together 5000+ hackers from all over the world. It is held in the city of Brussels (Belgium). http://fosdem.org/ FOSDEM 2018 will take place during the weekend of Saturday, February 3th and Sunday February 4th 2018. On Saturday we will have a devroom for Debugging Tools, jointly organized by the Valgrind and GDB projects. Devrooms are a place for development teams to meet, discuss, hack and publicly present the project's latest improvements and future directions. We will have a whole day to hang out together as community embracing debugging tools, such as Valgrind, gdb, RR, Infinity, radare... Please join us, regardless of whether you are a core hacker, a plugin hacker, a user, a packager or a hacker on a project that integrates, extends or complements debugging tools. ** Call for Participation We would like to organize a series of talks/discussions on various topics relevant to both core hackers, new developers, users, packagers and cross project functionality. Please do submit a talk proposal by Friday December 1st 2017, so we can make a list of activities during the day. Some possible topics for talks/discussions are: - The recently added functional changes (for users). - Get feedback on what what kinds of new functionality would be useful. Which tools and functionality users would like to see. - Discuss release/bugfixing strategy/policy (core hackers, packagers). - Connecting debugging tools together. - Latest DWARF extensions, going from binary back to source. - Multi, multi, multi... threads, processes and targets. - Debugging anything, everywhere. Dealing with complex systems. - Dealing with the dynamic loader and the kernel. - Intercepting and interposing functions and events. - Adding GDB features, such as designing GDB python scripts for your data structures. - Advances in gdbserver and the GDB remote serial protocol. - Adding Valgrind features (adding syscalls for a platform or VEX instructions for an architecture port). - Infrastructure changes to the Valgrind JIT framework. - Your interesting use case with a debugging tool. ** How to Submit There are two ways. The first one is to use the FOSDEM 'pentabarf' tool to submit your proposal: https://penta.fosdem.org/submission/FOSDEM18 - If necessary, create a Pentabarf account and activate it. Please reuse your account from previous years if you have already created it. - In the "Person" section, provide First name, Last name (in the "General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field in the "Description" tab). - Submit a proposal by clicking on "Create event". - Important! Select the "Debugging Tools devroom" track (on the "General" tab). - Provide the title of your talk ("Event title" in the "General" tab). - Provide a description of the subject of the talk and the intended audience (in the "Abstract" field of the "Description" tab) - Provide a rough outline of the talk or goals of the session (a short list of bullet points covering topics that will be discussed) in the "Full description" field in the "Description" tab The second way is to email your talk proposal to the deb...@fo... alias. Julian, Philippe, Mark, Ivosh, and Pedro will review the proposals and organize the schedule for the day. Please feel free to suggest or discuss any ideas for the devroom to deb...@fo... ** Recording of Talks As usually the FOSDEM organisers plan to have live streaming and recording fully working, both for remote/later viewing of talks, and so that people can watch streams in the hallways when rooms are full. This obviously requires speakers to consent to being recorded and streamed. If you plan to be a speaker, please understand that by doing so you implicitly give consent for your talk to be recorded and streamed. The recordings will be published under the same licence as all FOSDEM content (CC-BY). Important dates: Talk/Discussion Submission deadline: Friday 1 Dec 2017 Devroom Schedule announcement: Friday 15 Dec 2017 Devroom day: Saturday 3 Feb 2018 Hope to see you all at FOSDEM 2018 in the joint Debugging Tools devroom. Brussels (Belgium), Saturday February 3th 2018. On behalf of the devroom committee, Mark Wielaard |
|
From: Zack W. <za...@pa...> - 2017-11-21 14:54:44
|
On Tue, Nov 21, 2017 at 9:32 AM, John Reiser <jr...@bi...> wrote: > > this is a system call that valgrind does not yet understand. > Please follow the directions: report a bug, by visiting the given URL > and entering the appropriate information. A good title would be > MacOS: unhandled amd64-darwin syscall: unix:464 Inspecting <https://github.com/opensource-apple/xnu/blob/master/bsd/kern/syscalls.master>, it looks like there are a whole bunch of new syscalls. They may have finally gotten around to implementing POSIX.1-2008 - 464 is an openat() variant. zw |
|
From: John R. <jr...@bi...> - 2017-11-21 14:32:42
|
On 11/21/2017 1413Z, Kissami Imad wrote: >> Which version of mac/os? > The latest one 10.13 high sierra, I checked in valgrind code source and I see that is no supported (this valgrind version support only 16.* versions) >> Which version of valgrind? > Valgrind version is 3.13.0 > > > I modified the source code with adding same option for darwin 17.* and I success to install valgrind but when I used it for profiling I had this warning > > --55943-- WARNING: unhandled amd64-darwin syscall: unix:464 > --55943-- You may be able to write your own handler. > --55943-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > --55943-- Nevertheless we consider this a bug. Please report > --55943-- it at http://valgrind.org/support/bug_reports.html. > --55943-- WARNING: unhandled amd64-darwin syscall: unix:464 > --55943-- You may be able to write your own handler. > --55943-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > --55943-- Nevertheless we consider this a bug. Please report > --55943-- it at http://valgrind.org/support/bug_reports.html. Using a web search engine, > No results found for unhandled amd64-darwin syscall: "unix:464" . therefore this is a system call that valgrind does not yet understand. Please follow the directions: report a bug, by visiting the given URL and entering the appropriate information. A good title would be MacOS: unhandled amd64-darwin syscall: unix:464 -- |
188 messages has been excluded from this view by a project administrator.
