Bug#890355: man: nroff: Bad system call

[Thorsten Glaser]

Hi Colin,

> Hmm.  So I just dug out the VM that I'd been using to look into this,
> brought it up to date, and found that man works fine for me: this is a
> sid x32 chroot on a stretch amd64 base system running a 4.9.0-4-amd64
> kernel. So that means I'm sort of stalled on this for now: perhaps

Hmm. I’m using the sid kernel; unclear if that makes a difference,
but new kernels have been known to either fix or introduce problems
specific to x32, e.g. audio was totally broken for some time.

> In the meantime, you can add MAN_DISABLE_SECCOMP=1 to your environment
> as a workaround (but please remember to remove that again once I release
> 2.8.3 so that we can tell whether it fixes the problems).

Thanks, that indeed helps (and thus confirms that this was the
particular problem).

> it's worth seeing if any of the other fixes in 2.8.3 happen to cover
> this? The strace shows nroff being killed by SIGSYS immediately after
> the execve, with no indication of what system call it attempted that
> failed, but if it's the clock_gettime thing I speculated on earlier
> then
> https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=770cd67aaf711b2cded9cbc2f9e503ca0f5e73ba
> should fix it.

Interesting. People not only mix and match for performance reasons
but also due to bugs, etc. and because x32 isn’t a full architecture
in the first place anyway.

Hmm, let me see…

tglase@tglase:~ $ file /usr/bin/nroff
/usr/bin/nroff: POSIX shell script, ASCII text executable

Ah-hah! My /bin/sh is indeed klibc-built, and klibc pretends x32
is amd64 because it lacks x32 support (despite klibc’s author being
the person behind x32…).

If I temporarily symlink /bin/sh to bash, man works (I removed the
export from above *and* tested that it indeed fails, just to make
sure), so, yes, this would do the trick.

Thanks!

(I’ll take the reply to the other issue separately.)

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#890355: man: nroff: Bad system call

[Colin Watson]

On Wed, Apr 04, 2018 at 06:35:12PM +, Thorsten Glaser wrote:
> Hi Colin,
> >tglase@tglase:~ $ man ls
> >man: nroff: Bad system call
> > Manual page ls(1) line ?/? (END) (press h for help or q to quit)
> 
> any progress on this? Can I disable the seccomp stuff locally,
> using a configuration file or something? It’s kinda annoying
> after a while, on my $dayjob desktop which uses x32.

Hmm.  So I just dug out the VM that I'd been using to look into this,
brought it up to date, and found that man works fine for me: this is a
sid x32 chroot on a stretch amd64 base system running a 4.9.0-4-amd64
kernel.  So that means I'm sort of stalled on this for now: perhaps it's
worth seeing if any of the other fixes in 2.8.3 happen to cover this?
The strace shows nroff being killed by SIGSYS immediately after the
execve, with no indication of what system call it attempted that failed,
but if it's the clock_gettime thing I speculated on earlier then
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=770cd67aaf711b2cded9cbc2f9e503ca0f5e73ba
should fix it.

In the meantime, you can add MAN_DISABLE_SECCOMP=1 to your environment
as a workaround (but please remember to remove that again once I release
2.8.3 so that we can tell whether it fixes the problems).

> Also, this might be related: I see this at the tail of a failed
> buildd log, for sh4, on a buildd which uses qemu:
> 
>dh_installman -a -O--buildsystem=cmake
> man: ../../../src/man.c:2334: display: Assertion `man_file' failed.

This is unrelated.  I just went through the code and I can't see any
possible path that would cause this assertion to fail, but perhaps you
could file a separate bug for this?

> qemu: uncaught target signal 6 (Aborted) - core dumped
> dh_installman: man -l --recode UTF-8 
> ./debian/musescore/usr/share/man/man1/mscore.1.gz > 
> debian/musescore/usr/share/man/man1/mscore.1.gz.dh-new died with signal 6
> dh_installman: Aborting due to earlier error
> make: *** [debian/rules:10: binary-arch] Error 2
> 
> Perhaps seccomp is confusing qemu here, too?

I doubt it - that's just qemu getting SIGABRT due to a failed assert,
which seems normal.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#890355: man: nroff: Bad system call

[Thorsten Glaser]

Hi Colin,

>tglase@tglase:~ $ man ls
>man: nroff: Bad system call
> Manual page ls(1) line ?/? (END) (press h for help or q to quit)

any progress on this? Can I disable the seccomp stuff locally,
using a configuration file or something? It’s kinda annoying
after a while, on my $dayjob desktop which uses x32.


Also, this might be related: I see this at the tail of a failed
buildd log, for sh4, on a buildd which uses qemu:

   dh_installman -a -O--buildsystem=cmake
man: ../../../src/man.c:2334: display: Assertion `man_file' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
dh_installman: man -l --recode UTF-8 
./debian/musescore/usr/share/man/man1/mscore.1.gz > 
debian/musescore/usr/share/man/man1/mscore.1.gz.dh-new died with signal 6
dh_installman: Aborting due to earlier error
make: *** [debian/rules:10: binary-arch] Error 2

