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-shared object2.t crash #15215

Closed
p5pRT opened this issue Mar 6, 2016 · 14 comments
Closed

threads-shared object2.t crash #15215

p5pRT opened this issue Mar 6, 2016 · 14 comments

Comments

@p5pRT
Copy link

p5pRT commented Mar 6, 2016

Migrated from rt.perl.org#127661 (status was 'rejected')

Searchable as RT127661$

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2016

From @cpansprout

$ ./perl harness ../dist/threads-shared/t/object2.t
../dist/threads-shared/t/object2.t .. 1/131 panic​: free from wrong pool, 7f8d8986da00!=7f8d89803200 during global destruction.
../dist/threads-shared/t/object2.t .. All 131 subtests passed

But the problem disappears if I add the -v option to harness.

Is anybody else seeing this problem?

$ ./perl -Ilib -v

This is perl 5, version 23, subversion 9 (v5.23.9 (v5.23.8-83-g6e64da7*)) built for darwin-thread-multi-2level
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2016, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http​://www.perl.org/, the Perl Home Page.

Pint​:perl.git sprout$ ./perl -Ilib -V
Summary of my perl5 (revision 5 version 23 subversion 9) configuration​:
  Derived from​: 6e64da7
  Platform​:
  osname=darwin, osvers=12.5.0, archname=darwin-thread-multi-2level
  uname='darwin pint.local 12.5.0 darwin kernel version 12.5.0​: sun sep 29 13​:33​:47 pdt 2013; root​:xnu-2050.48.12~1release_x86_64 x86_64 '
  config_args='-DDEBUGGING -Accflags=-DPERL_OP_PARENT -Accflags=-DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO -Dcc=g++ -de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='g++', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -mmacosx-version-min=10.8 -DPERL_OP_PARENT -DPERL_DEBUG_READONLY_OPS -DPERL_NO_CO -DPERL_BOOL_AS_CHAR -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -DPERL_USE_SAFE_PUTENV',
  optimize='-O3 -g',
  cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -mmacosx-version-min=10.8 -DPERL_OP_PARENT -DPERL_DEBUG_READONLY_OPS -DPERL_NO_CO -DPERL_BOOL_AS_CHAR -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='g++', ldflags =' -mmacosx-version-min=10.8 -fstack-protector -L/usr/local/lib'
  libpth=/usr/include/c++/4.2.1 /usr/include/c++/4.2.1/backward /usr/local/lib /usr/lib
  libs=-lpthread -ldbm -ldl -lm -lutil -lc
  perllibs=-lpthread -ldl -lm -lutil -lc
  libc=, so=dylib, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -mmacosx-version-min=10.8 -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl)​:
  Compile-time options​: DEBUGGING HAS_TIMES MULTIPLICITY PERLIO_LAYERS
  PERL_BOOL_AS_CHAR PERL_COPY_ON_WRITE
  PERL_DEBUG_READONLY_OPS PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
  PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
  PERL_PRESERVE_IVUV PERL_TRACK_MEMPOOL PERL_USE_DEVEL
  PERL_USE_SAFE_PUTENV USE_64_BIT_ALL USE_64_BIT_INT
  USE_ITHREADS USE_LARGE_FILES USE_LOCALE
  USE_LOCALE_COLLATE USE_LOCALE_CTYPE
  USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO
  USE_PERL_ATOF USE_REENTRANT_API
  Locally applied patches​:
  uncommitted-changes
  Built under darwin
  Compiled at Mar 5 2016 12​:20​:36
  @​INC​:
  lib
  /usr/local/lib/perl5/site_perl/5.23.9/darwin-thread-multi-2level
  /usr/local/lib/perl5/site_perl/5.23.9
  /usr/local/lib/perl5/5.23.9/darwin-thread-multi-2level
  /usr/local/lib/perl5/5.23.9
  /usr/local/lib/perl5/site_perl
  .

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2016

From @cpansprout

On Sat Mar 05 16​:22​:20 2016, sprout wrote​:

$ ./perl harness ../dist/threads-shared/t/object2.t

BTW, that command has to be run in the t/ folder.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2016

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

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2016

From @cpansprout

On Sat Mar 05 16​:22​:20 2016, sprout wrote​:

$ ./perl harness ../dist/threads-shared/t/object2.t
../dist/threads-shared/t/object2.t .. 1/131 panic​: free from wrong
pool, 7f8d8986da00!=7f8d89803200 during global destruction.
../dist/threads-shared/t/object2.t .. All 131 subtests passed

