Fails to open screen terminfo

[leonerd]

Using a Term::Terminfo built against unibilium v2.0.0, it generally works:

$ perl -Mblib -MTerm::Terminfo -E'say for Term::Terminfo->new("vt220")->flag_varnames'
auto_right_margin
...

However it fails to find a plain screen terminfo:

$ perl -Mblib -MTerm::Terminfo -E'say for Term::Terminfo->new("screen")->flag_varnames'
unibi_from_term("screen"): No such file or directory at /home/leo/src/perl/Term-Terminfo/blib/lib/Term/Terminfo.pm line 89.

infocmp -L is able to find such:

$ infocmp -L screen
#       Reconstructed via infocmp from file: /lib/terminfo/s/screen
...

[leonerd]

What is interesting here is that the plain screen info is found in /lib/terminfo/..., where some files are found on my platform. Many more files are found in /usr/share/terminfo/... where unibilium went looking for it, but watching under strace it never tried /lib/terminfo/....

[leonerd]

Oops. Actually that last statement isn't true; sorry. It did try /lib/terminfo, found the file, opened it and read it, then for some reason continued on anyway:

...
openat(AT_FDCWD, "/home/leo/.terminfo/s/screen", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/leo/.terminfo/73/screen", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/terminfo/s/screen", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/terminfo/73/screen", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/terminfo/s/screen", O_RDONLY) = 3
read(3, "\32\1*\0+\0\20\0i\1\231\2screen|VT 100/ANSI X"..., 4096) = 1660
read(3, "", 2436)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/usr/share/terminfo/s/screen", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/terminfo/73/screen", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2995
read(3, "", 4096)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/usr/share/locale/en_GB/LC_MESSAGES/libc.mo", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1433, ...}) = 0
mmap(NULL, 1433, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb6e058e000
close(3)                                = 0
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "unibi_from_term(\"screen\"): No su"..., 124) = 124

[leonerd]

On further investigation I don't believe the location on disk actually matters here, because I can cp the file into $HOME/.terminfo/s/screen and according to strace it attempts to load it from both locations and still fails. I suspect then something in the content of the file it doesn't like. I shall try instrumenting the code more and see what I find out.

[leonerd]

With the code in PR #41 applied, it turns out the failure is an EINVAL:

unibi_from_term("screen"): Invalid argument at /home/leo/src/perl/Term-Terminfo/blib/lib/Term/Terminfo.pm line 89.

There are quite a number of EINVAL-related failures in unibilium.c itself so it's unclear which one is getting upset by my file.

I've attached my offending screen file to this issue, in case you can make more sense of it locally.
screen.gz

(Note I had to gzip it to allow it on github; the original file was not compressed:

$ file /lib/terminfo/s/screen
/lib/terminfo/s/screen: Compiled terminfo entry "screen"

$ sha1sum /lib/terminfo/s/screen
b43375d8185fb26a2f4258639085cc3946e5be41  /lib/terminfo/s/screen

[leonerd]

unibilium: FAIL_IF at unibilium.c:342

which is:

unibilium/unibilium.c

Line 342 in e3b16d6

DEL_FAIL_IF(extofflen != extalllen + extstrslen, EINVAL, t);

Adding some extra printfs in there I get:

extofflen=<18>, extalllen=<16>, extstrslen=<12>

[leonerd]

Ah. On further inspection, this doesn't happen with my debian-installed copy of v2.0.0, only one built from source. This appears to be because debian have patched it:

$ cat debian/patches/0001-Relax-checks-for-extended-capability-to-support-new-.patch 
From d730f881fb9d1fa8c402691240ee795a588a4c22 Mon Sep 17 00:00:00 2001
From: James McCoy <[email protected]>
Date: Sun, 22 Jul 2018 23:08:40 -0400
Subject: [PATCH] Relax checks for extended capability to support new format

In the 20180331 release, the format was slightly changed:

> 20180331
>         + improve terminfo write/read by modifying the fourth item of the
>           extended header to denote the number of valid strings in the extended
>           string table (prompted by a comment in unibilium's sources).

Since the number of valid string capabilities is not necessarily the
same as extstrslen, it's not possible to sanity check the total number
of items up front anymore.

Include a new test with an updated screen terminfo dump.
---
 t/new-extended-format-static_screen.c | 820 ++++++++++++++++++++++++++
 unibilium.c                           |   2 -
 2 files changed, 820 insertions(+), 2 deletions(-)
 create mode 100644 t/new-extended-format-static_screen.c
...

It seems this patch probably ought to be applied upstream.

[jamessan]

That patch is #39.

[leonerd]

Ah; I see there is already a PR for this at #39

[blueyed]

However it fails to find a plain screen terminfo:

I've attached my offending screen file to this issue, in case you can make more sense of it locally.
screen.gz

Where is/was this coming from?
I'll try using this for the test in neovim#5 (continuation of #39) - but wondering where you got it from.