Perhaps seccomp is confusing qemu here, too?

Thanks in advance,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#890355: man: nroff: Bad system call

[Colin Watson]

On Wed, Feb 14, 2018 at 03:26:31AM +0100, Thorsten Glaser wrote:
> Hrm.…
> 
> > Sure, it’s attached, and it seems really weird…
> 
> … I had thought someone had defined NULL as just 0
> (although dalias makes a good argument for it) and
> it was passed as a too-short sentinel, but it uses
> execve, so that was not it.
> 
> But I see a lot of seccomp stuff in there, which,
> obviously, is not there when I just run it from the
> shell. Syscall numbers on x32 differ, so perhaps,
> that is already the culprit?

I have a feeling that this is basically another iteration of
https://bugs.debian.org/850047.  While building a system to test it,
though, I ran into apt's seccomp sandbox also being broken on x32 (very
likely for the same kind of reason), so I'm yak-shaving my way towards
this ...

-- 
Colin Watson   [cjwat...@debian.org]

Bug#890355: man: nroff: Bad system call

[Thorsten Glaser]

Hrm.…

> Sure, it’s attached, and it seems really weird…

… I had thought someone had defined NULL as just 0
(although dalias makes a good argument for it) and
it was passed as a too-short sentinel, but it uses
execve, so that was not it.

But I see a lot of seccomp stuff in there, which,
obviously, is not there when I just run it from the
shell. Syscall numbers on x32 differ, so perhaps,
that is already the culprit?

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Bug#890355: man: nroff: Bad system call

[Colin Watson]

On Tue, Feb 13, 2018 at 09:55:36PM +0100, Thorsten Glaser wrote:
> tglase@tglase:~ $ man ls
> man: nroff: Bad system call
>  Manual page ls(1) line ?/? (END) (press h for help or q to quit)

This test case works fine for me; perhaps there's something about x32
that matters here.  Could you please try this, which will hopefully also
fail, and then attach man-ls.trace to this bug?

  strace -f -o man-ls.trace -s 1024 man ls

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#890355: man: nroff: Bad system call

[Thorsten Glaser]

Package: man-db
Version: 2.8.1-1
Severity: grave
Justification: renders package unusable

-begin screenshot-
tglase@tglase:~ $ man ls
man: nroff: Bad system call
 Manual page ls(1) line ?/? (END) (press h for help or q to quit)
-end screenshot-

This one works, though:
tglase@tglase:~ $ zcat /usr/share/man/man1/ls.1.gz | nroff -mandoc


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2
ii  debconf [debconf-2.0]  1.5.65
ii  dpkg   1.19.0.5
ii  groff-base 1.22.3-10
ii  libc6  2.26-6
ii  libgdbm5   1.14.1-3
ii  libpipeline1   1.5.0-1
ii  libseccomp22.3.1-2.1
ii  zlib1g 1:1.2.8.dfsg-5

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor
ii  dillo [www-browser] 3.0.5-4
ii  groff   1.22.3-10
ii  less487-0.1
ii  links2 [www-browser]2.14-5
ii  lynx [www-browser]  2.8.9dev16-2
ii  opera-static [www-browser]  9.64.2480.gcc4.qt3

-- debconf information:
  man-db/install-setuid: false
  man-db/auto-update: true