Bug 219715 - devel/valgrind: unhandled syscall (ino64 fallout?)
Summary: devel/valgrind: unhandled syscall (ino64 fallout?)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Bryan Drewery
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-02 03:57 UTC by Kyle Evans
Modified: 2019-03-04 20:31 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (bdrewery)


Attachments
wip fix (7.68 KB, patch)
2017-09-09 15:11 UTC, Roman Bogorodskiy
no flags Details | Diff
wip valgrind ino64 fix (7.09 KB, patch)
2017-09-09 16:59 UTC, Roman Bogorodskiy
no flags Details | Diff
Add st_birthtim to vki_stat64 (1.90 KB, patch)
2019-01-08 09:19 UTC, Roman Bogorodskiy
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle Evans freebsd_committer freebsd_triage 2017-06-02 03:57:31 UTC
On a post-ino64 world (stat/file output included for completeness), all valgrind invocations fail:

root@ghost:/tmp# valgrind ls -l
==2846== Memcheck, a memory error detector
==2846== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2846== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==2846== Command: ls -l
==2846== 
--2846-- WARNING: unhandled syscall: 552
--2846-- You may be able to write your own handler.
--2846-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--2846-- Nevertheless we consider this a bug.  Please report
--2846-- it at http://valgrind.org/support/bug_reports.html.
--2846-- WARNING: unhandled syscall: 551
--2846-- You may be able to write your own handler.
--2846-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--2846-- Nevertheless we consider this a bug.  Please report
--2846-- it at http://valgrind.org/support/bug_reports.html.
Cannot fstat "/usr/local/lib/valgrind/vgpreload_core-amd64-freebsd.so"
==2846== 
==2846== HEAP SUMMARY:
==2846==     in use at exit: 0 bytes in 0 blocks
==2846==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2846== 
==2846== All heap blocks were freed -- no leaks are possible
==2846== 
==2846== For counts of detected and suppressed errors, rerun with: -v
==2846== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

root@ghost:/tmp# stat /usr/local/lib/valgrind/vgpreload_core-amd64-freebsd.so
18446744071775659938 331657 -r-xr-xr-x 1 root wheel 18446744073709551615 3208 "Jun  1 22:48:37 2017" "Jun  1 22:48:37 2017" "Jun  1 22:48:55 2017" "Jun  1 22:48:37 2017" 4096 9 0x800 /usr/local/lib/valgrind/vgpreload_core-amd64-freebsd.so

root@ghost:/tmp# file /usr/local/bin/valgrind
/usr/local/bin/valgrind: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200031), FreeBSD-style, stripped
Comment 1 Bryan Drewery freebsd_committer freebsd_triage 2017-06-02 04:16:53 UTC
My system is too old to test fixes for this currently. In theory it should
be easy to code up.
Comment 2 Bryan Drewery freebsd_committer freebsd_triage 2017-06-02 04:18:15 UTC
sys/kern/syscalls.master:551    AUE_FSTAT       STD     { int fstat(int fd, struct stat *sb); }
sys/kern/syscalls.master:552    AUE_FSTATAT     STD     { int fstatat(int fd, char *path, \
sys/kern/syscalls.master-                                   struct stat *buf, int flag); }
Comment 3 Bryan Drewery freebsd_committer freebsd_triage 2017-06-02 04:20:38 UTC
And the old ones need modified support as well:

sys/kern/syscalls.master:188    AUE_STAT        COMPAT11 { int stat(char *path, \
sys/kern/syscalls.master-                                   struct freebsd11_stat *ub); }
sys/kern/syscalls.master:493    AUE_FSTATAT     COMPAT11 { int fstatat(int fd, char *path, \
sys/kern/syscalls.master-                                   struct freebsd11_stat *buf, int flag); }

...


There's actually a dozen or so changes that need to be accounted for:
https://github.com/freebsd/freebsd/commit/e75ba1d5c4c79376a78351c8544388491db49664#diff-05dd75694f9540a2575ae474ae31f6c4
Comment 4 Roman Bogorodskiy freebsd_committer freebsd_triage 2017-09-09 15:11:25 UTC
Created attachment 186198 [details]
wip fix

I've played around with this today and got it more or less working.

Unfortunately, I wasn't able to make it work properly with 64-bit stat (you'll notice the && 0 hack if you read the patch).

lldb is somewhat not very helpful and the only backtrace I get have from it looks like this:

$ lldb /usr/local/lib/valgrind/memcheck-amd64-freebsd -c memcheck-amd64-free.core                                                                                     
(lldb) target create "/usr/local/lib/valgrind/memcheck-amd64-freebsd" --core "memcheck-amd64-free.core"   
Core file '/home/novel/ports_stuff/valgrind/memcheck-amd64-free.core' (x86_64) was loaded.                
(lldb) bt                                            
* thread #1, name = 'memcheck-amd64-free', stop reason = signal SIGSEGV                                   
  * frame #0: 0x000000003807f1fa memcheck-amd64-freebsd`vgPlain_fstat(fd=0, vgbuf=0x0000000000000000) at m_libcfile.c:378                                                                                           
(lldb) list                                          
(lldb) 

With m_libcfile.c:378 being:

 372 #  if defined(__NR_fstat64)
 373    { struct vki_stat64 buf64;
 374      res = VG_(do_syscall2)(__NR_fstat64, (UWord)fd, (UWord)&buf64);
 375      if (!(sr_isError(res) && sr_Err(res) == VKI_ENOSYS)) {
 376         /* Success, or any failure except ENOSYS */
 377         if (!sr_isError(res))
 378            TRANSLATE_TO_vg_stat(vgbuf, &buf64);
 379         return sr_isError(res) ? (-1) : 0;
 380      }
 381    }

Probably I've messed up with one of the struct sizes, but I'm not sure how to find the specific place.
Comment 5 Roman Bogorodskiy freebsd_committer freebsd_triage 2017-09-09 16:59:28 UTC
Created attachment 186200 [details]
wip valgrind ino64 fix

Should be a little better now.
Comment 6 Bryan Drewery freebsd_committer freebsd_triage 2017-10-18 17:24:37 UTC
(In reply to Roman Bogorodskiy from comment #5)
> Created attachment 186200 [details]
> wip valgrind ino64 fix
> 
> Should be a little better now.

Thanks, if I can find some time I'll take a look too.

What's the current status? Is everything implemented or are some things
still missing or only partly working?
Comment 7 Bryan Drewery freebsd_committer freebsd_triage 2017-10-30 17:14:08 UTC
Committed, reopen if there's more missing.
Comment 8 commit-hook freebsd_committer freebsd_triage 2017-10-30 17:14:34 UTC
A commit references this bug:

Author: bdrewery
Date: Mon Oct 30 17:13:32 UTC 2017
New revision: 453198
URL: https://svnweb.freebsd.org/changeset/ports/453198

Log:
  Add support for ino64.

  PR:		219715
  Submitted by:	novel

Changes:
  head/devel/valgrind/Makefile
  head/devel/valgrind/files/extra-patch-ino64
  head/devel/valgrind-devel/Makefile
  head/devel/valgrind-devel/files/extra-patch-ino64
Comment 9 Mark Johnston freebsd_committer freebsd_triage 2019-01-07 01:16:04 UTC
The patch contains a bug: struct vki_stat64 is missing the st_birthtim field.
Comment 10 Roman Bogorodskiy freebsd_committer freebsd_triage 2019-01-08 09:19:30 UTC
Created attachment 200906 [details]
Add st_birthtim to vki_stat64

I've added this missing field.

However, it looks like something got broken and I don't have memcheck working at all on 13-CURRENT, now it always reports:

total heap usage: 0 allocs, 0 frees, 0 bytes allocated
Comment 11 Mark Johnston freebsd_committer freebsd_triage 2019-01-08 16:47:41 UTC
(In reply to Roman Bogorodskiy from comment #10)
Thanks, looks good.

I noticed an identical memcheck problem in a project to get valgrind 3.13 working on FreeBSD.  That one was an upstream bug: https://bugs.kde.org/show_bug.cgi?id=402985

However, it's a recent regression and shouldn't be impacting the version of valgrind in ports AFAIK.  I'll see if I can figure out what's happening there.  Do you mind submitting a new PR?
Comment 12 Roman Bogorodskiy freebsd_committer freebsd_triage 2019-01-08 17:59:34 UTC
(In reply to Mark Johnston from comment #11)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234759

> However, it's a recent regression and shouldn't be impacting the version of valgrind in ports AFAIK.

Ports version also fails to read ELF symbols (yet to figure out if that causes the mentioned breakage or an unrelated issue):

--77604-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-amd64-freebsd.so
--77604-- ELF section outside all mapped regions
--77604-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so
--77604-- ELF section outside all mapped regions
--77604-- Reading syms from /lib/libc.so.7
--77604-- ELF section outside all mapped regions
Comment 13 Mark Johnston freebsd_committer freebsd_triage 2019-01-08 18:22:43 UTC
(In reply to Roman Bogorodskiy from comment #12)
That looks like a mostly unrelated issue.  My guess is that it's a consequence of switching to lld: unlike the ld.bfd in the base system, lld creates a read-only loadable segment for the symbol table, among other things.  valgrind required some changes to handle similar behaviour in newer versions of GNU ld: https://bugs.kde.org/show_bug.cgi?id=395682

My guess is that this is the same issue.  You can try running valgrind on a program linked with ld.bfd to confirm.
Comment 14 Roman Bogorodskiy freebsd_committer freebsd_triage 2019-01-09 15:09:13 UTC
(In reply to Mark Johnston from comment #13)

I tried building a test program using cc -fuse-ld=bfd test.c (cc being clang 7.0.1), no changes.
Comment 15 Mark Johnston freebsd_committer freebsd_triage 2019-03-04 20:30:39 UTC
(In reply to Roman Bogorodskiy from comment #10)
Any chance the stat fix could be committed despite the regression?  It certainly dosen't make things worse.  We can investigate the issue with malloc interposition in a separate PR.
Comment 16 Mark Johnston freebsd_committer freebsd_triage 2019-03-04 20:31:12 UTC
(In reply to Mark Johnston from comment #15)
Sorry for the noise, it was indeed committed.