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

threads panic in del_backref #9979

Closed
p5pRT opened this issue Nov 23, 2009 · 17 comments
Closed

threads panic in del_backref #9979

p5pRT opened this issue Nov 23, 2009 · 17 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Nov 23, 2009

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

Searchable as RT70748$

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 23, 2009

From @jdhedden

Created by @jdhedden

The following​:

  use threads;

  sub foo {
  return (sub { });
  }

  my $bar = threads->create(\&foo)->join();

  threads->create(sub { })->join();

produces​:

  panic​: del_backref during global destruction.

This bug was introduced with change 34354
(commit a49ba3f)

Once fixed, the following can be added to t/op/threads.t​:

# Test we don't get​:
# panic​: del_backref during global destruction.
fresh_perl_is(<<'EOI', 'ok', { }, 'Direct lookup hash for ->isa()');
use threads;
sub foo { return (sub { }); }
my $bar = threads->create(\&foo)->join();
threads->create(sub { })->join();
print "ok";
EOI

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.11.0:

Configured by Jerry at Mon Nov 23 09:24:58 EST 2009.

Summary of my perl5 (revision 5 version 11 subversion 0 patch 34354)
configuration:
  Platform:
    osname=cygwin, osvers=1.5.25(0.15642), archname=cygwin-thread-multi-64int
    uname='cygwin_nt-5.1 pn100-02-2-364p 1.5.25(0.15642) 2008-06-12
19:34 i686 cygwin '
    config_args='-de -Dusedevel -Dversiononly=no -Dinstallusrbinperl
-Uusemallocwrap -Duse64bitint -Dusethreads -Dinc_version_list=none
-Dnoextensions=IPC/SysV Sys/Syslog Devel/DProf Devel/Peek re GDBM_File
NDBM_File ODBM_File Text/Soundex attrs Math/BigInt/FastCalc Time/Piece
-A append:ccflags= -DNO_MATHOMS  -A define:optimize=-Os -pipe
-funit-at-a-time -march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse
-msse2'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=y, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
-DNO_MATHOMS -fno-strict-aliasing -pipe',
    optimize='-Os -pipe -funit-at-a-time -march=pentium4 -mfpmath=sse
-mieee-fp -mmmx -msse -msse2',
    cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -DNO_MATHOMS
-fno-strict-aliasing -pipe'
    ccversion='', gccversion='3.4.4 (cygming special, gdc 0.12, using
dmd 0.125)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++', ldflags =' -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -s -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /lib
    libs=-lgdbm -ldl -lcrypt -lgdbm_compat
    perllibs=-ldl -lcrypt
    libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=cygperl5_11_0.dll
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
    cccdlflags=' ', lddlflags=' --shared  -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -s -L/usr/local/lib'

Locally applied patches:
    DEVEL


@INC for perl 5.11.0:
    lib
    /usr/lib/perl5/5.11.0/cygwin
    /usr/lib/perl5/5.11.0
    /usr/lib/perl5/site_perl/5.11.0/cygwin
    /usr/lib/perl5/site_perl/5.11.0
    .


Environment for perl 5.11.0:
    CYGWIN=ntsec
    HOME=/home/jhedden
    LANG=C
    LANGUAGE=C
    LC_ALL=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/jhedden/bin:/usr/local/src/perl/bin:/link/work/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/Program
Files/WiX:/c/djgpp/bin:/c/bb/tools/apache-ant-1.6.5/bin:/c/Program
Files/nant-0.85/bin:/c/bb/tools/jse5/bin:/c/dev-cpp/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/system32/WBEM:/c/blp/API/dde:/c/blp/API:/c/oracle/ora92/bin:/c/Program
Files/Oracle/jre/1.3.1/bin:/c/Program
Files/Oracle/jre/1.1.8/bin:/c/Program
Files/Hummingbird/Connectivity/7.10/Accessories:/usr/bin:/c/Program
Files/Windows Imaging/:.
    PERLIO=perlio
    PERL_BADLANG (unset)
    SHELL (unset)

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 25, 2009

From @obra

Thanks. Applied as 7c76c2a.

On Tue 24.Nov'09 at 16​:28​:07 -0500, Jerry D. Hedden wrote​:

Attached adds a TODO test to t/op/threads.t for perl #70748.

From a611a5d553f7483a25a4879986015ceb4b51f5a0 Mon Sep 17 00​:00​:00 2001
From​: Jerry D. Hedden <jdhedden@​cpan.org>
Date​: Tue, 24 Nov 2009 16​:26​:08 -0500
Subject​: [PATCH] Add TODO test for perl #70748

---
t/op/threads.t | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/t/op/threads.t b/t/op/threads.t
index c8ed34a..48ead65 100644
--- a/t/op/threads.t
+++ b/t/op/threads.t
@​@​ -191,4 +191,21 @​@​ undef *a;
threads->new(sub {})->join;
pass("undefing a typeglob doesn't cause a crash during cloning");

