SIGSEGV with Term::ReadLine call readline() #16800

p5pRT · 2019-01-03T07:18:10Z

Migrated from rt.perl.org#133750 (status was 'rejected')

Searchable as RT133750$

p5pRT · 2019-01-03T07:18:10Z

From rafal@milecki.pl

Created by rafal@milecki.pl

I've written & run a trivial perl script using Term::Readline:

use Term::ReadLine;
my $term = Term::ReadLine->new('foo');
print "term: $term\n";
my $input = $term->readline("Enter something: ");
print "input: $input\n";

When running in on openSUSE with its perl 5.28.1 it crashes and I never get a prompt.

My perl experience is ZERO I'm just trying to debug problem with git-send-email that uses Term::ReadLine.

Hoping for some useful info I've tried running perl in a gdb. Not sure if there is anything useful there.

(gdb) file perl
Reading symbols from perl...Reading symbols from /usr/lib/debug/usr/bin/perl-5.28.1-1.1.x86_64.debug...done.
done.
(gdb) run test.perl
Starting program: /usr/bin/perl test.perl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
term: Term::ReadLine=HASH(0x5555559e1910)
*** buffer overflow detected ***: /usr/bin/perl terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff70474e9 in __GI_abort () at abort.c:79
#2 0x00007ffff70a09a7 in __libc_message (action=<optimized out>, fmt=fmt@entry=0x7ffff71aa2b0 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff713213d in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x7ffff71aa22d "buffer overflow detected") at fortify_fail.c:28
#4 0x00007ffff7132173 in __GI___fortify_fail (msg=msg@entry=0x7ffff71aa22d "buffer overflow detected") at fortify_fail.c:44
#5 0x00007ffff7130252 in __GI___chk_fail () at chk_fail.c:28
#6 0x00007ffff7132067 in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:25
#7 0x00007ffff7005a47 in rl_getc (stream=0x5555559c3ed0) at ../input.c:520
#8 0x00007ffff700635b in rl_read_key () at ../input.c:483
#9 0x00007ffff6fee69a in readline_internal_char () at ../readline.c:573
#10 0x00007ffff6feeeb5 in readline_internal_charloop () at ../readline.c:663
#11 readline_internal () at ../readline.c:677
#12 readline (prompt=<optimized out>) at ../readline.c:376
#13 0x00007ffff7e459af in XS_Term__ReadLine__Gnu__XS_rl_readline (my_perl=<optimized out>, cv=<optimized out>) at Gnu.xs:1317
#14 0x0000555555643521 in Perl_pp_entersub (my_perl=0x555555869260) at pp_hot.c:5232
#15 0x0000555555639836 in Perl_runops_standard (my_perl=0x555555869260) at run.c:42
#16 0x00005555555b5b87 in S_run_body (oldscope=<optimized out>, my_perl=<optimized out>) at perl.c:2694
#17 perl_run (my_perl=0x555555869260) at perl.c:2617
#18 0x000055555558c402 in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at perlmain.c:122

Perl Info


Flags:
     category=core
     severity=medium

Site configuration information for perl 5.28.1:

Configured by reproducible at Fri Nov 30 12:00:00 UTC 2018.

