Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gv_try_downgrade leaves dangling pointers during global destruction #10689

Closed
p5pRT opened this issue Oct 3, 2010 · 6 comments
Closed

gv_try_downgrade leaves dangling pointers during global destruction #10689

p5pRT opened this issue Oct 3, 2010 · 6 comments

Comments

@p5pRT
Copy link

p5pRT commented Oct 3, 2010

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

Searchable as RT78192$

@p5pRT
Copy link
Author

p5pRT commented Oct 3, 2010

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
Copy link
Author

p5pRT commented Jan 7, 2017

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
Copy link
Author

p5pRT commented Jan 7, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Jan 7, 2017

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 p5pRT closed this as completed Mar 28, 2017
@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2017

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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant