https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297638
--- Comment #1 from Markus Wild <[email protected]> --- There seems to be a race whether the bug triggers or not. The problem itself does seem to happen with previous systems as well, but the probability goes down when I go back: This is on a 13.2 system: $ ldd -a pam_ssh.so.5 | fgrep -q 'not found' $ ldd -a pam_ssh.so.5 | fgrep -q 'not found' pam_ssh.so.5: signal 13 $ ldd -a pam_ssh.so.5 | fgrep -q 'not found' pam_ssh.so.5: signal 13 $ ldd -a pam_ssh.so.5 | fgrep -q 'not found' pam_ssh.so.5: signal 13 $ ldd -a pam_ssh.so.5 | fgrep -q 'not found' pam_ssh.so.5: signal 13 $ ldd -a pam_ssh.so.5 | fgrep -q 'not found' pam_ssh.so.5: signal 13 $ ldd -a pam_ssh.so.5 | fgrep -q 'not found' $ ldd -a pam_ssh.so.5 | fgrep -q 'not found' pam_ssh.so.5: signal 13 This is on 11.2: $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' ./pam_ssh.so.5: signal 13 $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' ./pam_ssh.so.5: signal 13 $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' ./pam_ssh.so.5: signal 13 $ ldd -a ./pam_ssh.so.5 | fgrep -q 'not found' ./pam_ssh.so.5: signal 13 On 10.3, the bug didn't trigger at all. I've run ktrace -i on a /bin/sh, where I did the above, and here's the end of kdump -E | egrep 'write|close|pipe|open|shut|read|"' [...] 91610 ld-elf.so.1 4.465551813 RET write 1 91609 fgrep 4.465441180 CALL read(0,0x53c5822404c0,0x8000) 91610 ld-elf.so.1 4.465554672 CALL write(0x1,0x23797c1fb6f,0xe) "libcrypto.so.7" 91610 ld-elf.so.1 4.465566683 RET write 14/0xe 91609 fgrep 4.465559580 GIO fd 0 read 30 bytes "libssh.so.5 => not found (0) " 91609 fgrep 4.465572768 RET read 30/0x1e 91610 ld-elf.so.1 4.465569507 CALL write(0x1,0x23796652eaf,0x1) 91609 fgrep 4.465583554 CALL close(0) " " 91610 ld-elf.so.1 4.465592323 RET write 1 91610 ld-elf.so.1 4.465595462 CALL write(0x1,0x23796652eaf,0x1) 91609 fgrep 4.465606660 RET close 0 "=" 91610 ld-elf.so.1 4.465618571 RET write -1 errno 32 Broken pipe 91608 ldd 4.465734687 CALL write(0x2,0x33e48d760510,0x18) "pam_ssh.so.5: signal 13 " 91608 ldd 4.465751997 RET write 24/0x18 so, once fgrep -q sees the pattern it's looking for, it's essentially done and closes fd 0. Since ld-elf.so.1 is not done yet, and continues writing, it will wind up with SIGPIPE. This should not result in an error message in my opinion... -- You are receiving this mail because: You are the assignee for the bug.