Summary of my perl5 (revision 5 version 28 subversion 1) configuration:

   Platform:
     osname=linux
     osvers=4.19.8-1-default
     archname=x86_64-linux-thread-multi
     uname='reproducible'
     config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl -Dinc_version_list=5.28.0/x86_64-linux-thread-multi 5.28.0'
     hint=recommended
     useposix=true
     d_sigaction=define
     useithreads=define
     usemultiplicity=define
     use64bitint=define
     use64bitall=define
     uselongdouble=undef
     usemymalloc=n
     default_inc_excludes_dot=define
     bincompat5005=undef
   Compiler:
     cc='cc'
     ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
     optimize='-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -Wall -pipe'
     cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong'
     ccversion=''
     gccversion='8.2.1 20181108 [gcc-8-branch revision 265914]'
     gccosandvers=''
     intsize=4
     longsize=8
     ptrsize=8
     doublesize=8
     byteorder=12345678
     doublekind=3
     d_longlong=define
     longlongsize=8
     d_longdbl=define
     longdblsize=16
     longdblkind=3
     ivtype='long'
     ivsize=8
     nvtype='double'
     nvsize=8
     Off_t='off_t'
     lseeksize=8
     alignbytes=8
     prototype=define
   Linker and Libraries:
     ld='cc'
     ldflags =' -L/usr/local/lib64 -fstack-protector-strong'
     libpth=/usr/local/lib /usr/lib64/gcc/x86_64-suse-linux/8/include-fixed /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/lib /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib /lib64 /usr/lib64 /usr/local/lib64
     libs=-lm -ldl -lcrypt -lpthread
     perllibs=-lm -ldl -lcrypt -lpthread
     libc=/lib64/libc-2.27.so
     so=so
     useshrplib=true
     libperl=libperl.so
     gnulibc_version='2.27'
   Dynamic Linking:
     dlsrc=dl_dlopen.xs
     dlext=so
     d_dlsymun=undef
     ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.28.1/x86_64-linux-thread-multi/CORE'
     cccdlflags='-fPIC'
     lddlflags='-shared -L/usr/local/lib64 -fstack-protector-strong'



@INC for perl 5.28.1:
     /usr/lib/perl5/site_perl/5.28.1/x86_64-linux-thread-multi
     /usr/lib/perl5/site_perl/5.28.1
     /usr/lib/perl5/vendor_perl/5.28.1/x86_64-linux-thread-multi
     /usr/lib/perl5/vendor_perl/5.28.1
     /usr/lib/perl5/5.28.1/x86_64-linux-thread-multi
     /usr/lib/perl5/5.28.1
     /usr/lib/perl5/site_perl


Environment for perl 5.28.1:
     HOME=/home/rmilecki
     LANG=en_US.UTF-8
     LANGUAGE=
     LD_LIBRARY_PATH (unset)
     LOGDIR (unset)
     PATH=/home/rmilecki/bin:/usr/local/bin:/usr/bin:/bin
     PERL_BADLANG (unset)
     SHELL=/bin/bash

p5pRT · 2019-01-03T16:32:24Z

From @jkeenan

On Thu, 03 Jan 2019 07:18:10 GMT, rafal@milecki.pl wrote:

This is a bug report for perl from rafal@milecki.pl,
generated with the help of perlbug 1.41 running under perl 5.28.1.

-----------------------------------------------------------------
[Please describe your issue here]

I've written & run a trivial perl script using Term::Readline:

use Term::ReadLine;
my $term = Term::ReadLine->new('foo');
print "term: $term\n";
my $input = $term->readline("Enter something: ");
print "input: $input\n";

When running in on openSUSE with its perl 5.28.1 it crashes and I
never get a prompt.

My perl experience is ZERO I'm just trying to debug problem with git-
send-email that uses Term::ReadLine.

Hoping for some useful info I've tried running perl in a gdb. Not sure
if there is anything useful there.