But the problem disappears if I add the -v option to harness.

It also disappears if I run it with PERL_DESTRUCT_LEVEL=2, which surprised me.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2016

From @khwilliamson

On 03/05/2016 05​:34 PM, Father Chrysostomos via RT wrote​:

On Sat Mar 05 16​:22​:20 2016, sprout wrote​:

$ ./perl harness ../dist/threads-shared/t/object2.t
../dist/threads-shared/t/object2.t .. 1/131 panic​: free from wrong
pool, 7f8d8986da00!=7f8d89803200 during global destruction.
../dist/threads-shared/t/object2.t .. All 131 subtests passed

But the problem disappears if I add the -v option to harness.

It also disappears if I run it with PERL_DESTRUCT_LEVEL=2, which surprised me.

Those kind of weird things should be checked with valgrind to rule out
wild writes.

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2016

From @jkeenan

On Sat Mar 05 16​:22​:20 2016, sprout wrote​:

$ ./perl harness ../dist/threads-shared/t/object2.t
../dist/threads-shared/t/object2.t .. 1/131 panic​: free from wrong
pool, 7f8d8986da00!=7f8d89803200 during global destruction.
../dist/threads-shared/t/object2.t .. All 131 subtests passed

But the problem disappears if I add the -v option to harness.

Is anybody else seeing this problem?

$ ./perl -Ilib -v

This is perl 5, version 23, subversion 9 (v5.23.9 (v5.23.8-83-
g6e64da7*)) built for darwin-thread-multi-2level
(with 1 registered patch, see perl -V for more detail)

[snip]

config\_args='\-DDEBUGGING \-Accflags=\-DPERL\_OP\_PARENT \-Accflags=\-

DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO -Dcc=g++
-de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR'

Do you get the same failure if you either​:

(a) configure without the the '-Accflags' switches?

and/or​:

(b) use a different C compiler?

Thank you very much.

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

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2016

From @cpansprout

On Sun Mar 06 05​:41​:32 2016, jkeenan wrote​:

On Sat Mar 05 16​:22​:20 2016, sprout wrote​:

config\_args='\-DDEBUGGING \-Accflags=\-DPERL\_OP\_PARENT \-Accflags=\-

DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO -Dcc=g++
-de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR'

Do you get the same failure if you either​:

(a) configure without the the '-Accflags' switches?

and/or​:

(b) use a different C compiler?

If I drop -Accflags=-DPERL_OP_PARENT, the problem remains. (Same with -Accflags=-DPERL_NO_CO, which does nothing. It’s just my way of turning PERL_NO_COW on and off​: I delete the last letter.)

I don’t get the problem with clang. I need these three flags to get it​:

-Accflags=-DPERL_DEBUG_READONLY_OPS -Accflags=-DPERL_BOOL_AS_CHAR -Dcc=g++

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2016

From @cpansprout

On Sun Mar 06 06​:32​:42 2016, sprout wrote​:

On Sun Mar 06 05​:41​:32 2016, jkeenan wrote​:

On Sat Mar 05 16​:22​:20 2016, sprout wrote​:

config_args='-DDEBUGGING -Accflags=-DPERL_OP_PARENT -Accflags=-
DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO
-Dcc=g++
-de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR'

Do you get the same failure if you either​:

(a) configure without the the '-Accflags' switches?

and/or​:

(b) use a different C compiler?

If I drop -Accflags=-DPERL_OP_PARENT, the problem remains. (Same with
-Accflags=-DPERL_NO_CO, which does nothing. It’s just my way of
turning PERL_NO_COW on and off​: I delete the last letter.)

I don’t get the problem with clang. I need these three flags to get
it​:

-Accflags=-DPERL_DEBUG_READONLY_OPS -Accflags=-DPERL_BOOL_AS_CHAR
-Dcc=g++

I have tried bisecting in the one computer where this appears 100% reproducible. (Unfortunately, it does not have valgrind, and I am not in a position to change that.) Here is the result I get​:

commit 6e64da7
Author​: Karl Williamson <khw@​cpan.org>
Date​: Thu Mar 3 14​:21​:05 2016 -0700

  regcomp.c​: Revise, add comments, white-space changes

which just gives me a sinking feeling that this is going to be hard to track down. I need to make the bisect smarter by having it run the test 100 times....

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Mar 7, 2016

From @khwilliamson

On Sun Mar 06 14​:53​:27 2016, sprout wrote​:

On Sun Mar 06 06​:32​:42 2016, sprout wrote​:

On Sun Mar 06 05​:41​:32 2016, jkeenan wrote​:

On Sat Mar 05 16​:22​:20 2016, sprout wrote​:

config_args='-DDEBUGGING -Accflags=-DPERL_OP_PARENT -Accflags=-
DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO
-Dcc=g++
-de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR'

Do you get the same failure if you either​:

(a) configure without the the '-Accflags' switches?

and/or​:

(b) use a different C compiler?

If I drop -Accflags=-DPERL_OP_PARENT, the problem remains. (Same
with
-Accflags=-DPERL_NO_CO, which does nothing. It’s just my way of
turning PERL_NO_COW on and off​: I delete the last letter.)

I don’t get the problem with clang. I need these three flags to get
it​:

-Accflags=-DPERL_DEBUG_READONLY_OPS -Accflags=-DPERL_BOOL_AS_CHAR
-Dcc=g++

I have tried bisecting in the one computer where this appears 100%
reproducible. (Unfortunately, it does not have valgrind, and I am not
in a position to change that.) Here is the result I get​:

commit 6e64da7
Author​: Karl Williamson <khw@​cpan.org>
Date​: Thu Mar 3 14​:21​:05 2016 -0700

regcomp.c​: Revise, add comments, white-space changes

which just gives me a sinking feeling that this is going to be hard to
track down. I need to make the bisect smarter by having it run the
test 100 times....

Since my name got mentioned, I did verify that that commit was as advertised, only comments and white-space.

I rang this on blead on my 64-bit Linux box​:

./Configure -DDEBUGGING -Accflags=-DPERL_OP_PARENT -Accflags=-DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO -Dcc=g++ -de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR

I ran your script by hand, maybe 30-40 times in a row without failure. I ran it under valgrind, and also got no failure, though I don't know if there's something special to do with valgrind on subthreads.

--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Mar 7, 2016

From @khwilliamson

On 03/06/2016 10​:09 PM, Karl Williamson via RT wrote​:

On Sun Mar 06 14​:53​:27 2016, sprout wrote​:

On Sun Mar 06 06​:32​:42 2016, sprout wrote​:

On Sun Mar 06 05​:41​:32 2016, jkeenan wrote​:

On Sat Mar 05 16​:22​:20 2016, sprout wrote​:

config_args='-DDEBUGGING -Accflags=-DPERL_OP_PARENT -Accflags=-
DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO
-Dcc=g++
-de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR'

Do you get the same failure if you either​:

(a) configure without the the '-Accflags' switches?

and/or​:

(b) use a different C compiler?

If I drop -Accflags=-DPERL_OP_PARENT, the problem remains. (Same
with
-Accflags=-DPERL_NO_CO, which does nothing. It’s just my way of
turning PERL_NO_COW on and off​: I delete the last letter.)

I don’t get the problem with clang. I need these three flags to get
it​:

-Accflags=-DPERL_DEBUG_READONLY_OPS -Accflags=-DPERL_BOOL_AS_CHAR
-Dcc=g++

I have tried bisecting in the one computer where this appears 100%
reproducible. (Unfortunately, it does not have valgrind, and I am not
in a position to change that.) Here is the result I get​:

commit 6e64da7
Author​: Karl Williamson <khw@​cpan.org>
Date​: Thu Mar 3 14​:21​:05 2016 -0700

regcomp.c​: Revise, add comments, white-space changes

which just gives me a sinking feeling that this is going to be hard to
track down. I need to make the bisect smarter by having it run the
test 100 times....

Since my name got mentioned, I did verify that that commit was as advertised, only comments and white-space.

I rang this on blead on my 64-bit Linux box​:

./Configure -DDEBUGGING -Accflags=-DPERL_OP_PARENT -Accflags=-DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO -Dcc=g++ -de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR

I ran your script by hand, maybe 30-40 times in a row without failure. I ran it under valgrind, and also got no failure, though I don't know if there's something special to do with valgrind on subthreads.

That commit is adjacent to one that does change freeing things. You
could revert 88474c0 and
5751998 to see if the problem goes
away. (88474c is a revision of 57519)

In examining the code, I see another potential memory leak, and will fix
that, but I don't see how that could affect this.

@p5pRT
Copy link
Author

p5pRT commented Mar 7, 2016

From @cpansprout

On Mon Mar 07 10​:31​:48 2016, public@​khwilliamson.com wrote​:

On 03/06/2016 10​:09 PM, Karl Williamson via RT wrote​:

On Sun Mar 06 14​:53​:27 2016, sprout wrote​:

