Bug#917592: libterm-termkey-perl: FTBFS (failing tests)

[Niels Thykier]

gregor herrmann:
> On Sat, 29 Dec 2018 16:11:00 +0000, Niels Thykier wrote:
> 
>>>> Does/did it work under nohup (without the
>>>> debhelper work around to make nohup work)?
>>>
>>> Yes, in the same chroot (i.e. with the STDIN redirection commented
>>> out) `TERM=vt100 nohup prove --blib --verbose t/*.t' in d/rules works.
>>>  
>> Now I am even more puzzled.
>>
>> nohup does the eqv. of
>>
>>   open(STDIN, '>', '/dev/null')
>>
>> and libterm-termkey-perl allegedly copes with that!?  Unless the answer
>> is that prove "fixes" this for us and "perl Build test --verbose" (as
>> run by dh_auto_test) does not have the same magic as prove?
> 
> Hm, I don't know what's going on there …
> But maybe I did the test the other way around yesterday?
> 
> So, some more testing:
> 
> Chroot A: my normal sid cowbuilder chroot
> Chroot B: a copy with debhelper installed and the redirect STDIN line
>           in _doit() commented out
> 
> Results for the various option in override_dh_auto_test:
> 
> [...]
> 
> 
> Cheers,
> gregor
> 

Hi,

Basically, the test (t/05flags.t) seg. faults if stdin is a *readable*
non-tty (but succeeds in all other cases).


My recommendation is to use a short term work around by replacing the
dh_auto_test call with the upstream test runner.  This will take the
"edge" off this bug and enable us to debug this issue without the same
pressure with the upcoming freeze.


Anyhow, on to the details I have found:

 * Only test case 05flags.t fails and only if stdin is a *readable*
   non-tty (e.g. /dev/null, an empty file or a non-empty file)

 * It success the moment, stdin is either "left alone" or is a
   "writable" non-tty (0>/dev/null).

 * If the TERM is set to "dump", the test hangs.

 * If the TERM is set to a random / unknown TERM, the test succeeds.
   Presumably termkey does not know the terminal and skips the code
   that crashes.


Stacktrace follows:

"""
(gdb) bt full
#0  termkey_get_flags (tk=0x0) at termkey.c:565
No locals.
#1  0x00007ffff794cba6 in XS_Term__TermKey_get_flags (my_perl=<optimized
out>, cv=<optimized out>) at lib/Term/TermKey.xs:457
        self = <optimized out>
        RETVAL = <optimized out>
        targ = 0x555555ffd9c8
        sp = <optimized out>
        ax = <optimized out>
        mark = <optimized out>
        items = <optimized out>
#2  0x000055555563fd11 in Perl_pp_entersub ()
No symbol table info available.
#3  0x0000555555636026 in Perl_runops_standard ()
No symbol table info available.
#4  0x00005555555b2097 in perl_run ()
No symbol table info available.
#5  0x0000555555588402 in main ()
No symbol table info available.

"""


Compare the following runs:

  TERM=vt100 perl -I blib/arch -Ilib t/05flags.t 0</dev/null

vs.

  TERM=vt100 perl -I blib/arch -Ilib t/05flags.t  0>/dev/null

vs.

  TERM=dumb perl -I blib/arch -Ilib t/05flags.t 0</dev/null

vs.

  TERM=foo perl -I blib/arch -Ilib t/05flags.t 0</dev/null


For the record, this bug could be triggered without the debhelper change
if anyone ever built the package with:

    dpkg-buildpackage -uc -uc </dev/null

(Which apparently no one does - including our buildds, much to my surprise).


Thanks,
~Niels