(gdb) file perl
Reading symbols from perl...Reading symbols from
/usr/lib/debug/usr/bin/perl-5.28.1-1.1.x86_64.debug...done.
done.
(gdb) run test.perl
Starting program: /usr/bin/perl test.perl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
term: Term::ReadLine=HASH(0x5555559e1910)
*** buffer overflow detected ***: /usr/bin/perl terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff70474e9 in __GI_abort () at abort.c:79
#2 0x00007ffff70a09a7 in __libc_message (action=<optimized out>,
fmt=fmt@entry=0x7ffff71aa2b0 "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff713213d in __GI___fortify_fail_abort
(need_backtrace=need_backtrace@entry=true,
msg=msg@entry=0x7ffff71aa22d "buffer overflow detected") at
fortify_fail.c:28
#4 0x00007ffff7132173 in __GI___fortify_fail
(msg=msg@entry=0x7ffff71aa22d "buffer overflow detected") at
fortify_fail.c:44
#5 0x00007ffff7130252 in __GI___chk_fail () at chk_fail.c:28
#6 0x00007ffff7132067 in __fdelt_chk (d=<optimized out>) at
fdelt_chk.c:25
#7 0x00007ffff7005a47 in rl_getc (stream=0x5555559c3ed0) at
../input.c:520
#8 0x00007ffff700635b in rl_read_key () at ../input.c:483
#9 0x00007ffff6fee69a in readline_internal_char () at
../readline.c:573
#10 0x00007ffff6feeeb5 in readline_internal_charloop () at
../readline.c:663
#11 readline_internal () at ../readline.c:677
#12 readline (prompt=<optimized out>) at ../readline.c:376
#13 0x00007ffff7e459af in XS_Term__ReadLine__Gnu__XS_rl_readline
(my_perl=<optimized out>, cv=<optimized out>) at Gnu.xs:1317
#14 0x0000555555643521 in Perl_pp_entersub (my_perl=0x555555869260) at
pp_hot.c:5232
#15 0x0000555555639836 in Perl_runops_standard
(my_perl=0x555555869260) at run.c:42
#16 0x00005555555b5b87 in S_run_body (oldscope=<optimized out>,
my_perl=<optimized out>) at perl.c:2694
#17 perl_run (my_perl=0x555555869260) at perl.c:2617
#18 0x000055555558c402 in main (argc=<optimized out>, argv=<optimized
out>, env=<optimized out>) at perlmain.c:122

Thank you for the report. In a case like yours, where you are (I think) using a vendor-supplied 'perl' executable that was built with many configuration options, we often have to experiment with building 'perl' with a shorter list of configuration options in order to determine whether one or more of those config options is the cause of the crash.

As a first stab at this, I configured Perl 5 blead with the following options on both Ubuntu Linux 18.04 LTS and FreeBSD-11.2:

#####
sh ./Configure -des -Dusedevel -Duseithreads -Dcc=gcc-8 -DPERL_USE_SAFE_PUTENV
#####

I then tried your test program on each OS. Neither crashed.

p5p list: Any ideas?

Original poster: If you are familiar with 'git', you might want to do a checkout of the Perl 5 source code (git clone git://perl5.git.perl.org/perl.git perl) so that, should we come up with a solution, we can have you test that solution on your machine.

Thank you very much.
--
James E Keenan (jkeenan@cpan.org)

p5pRT · 2019-01-03T16:32:24Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2019-01-04T08:21:46Z

From carenas@gmail.com

this might be a problem with libreadline that is manifesting in openSUSE Tumbleweed as described in :

https://bugzilla.opensuse.org/show_bug.cgi?id=1120267

p5pRT · 2019-01-04T09:43:12Z

From @ppisar

On 2019-01-03, "James E Keenan via RT" <perlbug-followup@perl.org> wrote:

On Thu, 03 Jan 2019 07:18:10 GMT, rafal@milecki.pl wrote:

This is a bug report for perl from rafal@milecki.pl,
generated with the help of perlbug 1.41 running under perl 5.28.1.
[...]
(gdb) run test.perl
Starting program: /usr/bin/perl test.perl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
term: Term::ReadLine=HASH(0x5555559e1910)
*** buffer overflow detected ***: /usr/bin/perl terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff70474e9 in __GI_abort () at abort.c:79
#2 0x00007ffff70a09a7 in __libc_message (action=<optimized out>,
fmt=fmt@entry=0x7ffff71aa2b0 "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff713213d in __GI___fortify_fail_abort
(need_backtrace=need_backtrace@entry=true,
msg=msg@entry=0x7ffff71aa22d "buffer overflow detected") at
fortify_fail.c:28
#4 0x00007ffff7132173 in __GI___fortify_fail
(msg=msg@entry=0x7ffff71aa22d "buffer overflow detected") at
fortify_fail.c:44
#5 0x00007ffff7130252 in __GI___chk_fail () at chk_fail.c:28
#6 0x00007ffff7132067 in __fdelt_chk (d=<optimized out>) at
fdelt_chk.c:25
#7 0x00007ffff7005a47 in rl_getc (stream=0x5555559c3ed0) at
../input.c:520
#8 0x00007ffff700635b in rl_read_key () at ../input.c:483
#9 0x00007ffff6fee69a in readline_internal_char () at
../readline.c:573
#10 0x00007ffff6feeeb5 in readline_internal_charloop () at
../readline.c:663
#11 readline_internal () at ../readline.c:677
#12 readline (prompt=<optimized out>) at ../readline.c:376
#13 0x00007ffff7e459af in XS_Term__ReadLine__Gnu__XS_rl_readline
(my_perl=<optimized out>, cv=<optimized out>) at Gnu.xs:1317
#14 0x0000555555643521 in Perl_pp_entersub (my_perl=0x555555869260) at
pp_hot.c:5232
#15 0x0000555555639836 in Perl_runops_standard
(my_perl=0x555555869260) at run.c:42
#16 0x00005555555b5b87 in S_run_body (oldscope=<optimized out>,
my_perl=<optimized out>) at perl.c:2694
#17 perl_run (my_perl=0x555555869260) at perl.c:2617
#18 0x000055555558c402 in main (argc=<optimized out>, argv=<optimized
out>, env=<optimized out>) at perlmain.c:122