+
+TODO​: {
+ no strict 'vars'; # Accessing $TODO from test.pl
+ local $TODO = 'perl #70748';
+
+# Test we don't get​:
+# panic​: del_backref during global destruction.
+fresh_perl_is(<<'EOI', 'ok', { }, 'No del_backref panic');
+use threads;
+sub foo { return (sub { }); }
+my $bar = threads->create(\&foo)->join();
+threads->create(sub { })->join();
+print "ok";
+EOI
+
+} # TODO
+
# EOF
--
1.6.1.2

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 25, 2009

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 25, 2009

From @jdhedden

# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=70748 >

The following​:

   use threads;

   sub foo {
       return (sub { });
   }

   my $bar = threads->create(\&foo)->join();

   threads->create(sub { })->join();

produces​:

   panic​: del_backref during global destruction.

It get trickier. With commit 789c461
the bug "goes away". The only substantive thing that commit did was add
fatal_enabled() to warnings.pm. If I manually edit warnings.pm to remove
that function, the bug reappears.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 27, 2009

From @nwc10

On Wed, Nov 25, 2009 at 03​:32​:27PM -0500, Jerry D. Hedden wrote​:

# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=70748 >

The following​:

   use threads;

   sub foo {
       return (sub { });
   }

   my $bar = threads->create(\&foo)->join();

   threads->create(sub { })->join();

produces​:

   panic​: del_backref during global destruction.

It get trickier. With commit 789c461
the bug "goes away". The only substantive thing that commit did was add
fatal_enabled() to warnings.pm. If I manually edit warnings.pm to remove
that function, the bug reappears.

I can't re-create this on any platform I have access to (Linux, OS X, FreeBSD),
with any revision I tried. (Just after the revision you report introduced it,
and with various recent revisions prior to 789c461).

Does this happen on any platform other than Cygwin?

Is it sensitive to external factors? For example, the number of environment
variables set?

Nicholas Clark

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 28, 2009

From @jdhedden

Jerry D. Hedden wrote​:

# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=70748 >

The following​:

   use threads;

   sub foo {
       return (sub { });
   }

   my $bar = threads->create(\&foo)->join();

   threads->create(sub { })->join();

produces​:

   panic​: del_backref during global destruction.

It get trickier.  With commit 789c461
the bug "goes away".  The only substantive thing that commit did was add
fatal_enabled() to warnings.pm.  If I manually edit warnings.pm to remove
that function, the bug reappears.

Nicholas Clark wrote​:

I can't re-create this on any platform I have access to (Linux, OS X, FreeBSD),
with any revision I tried. (Just after the revision you report introduced it,
and with various recent revisions prior to 789c461).

Does this happen on any platform other than Cygwin?

Yes. I can reproduce it with ActivePerl 5.10.1.
(I tried 5.10.1 under Solaris, but that did not reproduce the bug.)

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 16, 2009

From @obra

On Sat Nov 28 13​:59​:06 2009, jdhedden@​cpan.org wrote​:

Jerry D. Hedden wrote​:

# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=70748 >

The following​:

   use threads;

   sub foo {
       return (sub { });
   }

   my $bar = threads->create(\&foo)->join();

   threads->create(sub { })->join();

produces​:

   panic​: del_backref during global destruction.

It get trickier.  With commit 789c461
the bug "goes away".  The only substantive thing that commit did was
add fatal_enabled() to warnings.pm.  If I manually edit warnings.pm to
remove that function, the bug reappears.

Nicholas Clark wrote​:

I can't re-create this on any platform I have access to (Linux, OS X, FreeBSD),
with any revision I tried. (Just after the revision you report introduced it,
and with various recent revisions prior to 789c461).

At this point, should this issue still be blocking 5.12.0?

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 16, 2009

From @jdhedden

On Tue, Dec 15, 2009 at 19​:04, Jesse via RT <perlbug-followup@​perl.org> wrote​:

On Sat Nov 28 13​:59​:06 2009, jdhedden@​cpan.org wrote​:

Jerry D. Hedden wrote​:

# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=70748 >

The following​:

   use threads;

   sub foo {
       return (sub { });
   }

   my $bar = threads->create(\&foo)->join();

   threads->create(sub { })->join();

produces​:

   panic​: del_backref during global destruction.

It get trickier.  With commit 789c461
the bug "goes away".  The only substantive thing that commit did was
add fatal_enabled() to warnings.pm.  If I manually edit warnings.pm to
remove that function, the bug reappears.

Nicholas Clark wrote​:

I can't re-create this on any platform I have access to (Linux, OS X, FreeBSD),
with any revision I tried. (Just after the revision you report introduced it,
and with various recent revisions prior to 789c461).

At this point, should this issue still be blocking 5.12.0?

For that it's worth, my opinion is that this should be looked into and
fixed. It looks to be some internal bug that could potentially cause
threaded apps to become unusable.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 16, 2009

From @obra