On Sun Mar 06 06​:32​:42 2016, sprout wrote​:

On Sun Mar 06 05​:41​:32 2016, jkeenan wrote​:

On Sat Mar 05 16​:22​:20 2016, sprout wrote​:

config_args='-DDEBUGGING -Accflags=-DPERL_OP_PARENT -Accflags=-
DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO
-Dcc=g++
-de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR'

Do you get the same failure if you either​:

(a) configure without the the '-Accflags' switches?

and/or​:

(b) use a different C compiler?

If I drop -Accflags=-DPERL_OP_PARENT, the problem remains. (Same
with
-Accflags=-DPERL_NO_CO, which does nothing. It’s just my way of
turning PERL_NO_COW on and off​: I delete the last letter.)

I don’t get the problem with clang. I need these three flags to get
it​:

-Accflags=-DPERL_DEBUG_READONLY_OPS -Accflags=-DPERL_BOOL_AS_CHAR
-Dcc=g++

I have tried bisecting in the one computer where this appears 100%
reproducible. (Unfortunately, it does not have valgrind, and I am
not
in a position to change that.) Here is the result I get​:

commit 6e64da7
Author​: Karl Williamson <khw@​cpan.org>
Date​: Thu Mar 3 14​:21​:05 2016 -0700

regcomp.c​: Revise, add comments, white-space changes

which just gives me a sinking feeling that this is going to be hard
to
track down. I need to make the bisect smarter by having it run the
test 100 times....

Since my name got mentioned, I did verify that that commit was as
advertised, only comments and white-space.

I rang this on blead on my 64-bit Linux box​:

./Configure -DDEBUGGING -Accflags=-DPERL_OP_PARENT -Accflags=-
DPERL_DEBUG_READONLY_OPS -Duseithreads -Accflags=-DPERL_NO_CO
-Dcc=g++ -de -Dusedevel -Accflags=-DPERL_BOOL_AS_CHAR

I ran your script by hand, maybe 30-40 times in a row without
failure. I ran it under valgrind, and also got no failure, though I
don't know if there's something special to do with valgrind on
subthreads.

That commit is adjacent to one that does change freeing things. You
could revert 88474c0 and
5751998 to see if the problem goes
away. (88474c is a revision of 57519)

In examining the code, I see another potential memory leak, and will
fix
that, but I don't see how that could affect this.

Thank you for the suggestion. Alas, it makes no difference. I honestly think I misread the bisect output, because now I can no longer get it to fail under an automated bisect.

I have now bisected it manually to​:

commit 67ba812
Author​: Aristotle Pagaltzis <pagaltzis@​gmx.de>
Date​: Wed Mar 2 03​:30​:30 2016 +0100

  narrow the filename check in strict.pm/warnings.pm

which means we have a latent bug that has just been uncovered. I will keep digging....

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2016

From @cpansprout

On Mon Mar 07 12​:55​:35 2016, sprout wrote​:

I have now bisected it manually to​:

commit 67ba812
Author​: Aristotle Pagaltzis <pagaltzis@​gmx.de>
Date​: Wed Mar 2 03​:30​:30 2016 +0100

narrow the filename check in strict.pm/warnings.pm

which means we have a latent bug that has just been uncovered. I will
keep digging....

After a while, I stopped being able to reproduce it myself, even with commits where I could consistently reproduce it before. So I am at a loss. With no way to track down this bug now, and nobody who can reproduce it, I am just going to mark it as rejected.

--

Father Chrysostomos

@p5pRT p5pRT closed this as completed Mar 8, 2016
@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2016

@cpansprout - Status changed from 'open' to 'rejected'

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2016

From @khwilliamson

On 03/08/2016 09​:47 AM, Father Chrysostomos via RT wrote​:

On Mon Mar 07 12​:55​:35 2016, sprout wrote​:

I have now bisected it manually to​:

commit 67ba812
Author​: Aristotle Pagaltzis <pagaltzis@​gmx.de>
Date​: Wed Mar 2 03​:30​:30 2016 +0100

narrow the filename check in strict.pm/warnings.pm

which means we have a latent bug that has just been uncovered. I will
keep digging....

After a while, I stopped being able to reproduce it myself, even with commits where I could consistently reproduce it before. So I am at a loss. With no way to track down this bug now, and nobody who can reproduce it, I am just going to mark it as rejected.

Problems that go away on their own tend to come back on their own.

If you're saying that you've reset the perl HEAD to where it used to
fail, and it doesn't now, then that is very strange, and sounds like a
hardware glitch (or neutrinos :) )

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