Thank you for the report. In a case like yours, where you are (I
think) using a vendor-supplied 'perl' executable that was built with
many configuration options, we often have to experiment with building
'perl' with a shorter list of configuration options in order to
determine whether one or more of those config options is the cause of
the crash.

As a first stab at this, I configured Perl 5 blead with the following
options on both Ubuntu Linux 18.04 LTS and FreeBSD-11.2:

#####
sh ./Configure -des -Dusedevel -Duseithreads -Dcc=gcc-8 -DPERL_USE_SAFE_PUTENV
#####

I then tried your test program on each OS. Neither crashed.

The backtrace shows the "crash" is an intentional abort triggered by
a heuristic when calling libreadline's rl_getc().

The heuristic is enabled by hardening GCC flags (like
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-fstack-clash-protection -fcf-protection) and/or by a linked-in a hardened
glibc code (an interposed or an in-lined function).

The backtrace mentions __fdelt_chk(). A web search returns e.g. this
implementation
<https://github.com/lattera/glibc/blob/master/debug/fdelt_chk.c>. The
code checks if a file descriptor passed in a file descriptor set to select(2)
syscall is valid. Using select(2) to wait for reading a character from
a descriptor looks like a reasonable rl_getc()'s job.

I guess some code does not set the stdin file descriptor properly.

-- Petr

p5pRT · 2019-01-04T09:54:12Z

From @ppisar

On 2019-01-04, Petr Pisar <ppisar@redhat.com> wrote:

The heuristic is enabled by hardening GCC flags (like
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-fstack-clash-protection -fcf-protection)

These flags are just an example. (I'm unable to reproduce it with them
on Fedora 30). You can obtain flags used for building
your perl with "perl -V | grep flags" shell command.

You should also contact your package vendor (SuSE). It's quite possible
that the vendor will be able to reproduce and debug this issue.

-- Petr

p5pRT · 2019-01-04T14:57:17Z

From rafal@milecki.pl

On Fri, 04 Jan 2019 01:54:12 -0800, ppisar wrote:

These flags are just an example. (I'm unable to reproduce it with them
on Fedora 30). You can obtain flags used for building
your perl with "perl -V | grep flags" shell command.

perl -V | grep flags
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl -Dinc_version_list=5.28.0/x86_64-linux-thread-multi 5.28.0'
ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong'
ldflags =' -L/usr/local/lib64 -fstack-protector-strong'
ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.28.1/x86_64-linux-thread-multi/CORE'
cccdlflags='-fPIC'
lddlflags='-shared -L/usr/local/lib64 -fstack-protector-strong'

You should also contact your package vendor (SuSE). It's quite possible
that the vendor will be able to reproduce and debug this issue.

I've created openSUSE report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1120759

p5pRT · 2019-01-04T15:01:25Z

From rafal@milecki.pl

On Thu, 03 Jan 2019 08:32:24 -0800, jkeenan wrote:

Original poster: If you are familiar with 'git', you might want to do
a checkout of the Perl 5 source code (git clone
git://perl5.git.perl.org/perl.git perl) so that, should we come up
with a solution, we can have you test that solution on your machine.

I've just tried compiling perl from git using your config options:

cd ~/linux/
git clone git://perl5.git.perl.org/perl.git
cd perl
./Configure -des -Dusedevel -Duseithreads -Dcc=gcc-8 -DPERL_USE_SAFE_PUTENV
make -j 8

Then tested my sample script and it works fine!

PERL5LIB=~/linux/perl/lib ~/linux/perl/perl ~/test.perl
term: Term::ReadLine::Stub=ARRAY(0x24ea960)
Enter something: Foo
input: Foo

So it appears my gcc / glibc / libreadline are fine.

I've also tried compiling from the v5.28.1 tag and it also works!

My last guess is there is something in the way openSUSE compiler perl that triggers this problem.

p5pRT · 2019-01-04T16:10:04Z

From @jkeenan

On Fri, 04 Jan 2019 15:01:25 GMT, rafal@milecki.pl wrote:

On Thu, 03 Jan 2019 08:32:24 -0800, jkeenan wrote:

Original poster: If you are familiar with 'git', you might want to
do
a checkout of the Perl 5 source code (git clone
git://perl5.git.perl.org/perl.git perl) so that, should we come up
with a solution, we can have you test that solution on your machine.

I've just tried compiling perl from git using your config options:

cd ~/linux/
git clone git://perl5.git.perl.org/perl.git
cd perl
./Configure -des -Dusedevel -Duseithreads -Dcc=gcc-8
-DPERL_USE_SAFE_PUTENV
make -j 8

Then tested my sample script and it works fine!

PERL5LIB=~/linux/perl/lib ~/linux/perl/perl ~/test.perl
term: Term::ReadLine::Stub=ARRAY(0x24ea960)
Enter something: Foo
input: Foo

So it appears my gcc / glibc / libreadline are fine.

I've also tried compiling from the v5.28.1 tag and it also works!

My last guess is there is something in the way openSUSE compiler perl
that triggers this problem.

Thanks for filing the SUSE bug report and for your further investigation.

Because the resolution of this issue awaits investigation by the downstream packager, I'm classifying this ticket as Stalled.

Thank you very much.

--
James E Keenan (jkeenan@cpan.org)

p5pRT · 2019-01-04T16:10:04Z

@jkeenan - Status changed from 'open' to 'stalled'

p5pRT · 2019-01-05T10:50:58Z

From rafal@milecki.pl

I'm incapable of debugging this and I'm giving up at this point :( I simply can't reproduce this problem when compiling perl on my own.

1) I've checkouted perl5 sources

2) I've applied all openSUSE patches:
patch -p0 < perl-5.28.0.dif
patch -p0 < perl-regexp-refoverflow.diff
patch -p0 < perl-nroff.diff
patch -p0 < perl-netcmdutf8.diff
patch -p0 < perl-HiRes.t-timeout.diff
patch -p0 < perl-saverecontext.diff
patch -p0 < perl-5.22.0_wrong_rpm_provides.diff
patch -p0 < perl-incfix.diff
patch -p0 < perl-5.18.2-overflow.diff
patch -p1 < perl-reproducible.patch
patch -p1 < posix-sigaction.patch
patch -p0 < perl-gdbm-test-no-mmap.diff
patch -p0 < perl-revert-caretx.diff

3) I've tried to configure perl5 using the same options as openSUSE:
./Configure -ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize="-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -Wall -pipe" -Accflags=-DPERL_USE_SAFE_PUTENV

4) I've compiled it (make) and tested:
LD_LIBRARY_PATH=~~/linux/perl/ PERL5LIB=~~/linux/perl/lib ~/linux/perl/perl ~/test.perl

It works perfectly fine. I've no idea what's wrong with the openSUSE perl build.

p5pRT · 2019-01-05T10:50:58Z

The RT System itself - Status changed from 'stalled' to 'open'

p5pRT · 2019-01-12T23:33:54Z

From rafal@milecki.pl

This problem has appeared to be related to (or caused by) an outdated Term-ReadLine-Gnu version (1.20) provided by openSUSE.

I've tested the latest Term-ReadLine-Gnu and bisected to find fixing commits.