On Wed, Dec 16, 2009 at 11​:45​:25AM -0500, Jerry D. Hedden wrote​:

On Tue, Dec 15, 2009 at 19​:04, Jesse via RT <perlbug-followup@​perl.org> wrote​:

On Sat Nov 28 13​:59​:06 2009, jdhedden@​cpan.org wrote​:

Jerry D. Hedden wrote​:

# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=70748 >

I can't re-create this on any platform I have access to (Linux, OS X, FreeBSD),
with any revision I tried. (Just after the revision you report introduced it,
and with various recent revisions prior to 789c461).

At this point, should this issue still be blocking 5.12.0?

For that it's worth, my opinion is that this should be looked into and
fixed. It looks to be some internal bug that could potentially cause
threaded apps to become unusable.

[resent with perlbug on cc list]

I have absolutely no problem keeping it open. But it doesn't look like
it fits the criteria for blocking shipment of 5.12.0.

--

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2009

From @cpansprout

This was caused by change 34210/41fae7a, which simply reveals a bug
that already existed.

A sub returned from a thread brings a lot of baggage with it,
including some globs. There is this comment near the top of
Perl_sv_dup in the if(param->flags & CLONEf_JOIN_IN) block that reads​:
  /** don't clone stashes if they already exist **/

Then later on, under case SVt_PVGV​:
  /* Don't call sv_add_backref here as it's going to be
  created as part of the magic cloning of the symbol
  table. */

So what’s happening is that there is a glob with no back-reference in
its stash, which glob is sometimes freed after the stash, so it
induces the panic.

Attached is a patch to fix this, another one to remove the ‘TODO’
status from the test, and another to add a test for something I almost
broke.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2009

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2009

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2009

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2009

From @cpansprout

Attached is another, more reliable test for the original bug.

On Dec 20, 2009, at 1​:07 PM, Father Chrysostomos wrote​:

This was caused by change 34210/41fae7a, which simply reveals a bug
that already existed.

A sub returned from a thread brings a lot of baggage with it,
including some globs. There is this comment near the top of
Perl_sv_dup in the if(param->flags & CLONEf_JOIN_IN) block that reads​:
/** don't clone stashes if they already exist **/

Then later on, under case SVt_PVGV​:
/* Don't call sv_add_backref here as it's going to be
created as part of the magic cloning of the symbol
table. */

So what’s happening is that there is a glob with no back-reference
in its stash, which glob is sometimes freed after the stash, so it
induces the panic.

Attached is a patch to fix this, another one to remove the ‘TODO’
status from the test, and another to add a test for something I
almost broke.
<70748.diff><70748-test.diff><closure-test.diff>

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2009

From @cpansprout

Inline Patch
--- blead-70748copy/t/op/threads.t	2009-12-20 12:39:51.000000000 -0800
+++ blead-70748copy2/t/op/threads.t	2009-12-20 14:29:00.000000000 -0800
@@ -16,7 +16,7 @@ BEGIN {
        exit 0;
      }
 
-     plan(16);
+     plan(17);
 }
 
 use strict;
@@ -204,6 +204,15 @@ threads->create(sub { })->join();
 print "ok";
 EOI
 
+# Another, more reliable test for the same del_backref bug:
+fresh_perl_like(
+ <<'   EOJ', qr/ok/, {}, 'No del_backref panic [perl #70748] (2)'
+   use threads;
+   push @bar, threads->create(sub{sub{}})->join() for 1...10;
+   print "ok";
+   EOJ
+);
+
 # Simple closure-returning test: At least this case works (though it
 # leaks), and we don't want to break it.
 fresh_perl_like(<<'EOJ', qr/^foo\n/, {}, 'returning a closure');
@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 22, 2009

From @rgarcia

Thanks, all applied as 27bca32.

2009/12/20 Father Chrysostomos <sprout@​cpan.org>​:

Attached is another, more reliable test for the original bug.

On Dec 20, 2009, at 1​:07 PM, Father Chrysostomos wrote​:

This was caused by change 34210/41fae7a, which simply reveals a bug that
already existed.

A sub returned from a thread brings a lot of baggage with it, including
some globs. There is this comment near the top of Perl_sv_dup in the
if(param->flags & CLONEf_JOIN_IN) block that reads​:
               /** don't clone stashes if they already exist **/

Then later on, under case SVt_PVGV​:
                   /* Don't call sv_add_backref here as it's going to be
                      created as part of the magic cloning of the symbol
                      table. */

So what’s happening is that there is a glob with no back-reference in its
stash, which glob is sometimes freed after the stash, so it induces the
panic.

Attached is a patch to fix this, another one to remove the ‘TODO’ status
from the test, and another to add a test for something I almost broke.
<70748.diff><70748-test.diff><closure-test.diff>

--
"You don't mean odds and ends, you mean des curieux et des bouts",
corrected the manager.
-- Terry Pratchett, Hogfather

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 22, 2009

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

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

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.