write(FH) on closed FH cuases segv #2977

p5pRT · 2000-12-10T11:54:20Z

Migrated from rt.perl.org#4893 (status was 'resolved')

Searchable as RT4893$

p5pRT · 2000-12-10T11:54:20Z

From @mjdominus

Created by @mjdominus

The write() itself doesn't cause the segv; it's just silently
ignored. Rather, when you write past the end of the 'page',
Perl tries to invoke the FH_TOP format automatically, and that cuases
the segv.

I tried to fix it, but it turned out to be more complicated than I
thought. Enclosed is a patch to t/op/misc.t that installs a test case
for this bug.

--- t/op/misc.t 2000/12/10 19:48:23 1.1
+++ t/op/misc.t 2000/12/10 19:51:08 1.2
@@ -545,3 +545,23 @@
lcfirst - world
uc - WORLD
lc - world
+########
+# 20001210 mjd@plover.com
+format REMITOUT_TOP =
+FOO
+.
+
+format REMITOUT =
+BAR
+.
+
+# This loop causes a segv in 5.6.0
+for $lineno (1..61) {
+ write REMITOUT;
+}
+
+print "It's OK!";
+EXPECT
+It's OK!
+
+

Perl Info


Flags:
    category=core
    severity=medium

Site configuration information for perl v5.6.0:

Configured by mjd at Wed Sep 20 15:34:29 EDT 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.2.16, archname=i586-linux
    uname='linux plover 2.2.16 #97 fri jun 16 19:45:30 pdt 2000 i586 unknown '
    config_args='-Doptimize=-g -des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define 
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler:
    cc='cc', optimize='-g', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
    cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include'
    ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
    libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.0:
    /usr/local/lib/perl5/5.6.0/i586-linux
    /usr/local/lib/perl5/5.6.0
    /usr/local/lib/perl5/site_perl/5.6.0/i586-linux
    /usr/local/lib/perl5/site_perl/5.6.0
    /usr/local/lib/perl5/site_perl/5.00557/i586-linux
    /usr/local/lib/perl5/site_perl/5.00557
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.6.0:
    HOME=/home/mjd
    LANG (unset)
    LANGUAGE (unset)
    LC_ALL=POSIX
    LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib
    LOGDIR (unset)
    PATH=/home/mjd/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11/bin:/usr/games:/sbin:/usr/sbin:/usr/local/bin/X11:/usr/local/bin/mh:/data/mysql/bin:/usr/local/bin/pbm:/usr/local/bin/ezmlm:/home/mjd/TPI/bin:/usr/local/mysql/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2000-12-10T14:39:21Z

From [Unknown Contact. See original ticket]

<mjd@plover.com> writes:

This is a bug report for perl from mjd@plover.plover.com,
generated with the help of perlbug 1.28 running under perl v5.6.0.

-----------------------------------------------------------------
[Please enter your report here]

The write() itself doesn't cause the segv; it's just silently
ignored. Rather, when you write past the end of the 'page',
Perl tries to invoke the FH_TOP format automatically, and that cuases
the segv.

Having just visited the format code to make it utf8 aware I am not
in the least surprised by the bug.

It is just possible that it got fixed as a result of what I did,
if not I am more or less up to speed.

Thanks for the test though.

I tried to fix it, but it turned out to be more complicated than I
thought. Enclosed is a patch to t/op/misc.t that installs a test case
for this bug.

--- t/op/misc.t 2000/12/10 19:48:23 1.1
+++ t/op/misc.t 2000/12/10 19:51:08 1.2
@@ -545,3 +545,23 @@
lcfirst - world
uc - WORLD
lc - world
+########
+# 20001210 mjd@plover.com
+format REMITOUT_TOP =
+FOO
+.
+
+format REMITOUT =
+BAR
+.
+
+# This loop causes a segv in 5.6.0
+for $lineno (1..61) {
+ write REMITOUT;
+}
+
+print "It's OK!";
+EXPECT
+It's OK!
+
+

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.6.0:

Configured by mjd at Wed Sep 20 15:34:29 EDT 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.2.16, archname=i586-linux
uname='linux plover 2.2.16 #97 fri jun 16 19:45:30 pdt 2000 i586 unknown '
config_args='-Doptimize=-g -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='cc', optimize='-g', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include'
ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:

---
@INC for perl v5.6.0:
/usr/local/lib/perl5/5.6.0/i586-linux
/usr/local/lib/perl5/5.6.0
/usr/local/lib/perl5/site_perl/5.6.0/i586-linux
/usr/local/lib/perl5/site_perl/5.6.0
/usr/local/lib/perl5/site_perl/5.00557/i586-linux
/usr/local/lib/perl5/site_perl/5.00557
/usr/local/lib/perl5/site_perl
.