Release 1.23 has fixed a crash with a commit:
r460 ("fix not to clobber binmode layer (utf-8) on filehandles")
https://sourceforge.net/p/perl-trg/code/460/

Unfortunately that wasn't a real/complete fix as it made readline() just return immediately an empty value.

Release 1.26 provided a real fix with a commit:
r481 ("make handling of iostreams simple (make _rl_store_iostream() return void and remove _rl_fetch_iostream()) [rt.cpan.org #101078]")
https://sourceforge.net/p/perl-trg/code/481/

Starting with that change calling readline() allows user to provide an input as expected.

Thanks everyone involved into this debugging, I believe it's up to the openSUSE to update Term-ReadLine-Gnu now.

p5pRT · 2019-01-23T03:56:41Z

From @tonycoz

On Sat, 12 Jan 2019 15:33:54 -0800, rafal@milecki.pl wrote:

This problem has appeared to be related to (or caused by) an outdated
Term-ReadLine-Gnu version (1.20) provided by openSUSE.

I've tested the latest Term-ReadLine-Gnu and bisected to find fixing
commits.

Release 1.23 has fixed a crash with a commit:
r460 ("fix not to clobber binmode layer (utf-8) on filehandles")
https://sourceforge.net/p/perl-trg/code/460/

Unfortunately that wasn't a real/complete fix as it made readline()
just return immediately an empty value.

Release 1.26 provided a real fix with a commit:
r481 ("make handling of iostreams simple (make _rl_store_iostream()
return void and remove _rl_fetch_iostream()) [rt.cpan.org #101078]")
https://sourceforge.net/p/perl-trg/code/481/

Starting with that change calling readline() allows user to provide an
input as expected.

Thanks everyone involved into this debugging, I believe it's up to the
openSUSE to update Term-ReadLine-Gnu now.

Thanks for the update.

Since this isn't a bug in perl, and appears to have been fixed upstream, and we aren't the upstream, I'm rejecting this issue.

Tony

p5pRT · 2019-01-23T03:56:42Z

@tonycoz - Status changed from 'open' to 'rejected'

p5pRT closed this as completed Jan 23, 2019

p5pRT added Severity Medium type-core labels Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SIGSEGV with Term::ReadLine call readline() #16800

SIGSEGV with Term::ReadLine call readline() #16800

p5pRT commented Jan 3, 2019

p5pRT commented Jan 3, 2019

p5pRT commented Jan 3, 2019

p5pRT commented Jan 3, 2019

p5pRT commented Jan 4, 2019

p5pRT commented Jan 4, 2019

p5pRT commented Jan 4, 2019

p5pRT commented Jan 4, 2019

p5pRT commented Jan 4, 2019

p5pRT commented Jan 4, 2019

p5pRT commented Jan 4, 2019

p5pRT commented Jan 5, 2019

p5pRT commented Jan 5, 2019

p5pRT commented Jan 12, 2019

p5pRT commented Jan 23, 2019

p5pRT commented Jan 23, 2019

SIGSEGV with Term::ReadLine call readline() #16800

SIGSEGV with Term::ReadLine call readline() #16800

Comments

p5pRT commented Jan 3, 2019

p5pRT commented Jan 3, 2019

From rafal@milecki.pl

Created by rafal@milecki.pl

p5pRT commented Jan 3, 2019

From @jkeenan

p5pRT commented Jan 3, 2019

p5pRT commented Jan 4, 2019

From carenas@gmail.com

p5pRT commented Jan 4, 2019

From @ppisar

p5pRT commented Jan 4, 2019

From @ppisar

p5pRT commented Jan 4, 2019

From rafal@milecki.pl

p5pRT commented Jan 4, 2019

From rafal@milecki.pl

p5pRT commented Jan 4, 2019

From @jkeenan

p5pRT commented Jan 4, 2019

p5pRT commented Jan 5, 2019

From rafal@milecki.pl

p5pRT commented Jan 5, 2019

p5pRT commented Jan 12, 2019

From rafal@milecki.pl

p5pRT commented Jan 23, 2019

From @tonycoz

p5pRT commented Jan 23, 2019