diff options
| author | David Mitchell <davem@iabyn.com> | 2010-03-30 15:03:50 +0100 |
|---|---|---|
| committer | David Mitchell <davem@iabyn.com> | 2010-03-30 15:03:50 +0100 |
| commit | 099be4f1d597471eb719c9a344b7c1b55e11ba24 (patch) | |
| tree | 46ddeb749d35c52c3df9d34f54e7200aef8ddbcf /pp_hot.c | |
| parent | 447ee1343739cf8e34c4ff1ba9b30eae75c3f1ab (diff) | |
| download | perl-099be4f1d597471eb719c9a344b7c1b55e11ba24.tar.gz | |
PL_defoutgv isn't always a GV.
Nasty code like the following results in PL_defoutgv not pointing
to a valid GV:
my $x = *STDERR; select($x); $x = 1;
This causes all sorts of SEGVs when PL_defoutgv is subsequently accessed,
because most code assumes that it has a valid gv_gp pointer. It also
turns out that PL_defoutgv is under-tested; for example, temporarily
hacking pp_close to make an arg-less close() croak didn't cause any
minitest failures.
Add a new test file that does some basic testing of a bad PL_defoutgv,
and fix all the obvious badness in accessing it.
This also fixes #20727, which although ostensibly a tie bug, was due to
PL_defoutgv pointing to a tiedelem scalar, and fun like that described
above happening.
Diffstat (limited to 'pp_hot.c')
| -rw-r--r-- | pp_hot.c | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -734,7 +734,7 @@ PP(pp_print) RETURN; } if (!(io = GvIO(gv))) { - if ((GvEGV(gv)) && (io = GvIO(GvEGV(gv))) + if ((GvEGVx(gv)) && (io = GvIO(GvEGV(gv))) && (mg = SvTIED_mg((const SV *)io, PERL_MAGIC_tiedscalar))) goto had_magic; if (ckWARN2(WARN_UNOPENED,WARN_CLOSED)) |