Summary: | devel/valgrind: unhandled syscall (ino64 fallout?) | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Kyle Evans <kevans> | ||||||||
Component: | Individual Port(s) | Assignee: | Bryan Drewery <bdrewery> | ||||||||
Status: | Closed FIXED | ||||||||||
Severity: | Affects Many People | CC: | emaste, kib, markj, michaelbuch12, novel | ||||||||
Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(bdrewery) |
||||||||
Version: | Latest | ||||||||||
Hardware: | Any | ||||||||||
OS: | Any | ||||||||||
Attachments: |
|
Description
Kyle Evans
2017-06-02 03:57:31 UTC
My system is too old to test fixes for this currently. In theory it should be easy to code up. 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); } 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 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.
Created attachment 186200 [details]
wip valgrind ino64 fix
Should be a little better now.
(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? Committed, reopen if there's more missing. 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 The patch contains a bug: struct vki_stat64 is missing the st_birthtim field. 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
(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? (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 (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. (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. (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. (In reply to Mark Johnston from comment #15) Sorry for the noise, it was indeed committed. |