Created attachment 204999 [details] diff build logs Hello, I'm see broken build emulators/i386-wine-devel if revert usr.bin/strings on 325188 build fixed.
Could you generate a core dump of string and paste it here? To do that please set those sysctls: kern.trap_enotcap kern.capmode_coredump kern.corefile Thank you, Mariusz
hm... this crash not generate core :( test perl -e 'dump' make core success. if you have time this instruction for build https://wiki.freebsd.org/i386-Wine
I managed to reproduce this. It looks like some strange issue in libnv or the kernel, libnv is seeing recv() return 0 upon attempting to read a new message. I suspect that there is a problem in our 32-bit compat code for sockets.
If the issue is in the libnv and Casper I can look into this. Could you tell me how to reproduce the problem or can you add the core dump?
(In reply to Mariusz Zaborski from comment #4) I'm pretty sure it's a bug somewhere in our freebsd32 sendmsg, I'm still digging into it. To repro, run the following in an i386 chroot on amd64: $ jot -b /bin/cat 85 >/tmp/files $ strings $(cat /tmp/files) >/dev/null strings: '/bin/cat': Invalid argument $
So, the issue is that we have an undocumented limit on the number of descriptors that we can send in a single sendmsg() call, and it's the number that fits in an mbuf cluster (MCLBYTES = 2KB). And, libnv has this: 62 #ifdef __linux__ 63 /* Linux: arbitrary size, but must be lower than SCM_MAX_FD. */ 64 #define PKG_MAX_SIZE ((64U - 1) * CMSG_SPACE(sizeof(int))) 65 #else 66 #define PKG_MAX_SIZE (MCLBYTES / CMSG_SPACE(sizeof(int)) - 1) 67 #endif The problem is that libnv passes each fd in a separate cmsg (no idea why), and these cmsgs have a different size on 32-bit vs. 64-bit FreeBSD due to alignment. Our freebsd32 sendmsg translates the messages to their native size, so it can only accept as many as our 64-bit sendmsg. But a 32-bit application running on a 64-bit kernel doesn't know that. We could largely mitigate the problem here by passing all of the fds in a single cmsg. That would also be more efficient. But this is really a general problem in our freebsd32 compat, which must be willing to construct an mbuf chain to hold the control message instead of assuming that it all fits in one cluster.
Grab this bug since I'm working on it. https://reviews.freebsd.org/D20941 https://reviews.freebsd.org/D20942
A commit references this bug: Author: markj Date: Tue Jul 16 16:28:50 UTC 2019 New revision: 350054 URL: https://svnweb.freebsd.org/changeset/base/350054 Log: Use a platform-independent constant for PKG_MAX_SIZE. This constant determines the number of rights libnv will attempt to transmit in a given control message. In practice, the upper limit defined by the kernel is machine-dependent and is smaller on 64-bit kernels than on 32-bit kernels. To ensure that a 32-bit libnv works as expected when run on a 64-bit kernel, use a limit that will work on both 32-bit and 64-bit kernels. PR: 238511 Discussed with: oshogbo MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D20942 Changes: head/lib/libnv/msgio.c
A commit references this bug: Author: markj Date: Fri Jul 19 15:07:31 UTC 2019 New revision: 350130 URL: https://svnweb.freebsd.org/changeset/base/350130 Log: MFC r350054: Use a platform-independent constant for PKG_MAX_SIZE. PR: 238511 Changes: _U stable/12/ stable/12/lib/libnv/msgio.c
Thanks for the report.
build of emulators/i386-wine-devel | i386-wine-devel-4.17,1 ended at Tue Oct 8 23:16:21 MSK 2019 >/usr/bin/grep -v '[@%]' /wrkdirs/usr/ports/emulators/i386-wine-devel/work/.PLIST.mktmp | /usr/bin/sed "s!^!/wrkdirs/usr/ports/emulators/i386-wine-devel/work/stage/usr/local/!g" | /usr/bin/xargs -n1 file -F' ' | /usr/bin/grep ELF | /usr/bin/cut -f1 -d' ' | /usr/bin/xargs strings | /usr/bin/grep '^lib.*\.so' | /usr/bin/sort -u > /wrkdirs/usr/ports/emulators/i386-wine-devel/work/winesoftlibs >strings: '/wrkdirs/usr/ports/emulators/i386-wine-devel/work/stage/usr/local/lib32/wine/tapi32.dll.so': Socket is not connected >xargs: strings: terminated with signal 13; aborting
(In reply to Andrey Fesenko from comment #11) Please provide the host and jail revisions.
Host OSVERSION: 1300048 Jail OSVERSION: 1300048 full log https://suahbsd.org/poudriere-logs/data/13i386-default-wine/2019-10-08_15h55m10s/logs/i386-wine-devel-4.17,1.log
(In reply to Andrey Fesenko from comment #13) My apologies, I never followed up on this. :( Is it still occurring? I fixed another related bug recently, 241226, which may be the cause.
I presume the problem is now fixed with PR 241226.