gv_try_downgrade leaves dangling pointers during global destruction

[p5pRT]

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

Searchable as RT78192$

[p5pRT]

From @cpansprout

If a subroutine contains an op that references a downgradable GV, then gv_try_downgrade, if called on that GV during global destruction, *might* leave dangling pointers elsewhere; where exactly I wot not.

This only happens in non-threaded builds and with PERL_DESTRUCT_LEVEL set to 2 (as in make test).

This was causing t/op/gv.t to give this assertion​:

Assertion failed​: (SvTYPE(sv) != SVTYPEMASK), function Perl_sv_clear, file sv.c, line 5783.

This started with commit 13be902 (lvalue-to-glob assigment), but only because of the tests it added.

It was actually caused by f746176, which added gv_try_downgrade.

I’ve made gv_try_downgrade simply return during global destruction with commit 95f5675.

This ticket is a reminder that those dangling pointers need to be dealt with some day. (I still think gv_try_downgrade should be skipped during global destruction, regardless.)

To reproduce, delete the following line from gv.c​:Perl_gv_try_downgrade​:

  if (PL_dirty) return;

Then compile perl with -DDEBUGGING (but without threads) and run​:

  cd t; PERL_DESTRUCT_LEVEL=2 ./perl harness -v op/gv.t

---

Flags​:
  category=core
  severity=low

---

This perlbug was built using Perl 5.10.1 - Thu Sep 24 18​:07​:44 PDT 2009
It is being executed now by Perl 5.13.5 - Fri Oct 1 09​:23​:16 PDT 2010.

Site configuration information for perl 5.13.5​:

Configured by sprout at Fri Oct 1 09​:23​:16 PDT 2010.

Summary of my perl5 (revision 5 version 13 subversion 5) configuration​:
  Local Commit​: 4bc6ae2d6cbb928e4a57ec20039fa8fa8dfc2003
  Ancestor​: 95f5675
  Platform​:
  osname=darwin, osvers=10.4.0, archname=darwin-2level
  uname='darwin pint.local 10.4.0 darwin kernel version 10.4.0​: fri apr 23 18​:28​:53 pdt 2010; root​:xnu-1504.7.4~1release_i386 i386 '
  config_args='-de -Dusedevel -DDEBUGGING'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
  optimize='-O3 -g',
  cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib
  libs=-ldbm -ldl -lm -lutil -lc
  perllibs=-ldl -lm -lutil -lc
  libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Locally applied patches​:
 

---

@​INC for perl 5.13.5​:
  lib
  /usr/local/lib/perl5/site_perl/5.13.5/darwin-2level
  /usr/local/lib/perl5/site_perl/5.13.5
  /usr/local/lib/perl5/5.13.5/darwin-2level
  /usr/local/lib/perl5/5.13.5
  /usr/local/lib/perl5/site_perl
  .

---

Environment for perl 5.13.5​:
  DYLD_LIBRARY_PATH (unset)
  HOME=/Users/sprout
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/local/bin​:/usr/X11/bin​:/usr/local/bin
  PERL_BADLANG (unset)
  SHELL=/bin/bash

[p5pRT]

From @jkeenan

On Sun, 03 Oct 2010 19​:54​:09 GMT, sprout wrote​:

If a subroutine contains an op that references a downgradable GV, then
gv_try_downgrade, if called on that GV during global destruction,
*might* leave dangling pointers elsewhere; where exactly I wot not.

This only happens in non-threaded builds and with PERL_DESTRUCT_LEVEL
set to 2 (as in make test).

This was causing t/op/gv.t to give this assertion​:

Assertion failed​: (SvTYPE(sv) != SVTYPEMASK), function Perl_sv_clear,
file sv.c, line 5783.

This started with commit 13be902 (lvalue-to-glob assigment), but only
because of the tests it added.

It was actually caused by f746176, which added gv_try_downgrade.

I’ve made gv_try_downgrade simply return during global destruction
with commit 95f5675.

This ticket is a reminder that those dangling pointers need to be
dealt with some day. (I still think gv_try_downgrade should be skipped
during global destruction, regardless.)

To reproduce, delete the following line from
gv.c​:Perl_gv_try_downgrade​:

if (PL_dirty) return;

Then compile perl with -DDEBUGGING (but without threads) and run​:

cd t; PERL_DESTRUCT_LEVEL=2 ./perl harness -v op/gv.t

While 'PL_dirty' still exists in C code underneath cpan/, dist/ and ext/, it no longer exists in gv.c or other core C files. Consequently, I can no longer reproduce the problem in the manner advised more than 6 years ago.

Is the ticket closable?

Thank you very much.

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

[p5pRT]

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

[p5pRT]

From @arc

James E Keenan via RT <perlbug-followup@​perl.org> wrote​:

While 'PL_dirty' still exists in C code underneath cpan/, dist/ and ext/, it no longer exists in gv.c or other core C files. Consequently, I can no longer reproduce the problem in the manner advised more than 6 years ago.

Is the ticket closable?

It still has a stub definition in perl.h that's only made available to
XS modules, rather than being used in the core directly​:

#ifndef PERL_CORE
/* Do not use this macro. It only exists for extensions that rely on PL_dirty
* instead of using the newer PL_phase, which provides everything PL_dirty
* provided, and more. */
# define PL_dirty cBOOL(PL_phase == PERL_PHASE_DESTRUCT)

# define PL_amagic_generation PL_na
# define PL_encoding ((SV *)NULL)
#endif /* !PERL_CORE */

The Perl_gv_try_downgrade() function still has the equivalent logic to
avoid these dangling pointers​:

  /* XXX Why and where does this leave dangling pointers during global
  destruction? */
  if (PL_phase == PERL_PHASE_DESTRUCT) return;

However, commenting that out doesn't allow me to reproduce the
behaviour described, either. Maybe sprout can shed some light on this
situation.

--
Aaron Crane ** http​://aaroncrane.co.uk/

[p5pRT]

@iabyn - Status changed from 'open' to 'resolved'

[p5pRT]

From @iabyn

On Sat, Jan 07, 2017 at 05​:59​:55PM +0000, Aaron Crane wrote​:

James E Keenan via RT <perlbug-followup@​perl.org> wrote​:

While 'PL_dirty' still exists in C code underneath cpan/, dist/ and ext/, it no longer exists in gv.c or other core C files. Consequently, I can no longer reproduce the problem in the manner advised more than 6 years ago.

Is the ticket closable?

It still has a stub definition in perl.h that's only made available to
XS modules, rather than being used in the core directly​:

#ifndef PERL_CORE
/* Do not use this macro. It only exists for extensions that rely on PL_dirty
* instead of using the newer PL_phase, which provides everything PL_dirty
* provided, and more. */
# define PL_dirty cBOOL(PL_phase == PERL_PHASE_DESTRUCT)

# define PL_amagic_generation PL_na
# define PL_encoding ((SV *)NULL)
#endif /* !PERL_CORE */

The Perl_gv_try_downgrade() function still has the equivalent logic to
avoid these dangling pointers​:

/\* XXX Why and where does this leave dangling pointers during global
   destruction? \*/
if \(PL\_phase == PERL\_PHASE\_DESTRUCT\) return;

However, commenting that out doesn't allow me to reproduce the
behaviour described, either. Maybe sprout can shed some light on this
situation.

I can reproduce it on the old commit sprout mentioned as when the problem
started (13be902) but not blead.

In the absence of any contrary information, I'm marking this ticket
closed.

--
In England there is a special word which means the last sunshine
of the summer. That word is "spring".