---
Environment for perl v5.6.0:
HOME=/home/mjd
LANG (unset)
LANGUAGE (unset)
LC_ALL=POSIX
LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib
LOGDIR (unset)
PATH=/home/mjd/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11/bin:/usr/games:/sbin:/usr/sbin:/usr/local/bin/X11:/usr/local/bin/mh:/data/mysql/bin:/usr/local/bin/pbm:/usr/local/bin/ezmlm:/home/mjd/TPI/bin:/usr/local/mysql/bin
PERL_BADLANG (unset)
SHELL=/bin/bash

p5pRT · 2000-12-10T14:45:30Z

From @mjdominus

It is just possible that it got fixed as a result of what I did,
if not I am more or less up to speed.

I really doubt it. It has to do with perl getting a NULL stream
object and then passing the null pointer to PerlIO_write. The dump
occurs at pp_sys.c:1247:

if (IoLINES_LEFT(io) >= 0 && IoPAGE(io) > 0)
PerlIO_write(ofp, SvPVX(PL_formfeed), SvCUR(PL_formfeed));

I tried guarding this with a test for null 'ofp':

if (IoLINES_LEFT(io) >= 0 && IoPAGE(io) > 0)
if (ofp)
PerlIO_write(ofp, SvPVX(PL_formfeed), SvCUR(PL_formfeed));
else if (ckWARN(WARN_CLOSED))
report_closed_fh(gv, io, "write", "filehandle");

but that wasn't enough; there's something else going on also. I
investigated further, but wasn't able to figure it out.

Anyway, I don't think it was your fault, and just to be sure, I
checked it with 5.000, which aldso exhibits the problem.

p5pRT · 2000-12-11T01:10:23Z

From [Unknown Contact. See original ticket]

Mark-Jason Dominus <mjd@plover.com> writes:

It is just possible that it got fixed as a result of what I did,
if not I am more or less up to speed.

I really doubt it. It has to do with perl getting a NULL stream
object and then passing the null pointer to PerlIO_write.

I guessed as much - which is why I think it may be fixed ;-)
With the utf8 patches there are _NO_ calls to PerlIO_write() in the
format code - they have all become calls to do_print(), so (depending
on where check for NULL fp is) the problem has at least moved...

Anyway, I don't think it was your fault, and just to be sure, I
checked it with 5.000, which aldso exhibits the problem.

I am sure it wasn't my fault - I have never been near that code before ... :-)

p5pRT · 2000-12-11T07:39:22Z

From @mjdominus

I guessed as much - which is why I think it may be fixed ;-)

Sorry; I somehow read 'broken' where you had 'fixed'. The rest of my
response makes no sense without this.

p5pRT · 2000-12-11T11:58:30Z

From @jhi

On Mon, Dec 11, 2000 at 10:39:35AM -0500, Mark-Jason Dominus wrote:

I guessed as much - which is why I think it may be fixed ;-)

Sorry; I somehow read 'broken' where you had 'fixed'. The rest of my
response makes no sense without this.

I tried it out and it doesn't seem to be fixed yet...

p5pRT · 2012-08-05T20:01:32Z

From @cpansprout

The crash was fixed in 7ef822c, but ticket #17099 says there is
still a memory leak.

--

Father Chrysostomos

p5pRT closed this as completed Nov 28, 2003

p5pRT added Severity Medium distro-Linux type-library labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

write(FH) on closed FH cuases segv #2977

write(FH) on closed FH cuases segv #2977

p5pRT commented Dec 10, 2000

p5pRT commented Dec 10, 2000

p5pRT commented Dec 10, 2000

p5pRT commented Dec 10, 2000

p5pRT commented Dec 11, 2000

p5pRT commented Dec 11, 2000

p5pRT commented Dec 11, 2000

p5pRT commented Aug 5, 2012

write(FH) on closed FH cuases segv #2977

write(FH) on closed FH cuases segv #2977

Comments

p5pRT commented Dec 10, 2000

p5pRT commented Dec 10, 2000

From @mjdominus

Created by @mjdominus

p5pRT commented Dec 10, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Dec 10, 2000

From @mjdominus

p5pRT commented Dec 11, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Dec 11, 2000

From @mjdominus

p5pRT commented Dec 11, 2000

From @jhi

p5pRT commented Aug 5, 2012

From @cpansprout