You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(5) |
2
(11) |
|
3
(3) |
4
|
5
|
6
|
7
|
8
|
9
|
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
|
17
|
18
|
19
|
20
|
21
|
22
|
23
|
|
24
|
25
|
26
|
27
|
28
|
29
|
30
|
|
From: Philippe W. <phi...@so...> - 2023-09-01 19:05:46
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=c0b2c786d38002a20f845a9fb739b8659fa87bcc commit c0b2c786d38002a20f845a9fb739b8659fa87bcc Author: Philippe Waroquiers <phi...@sk...> Date: Fri Sep 1 20:23:46 2023 +0200 Fix 473944 Handle mold linker split RW PT_LOAD segments correctly Condition to consider segments will be merged has to be more specific than just having a page rounded file offset p_offset. Regtested on debian, somewhat poorly due to the amount of tests failing due to: 473745 must-be-redirected function - strlen - for valgrind 3.22 but not 3.21 Diff: --- NEWS | 3 +- coregrind/m_debuginfo/readelf.c | 72 ++++++++++++++++++++++++++++++++--------- 2 files changed, 59 insertions(+), 16 deletions(-) diff --git a/NEWS b/NEWS index 519ed664c1..6f13d53569 100644 --- a/NEWS +++ b/NEWS @@ -12,7 +12,7 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. * A new configure option --with-gdbscripts-dir lets you install the gdb valgrind python monitor scripts in a specific location. - For example an distro could use it to install the scripts in a + For example a distro could use it to install the scripts in a safe load location --with-gdbscripts-dir=%{_datadir}/gdb/auto-load It is also possible to configure --without-gdb-scripts-dir so no .debug_gdb_scripts section is added to the vgpreload library and @@ -53,6 +53,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 473604 Fix bug472219.c compile failure with Clang 16 473677 make check compile failure with Clang 16 based on GCC 13.x 473870 FreeBSD 14 applications fail early at startup +473944 Handle mold linker split RW PT_LOAD segments correctly n-i-bz Allow arguments with spaces in .valgrindrc files To see details of a given bug, visit diff --git a/coregrind/m_debuginfo/readelf.c b/coregrind/m_debuginfo/readelf.c index ac72f98fb5..a4c79efd0f 100644 --- a/coregrind/m_debuginfo/readelf.c +++ b/coregrind/m_debuginfo/readelf.c @@ -32,6 +32,7 @@ #include "pub_core_basics.h" #include "pub_core_vki.h" #include "pub_core_vkiscnums.h" +#include "pub_core_debuglog.h" #include "pub_core_debuginfo.h" #include "pub_core_libcbase.h" #include "pub_core_libcprint.h" @@ -3793,6 +3794,7 @@ Bool ML_(check_elf_and_get_rw_loads) ( Int fd, const HChar* filename, Int * rw_l DiOffT phdr_mioff = 0; UWord phdr_mnent = 0U; UWord phdr_ment_szB = 0U; + ElfXX_Phdr previous_rw_a_phdr; res = False; @@ -3830,6 +3832,9 @@ Bool ML_(check_elf_and_get_rw_loads) ( Int fd, const HChar* filename, Int * rw_l phdr_mnent = ehdr_m.e_phnum; phdr_ment_szB = ehdr_m.e_phentsize; + /* Sets p_memsz to 0 to indicate we have not yet a previous a_phdr. */ + previous_rw_a_phdr.p_memsz = 0; + for (i = 0U; i < phdr_mnent; i++) { ElfXX_Phdr a_phdr; ML_(img_get)(&a_phdr, mimg, @@ -3841,22 +3846,59 @@ Bool ML_(check_elf_and_get_rw_loads) ( Int fd, const HChar* filename, Int * rw_l if (((a_phdr.p_flags & (PF_R | PF_W)) == (PF_R | PF_W)) && ((a_phdr.p_flags & flag_x) == 0)) { ++*rw_load_count; - } + if (VG_(debugLog_getLevel)() > 1) + VG_(message)(Vg_DebugMsg, "check_elf_and_get_rw_loads: " + "++*rw_load_count to %d for %s " + "p_vaddr %#lx p_offset %lu, p_filesz %lu\n", + *rw_load_count, filename, + (UWord)a_phdr.p_vaddr, (UWord)a_phdr.p_offset, + (UWord)a_phdr.p_filesz); + /* + * Hold your horses + * Just because The ELF file contains 2 RW PT_LOAD segments + * doesn't mean that Valgrind will also make 2 calls to + * VG_(di_notify_mmap): in some cases, the 2 NSegments will get + * merged and VG_(di_notify_mmap) only gets called once. + * How to detect that the segments will be merged ? + * Logically, they will be merged if the first segment ends + * at the beginning of the second segment: + * Seg1 virtual address + Seg1 segment_size + * == Seg2 virtual address. + * However, it is not very clear how the file section will be + * loaded: the PT_LOAD specifies a file size and a memory size. + * Logically, the memory size should be used in the above + * condition, but strangely enough, in some cases the file size + * can be smaller than the memory size. And that then result in + * an "anonymous" mapping done between the 2 segments that + * otherwise would be consecutive. + * This has been seen in an executable linked by the mold linker + * (see bug 473944). In this case, the file segments were loaded + * with a "page rounded up" file size (observed on RHEL 8.6, + * ld-2.28.so, mold 1.5.1). + * However, in FreeBSD with lld (see 452802 and 473944), rounding + * up p_filesz in the below condition makes at least one test + * fail. + * As on the mold case, the below condition correctly ensures + * the 2 different segments loaded separately are both counted + * here, we use the non rounded up p_filesz. + * This is all a nightmare/hack. Something cleaner should be + * done than trying to guess here if segments will or will not + * be merged later depending on how the loader will load + * with or without rounding up. + * */ + if (previous_rw_a_phdr.p_memsz > 0 && + ehdr_m.e_type == ET_EXEC && + previous_rw_a_phdr.p_vaddr + previous_rw_a_phdr.p_filesz + == a_phdr.p_vaddr) + { + --*rw_load_count; + if (VG_(debugLog_getLevel)() > 1) + VG_(message)(Vg_DebugMsg, "check_elf_and_get_rw_loads: " + " --*rw_load_count to %d for %s\n", + *rw_load_count, filename); + } - /* - * Hold your horses - * Just because The ELF file contains 2 RW PT_LOAD segments it - * doesn't mean that Valgrind will also make 2 calls to - * VG_(di_notify_mmap). If the stars are all aligned - * (which usually means that the ELF file is the client - * executable with the segment offset for the - * second PT_LOAD falls exactly on 0x1000) then the NSegements - * will get merged and VG_(di_notify_mmap) only gets called once. */ - if (*rw_load_count == 2 && - ehdr_m.e_type == ET_EXEC && - a_phdr.p_offset == VG_PGROUNDDN(a_phdr.p_offset) ) - { - *rw_load_count = 1; + previous_rw_a_phdr = a_phdr; } } } |
|
From: Carl L. <ce...@us...> - 2023-09-01 18:59:57
|
Mark: On Fri, 2023-09-01 at 16:21 +0200, Mark Wielaard wrote: > Hi Carl, > > On Thu, 2023-08-31 at 15:38 -0700, Carl Love wrote: > > So, I then tried to run the same test on a Power 8LE system Ubuntu > > 20.04.5 LTS (Focal Fossa). I get: > > > > valgrind --tool=memcheck -q ./memcheck/tests/doublefree > out- > > current > > > > valgrind: Fatal error at startup: a function redirection > > valgrind: which is mandatory for this platform-tool combination > > valgrind: cannot be set up. Details of the redirection are: > > valgrind: > > valgrind: A must-be-redirected function > > valgrind: whose name matches the pattern: strlen > > valgrind: in an object with soname matching: ld64.so.2 > > valgrind: was not found whilst processing > > valgrind: symbols from the object with soname: ld64.so.2 > > valgrind: > > valgrind: Possible fixes: (1, short term): install glibc's > > debuginfo > > valgrind: package on this machine. (2, longer term): ask the > > packagers > > valgrind: for your Linux distribution to please in future ship a > > non- > > valgrind: stripped ld.so (or whatever the dynamic linker .so is > > called) > > valgrind: that exports the above-named function using the standard > > valgrind: calling conventions for this platform. The package you > > need > > valgrind: to install for fix (1) is called > > valgrind: > > valgrind: On Debian, Ubuntu: libc6-dbg > > valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo > > valgrind: > > valgrind: Note that if you are debugging a 32 bit process on a > > valgrind: 64 bit system, you will need a corresponding 32 bit > > debuginfo > > valgrind: package (e.g. libc6-dbg:i386). > > valgrind: > > valgrind: Cannot continue -- exiting now. Sorry. > > > > > > When I put in my print statements, I see the call to > > read_elf_symtab__normal instead of read_elf_symtab__ppc64be_linux > > as > > expected. It appears that some of the image file is read as I see a > > second call to di_notify_ACHIEVE_ACCEPT_STATE, read_elf_object > > which I > > don't see on the BE system before the run fails. > > So the above is indeed not architecture, but Debian/Ubuntu specific. > It is tracked as > https://bugs.kde.org/show_bug.cgi?id=473745 > > > It is because the ld.so symtab is in a separate dbg package, which > (now) isn't loaded early anymore when resolving the hardwired > redirects. It doesn't happen on other distros because they keep > symtab > in ld.so. I added the attached patch and tested on the four different platforms. The git tree for all four systems was: commit 053cf5ff31e4a2d65726af431824bf30172d21ed (HEAD -> master) Author: Mark Wielaard <ma...@kl...> Date: Fri Sep 1 19:10:17 2023 +0200 Explicitly load libc and any sonames that contain mandatory specs https://bugs.kde.org/show_bug.cgi?id=473745 commit d76ddc0981862bde160a92baf362d3baf2633368 Author: Aaron Merey <am...@re...> Date: Wed Aug 30 14:49:09 2023 -0400 Fix lazy debuginfo loading on ppc64le Lazy debuginfo loading introduced in commit 60f7e89ba32 assumed that either describe_IP or find_DiCfSI will be called before stacktrace printing. describe_IP and find_DiCfSI cause debuginfo to be lazily loaded before symtab lookup occurs during stacktraces. However this assumption does not hold true on ppc64le, resulting in debuginfo failing to load in time for stacktraces. Fix this by loading debuginfo during get_StackTrace_wrk on ppc arches. commit c934430d56c2add25002ea8e321bd8bdab80fc99 (origin/master, origin/HEAD) Author: Paul Floyd <pj...@wa...> Date: Thu Aug 31 15:32:21 2023 +0200 Bug 473870 - FreeBSD 14 applications fail early at startup FreeBSD recently started adding some functions using @gnu_indirect_function, specifically strpcmp which was causing this crash. When running and encountering this ifunc Valgrind looked for the ifunc_handler. But there wasn't one for FreeBSD so Valgrind asserted. The test results are: machine pre-lazy-load current mainline with ppc debuginfo fix with Explicitly-load- (as of 8/31/2023) libc-and-any-sonames Power 8 LE Red Hat Enterprise Linux Server 7.9 (Maipo) 707 tests, 708 tests, 708 tests 708 tests, 4 stderr failures, 280 stderr failures, 247 stderr failures, 4 stderr failures, 0 stdout failures, 54 stdout failures, 54 stdout failures, 0 stdout failures, 13 stderrB failures, 16 stderrB failures, 16 stderrB failures, 13 stderrB failures, 0 stdoutB failures, 11 stdoutB failures, 12 stdoutB failures 0 stdoutB failures 9 post failures 13 post failures 9 post failures 9 post failures Power 8 BE Ubuntu 20.04.5 LTS (Focal Fossa) 742 tests, 743 tests, 743 tests, 743 tests, 2 stderr failures, 671 stderr failures, 671 stderr failures, 671 stderr failures 0 stdout failures, 152 stdout failures, 152 stdout failures, 152 stdout failures, 0 stderrB failures, 14 stderrB failures, 14 stderrB failures, 14 stderrB failures, 2 stdoutB failures, 20 stdoutB failures, 20 stdoutB failures, 20 stdoutB failures, 9 post failures 43 post failures 43 post failures 43 post failures Power 9 LE Ubuntu 20.04.5 LTS (Focal Fossa) 711 tests, 712 tests, 712 tests, 712 tests, 4 stderr failures, 280 stderr failures, 247 stderr failures, 4 stderr failures, 0 stdout failures, 54 stdout failures, 54 stdout failures, 0 stdout failures, 13 stderrB failures, 16 stderrB failures, 16 stderrB failures, 13 stderrB failures, 0 stdoutB failures, 12 stdoutB failures, 12 stdoutB failures 0 stdoutB failures, 9 post failures 13 post failures 9 post failures 9 post failures Power 10 LE Red Hat Enterprise Linux 9.0 (Plow) 719 tests 720 tests, 720 tests, 720 tests, 2 stderr failures, 42 stderr failures, 2 stderr failures, 2 stderr failures, 0 stdout failures, 0 stdout failures, 0 stdout failures, 0 stdout failures, 2 stderrB failures, 2 stderrB failures, 2 stderrB failures, 2 stderrB failures, 10 stdoutB failures, 10 stdoutB failures, 10 stdoutB failures, 10 stdoutB failures 0 post failures 3 post failures 0 post failures 0 post failures The Explicitly-load-libc-and-any-sonames-that-contain-ma.patch seems to fix the issues across the various OS distributions for the LE machines. It does appear that there is a separate issue with the original patch to lazily load the debug info on PowerPC BE. Hopefully we can sort that issue out when Aaron gets back from vacation. Thanks for your help with the latest patch. Carl |
|
From: Mark W. <ma...@kl...> - 2023-09-01 17:47:42
|
On Fri, 2023-09-01 at 16:21 +0200, Mark Wielaard wrote: > So the above is indeed not architecture, but Debian/Ubuntu specific. > It is tracked as https://bugs.kde.org/show_bug.cgi?id=473745 > > It is because the ld.so symtab is in a separate dbg package, which > (now) isn't loaded early anymore when resolving the hardwired > redirects. It doesn't happen on other distros because they keep symtab > in ld.so. I have attached a patch that seems to work for me. |
|
From: Mark W. <ma...@kl...> - 2023-09-01 14:21:34
|
Hi Carl, On Thu, 2023-08-31 at 15:38 -0700, Carl Love wrote: > So, I then tried to run the same test on a Power 8LE system Ubuntu > 20.04.5 LTS (Focal Fossa). I get: > > valgrind --tool=memcheck -q ./memcheck/tests/doublefree > out- > current > > valgrind: Fatal error at startup: a function redirection > valgrind: which is mandatory for this platform-tool combination > valgrind: cannot be set up. Details of the redirection are: > valgrind: > valgrind: A must-be-redirected function > valgrind: whose name matches the pattern: strlen > valgrind: in an object with soname matching: ld64.so.2 > valgrind: was not found whilst processing > valgrind: symbols from the object with soname: ld64.so.2 > valgrind: > valgrind: Possible fixes: (1, short term): install glibc's debuginfo > valgrind: package on this machine. (2, longer term): ask the > packagers > valgrind: for your Linux distribution to please in future ship a non- > valgrind: stripped ld.so (or whatever the dynamic linker .so is > called) > valgrind: that exports the above-named function using the standard > valgrind: calling conventions for this platform. The package you need > valgrind: to install for fix (1) is called > valgrind: > valgrind: On Debian, Ubuntu: libc6-dbg > valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo > valgrind: > valgrind: Note that if you are debugging a 32 bit process on a > valgrind: 64 bit system, you will need a corresponding 32 bit > debuginfo > valgrind: package (e.g. libc6-dbg:i386). > valgrind: > valgrind: Cannot continue -- exiting now. Sorry. > > > When I put in my print statements, I see the call to > read_elf_symtab__normal instead of read_elf_symtab__ppc64be_linux as > expected. It appears that some of the image file is read as I see a > second call to di_notify_ACHIEVE_ACCEPT_STATE, read_elf_object which I > don't see on the BE system before the run fails. So the above is indeed not architecture, but Debian/Ubuntu specific. It is tracked as https://bugs.kde.org/show_bug.cgi?id=473745 It is because the ld.so symtab is in a separate dbg package, which (now) isn't loaded early anymore when resolving the hardwired redirects. It doesn't happen on other distros because they keep symtab in ld.so. Cheers, Mark |
|
From: Paul F. <pa...@so...> - 2023-09-01 06:26:48
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=8a545a3684024f4a54bb20b7ad1d0fe9949bbede commit 8a545a3684024f4a54bb20b7ad1d0fe9949bbede Author: Paul Floyd <pj...@wa...> Date: Fri Sep 1 08:26:24 2023 +0200 FreeBSD: add common failure causes to README.freebsd Also fix the name of one of the fields of vki_kinfo_vmentry. Diff: --- README.freebsd | 15 ++++++++++++++- coregrind/m_aspacemgr/aspacemgr-linux.c | 2 +- include/vki/vki-freebsd.h | 2 +- 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/README.freebsd b/README.freebsd index eb6a510ada..ce1e435f5d 100644 --- a/README.freebsd +++ b/README.freebsd @@ -130,7 +130,20 @@ These are much easier. They just contain a POST_MEM_WRITE macro for each output argument. -1. Running regression tests +1. Frequent causes of problems + +- New _umtx_op codes. Valgrind will print "WARNING: _umtx_op unsupported value". + See syswrap-freebsd.c and add new cases for the new codes. +- Additions to auxv. Depending on the entry it may need to be simply copied + from the host to the guest, it may need to be modified for the guest or + it may need to be ignored. See initimg-freebsd.c. +- ELF PT_LOAD mappings. Either Valgrind will assert or there will be no source + information in error reports. See VG_(di_notify_mmap) in debuginfo.c +- Because they contain many deliberate errors the regression tests are prone + to change with changes of compiler. Liberal use of 'volatile' and + '-Wno-warning-flag' can help - see configure.ac + +2. Running regression tests In order to run all of the regression tests you will need to install the following packages diff --git a/coregrind/m_aspacemgr/aspacemgr-linux.c b/coregrind/m_aspacemgr/aspacemgr-linux.c index ae38d8bd05..ba8964928e 100644 --- a/coregrind/m_aspacemgr/aspacemgr-linux.c +++ b/coregrind/m_aspacemgr/aspacemgr-linux.c @@ -3943,7 +3943,7 @@ static void parse_procselfmaps ( endPlusOne = (UWord)kve->kve_end; foffset = kve->kve_offset; filename = kve->kve_path; - dev = kve->kve_fsid_freebsd11; + dev = kve->kve_vn_fsid_freebsd11; ino = kve->kve_fileid; if (filename[0] != '/') { filename = NULL; diff --git a/include/vki/vki-freebsd.h b/include/vki/vki-freebsd.h index 92ca8a6878..b30b2933ec 100644 --- a/include/vki/vki-freebsd.h +++ b/include/vki/vki-freebsd.h @@ -2170,7 +2170,7 @@ struct vki_kinfo_vmentry { ULong kve_end; ULong kve_offset; ULong kve_fileid; - UInt kve_fsid_freebsd11; + UInt kve_vn_fsid_freebsd11; int kve_flags; int kve_resident; int kve_private_resident; |