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

perl 5.14.2 test suite failures on x86_64-sun-solaris2.10 #11681

Closed
p5pRT opened this issue Sep 30, 2011 · 16 comments
Closed

perl 5.14.2 test suite failures on x86_64-sun-solaris2.10 #11681

p5pRT opened this issue Sep 30, 2011 · 16 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 30, 2011

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

Searchable as RT100450$

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2011

@p5pRT
Copy link
Author

p5pRT commented Mar 24, 2012

From @jkeenan

On Fri Sep 30 14​:29​:35 2011, Tim.Mooney@​ndsu.edu wrote​:

This is a bug report for perl from Tim.Mooney@​ndsu.edu,
generated with the help of perlbug 1.39 running under perl 5.14.2.

The original post included the full output of 't/harness', which was too
big for RT to display. Hence, this ticket did not get the attention it
deserved.

Let me try to boil it down.

-----------------------------------------------------------------

I've compiled perl 5.14.2 on Solaris 2.10 (not OpenSolaris) using
the Sun Studio 12u1 toolchain. 63 of the test categories had
failures,
including many of the tests relating to threading.

In comparison to previous perl builds I've done (which have been built
in an identical manner), this is a huge number of failures. For
example,
5.12.3 built with the same compiler using the exact same parameters
has
only 1 subtest fail in the lib/locale test. I also just built 5.12.4
using
the exact same build environment and Configure arguments, and it too
had
just the 1 subtest failure.

What information can I provide that would be useful to track down the
reasons for some of these new failures? I'm including the results
from
t/harness inline

Tim

results from

cd t
\./perl harness 2>&1 | tee /tmp/perl\-5\.14\.2\-harness\.out

[snip]

Let's go to one of the first block of test failures.

[snip]

re/regexp_qr_embed_thr.t ..........................................
Failed 1520/1525 subtests

[snip]

op/fork.t ......................................................... ok
op/getpid.t .......................................................
Failed 2/3 subtests
op/getppid.t ...................................................... ok

[snip]

op/gv.t ...........................................................
Failed 143/234 subtests
op/hash.t ......................................................... ok

[snip]

op/require_errors.t ............................................... ok
Segmentation Fault - core dumped
Segmentation Fault - core dumped
Segmentation Fault - core dumped
Segmentation Fault - core dumped
op/reset.t ........................................................
All 24 subtests passed

[snip]

op/sselect.t ...................................................... ok
# Failed at op/stash.t line 87
# got "main"
# expected "one"
# Failed at op/stash.t line 99
# got "main"
# expected "two"
op/stash.t ........................................................
Failed 46/54 subtests

[snip]

op/taint.t ........................................................ ok
Segmentation Fault - core dumped
# Failed at ./test.pl line 828
# got ""
# expected "ok"
# PROG​:
# use threads;
# opendir dir, 'op';
# async{}->join for 1..2;
# print "ok";
# STATUS​: 35584
op/threads-dirh.t .................................................
Failed 6/6 subtests
Segmentation Fault - core dumped
# Failed at ./test.pl line 828
# got ""
# expected "ok"
# PROG​:
# use threads;
# threads->create(sub { my %h=(1,2); delete $h{1}})->join for 1..2;
# print "ok";
# STATUS​: 35584
Segmentation Fault - core dumped
Segmentation Fault - core dumped
# Failed at ./test.pl line 828
# got ""
# expected "ok"
# PROG​:
# package Foo;
# sub new { bless {},shift }
# package main;
# use threads;
# use Scalar​::Util qw(weaken);
# my $object = Foo->new;
# my $ref = $object;
# weaken $ref;
# threads->create(sub { $ref = $object } )->join; # $ref = $object
causes problems
# print "ok";
# STATUS​: 35584
op/threads.t ......................................................
Failed 23/24 subtests

Would it be possible to provide more verbose output on these particular
failures?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Mar 24, 2012

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

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2012

From Tim.Mooney@ndsu.edu

Would it be possible to provide more verbose output on these particular
failures?

Jim, et. al.-

When I've used rt in the past, reply-via-email has "just worked". I've
replied via email a couple times today to this issue, but I'm not seeing
my replies reflected in the ticket.

Is perlbug's RT not using reply-via-email, or is there a significant
delay before email replies show up in the ticket system?

Thanks,

Tim

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2012

From @jkeenan

On Tue Apr 17 13​:38​:12 2012, enchanter wrote​:

Jim, et. al.-

When I've used rt in the past, reply-via-email has "just worked". I've
replied via email a couple times today to this issue, but I'm not seeing
my replies reflected in the ticket.

Is perlbug's RT not using reply-via-email, or is there a significant
delay before email replies show up in the ticket system?

I have to admit that I'm not familiar with reply-via-email, so I suspect
it's not working.

I know that the web interface works, because that's what I use. If you
can't use that but can use IRC, I'd suggest logging on to irc.perl.org
#p5p and asking the advice of those gathered there.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2012

From Tim.Mooney@ndsu.edu

In regard to​: [perl #100450] perl 5.14.2 test suite failures on...​:

On Fri Sep 30 14​:29​:35 2011, Tim.Mooney@​ndsu.edu wrote​:

This is a bug report for perl from Tim.Mooney@​ndsu.edu,
generated with the help of perlbug 1.39 running under perl 5.14.2.

The original post included the full output of 't/harness', which was too
big for RT to display. Hence, this ticket did not get the attention it
deserved.

Let me try to boil it down.

Thanks James, and sorry for the delay in responding.

Let's go to one of the first block of test failures.

Sounds good.

[snip]

re/regexp_qr_embed_thr.t ..........................................
Failed 1520/1525 subtests

01​:22 PM dogbert t$./perl -I ../lib re/regexp_qr_embed_thr.t
1..1525
# 1 iterations
ok 1 # (Blank line or comment)
# This stops me getting screenfulls of syntax errors every time I
# accidentally
ok 2 # (Blank line or comment)
# run this file via a shell glob. Format of this file is given in
# regexp.t
ok 3 # (Blank line or comment)
# Can't use \N{VALID NAME TEST} here because need 'use charnames'; but can
# use
ok 4 # (Blank line or comment)
# \N{U+valid} here.
ok 5 # (Blank line or comment)
Segmentation Fault (core dumped)

01​:23 PM dogbert t$dbx perl core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your
.dbxrc
Reading perl
core file header read successfully
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libdl.so.1
Reading libm.so.2
Reading libpthread.so.1
Reading libc.so.1
Reading libthread.so.1
Reading threads.so
t@​1 (l@​1) program terminated by signal SEGV (no mapping at the fault
address)
0x00000000004f0ff0​: Perl_sv_vcatpvfn+0x23e0​: movdqa (%rdx),%xmm1
(dbx) where
current thread​: t@​1
=>[1] Perl_sv_vcatpvfn(0x7e6490, 0xfffffd7fffdfdf68, 0x73646165726870,
0xc, 0xfffffd7fffdfe140, 0x0), at 0x4f0ff0
  [2] Perl_vnewSVpvf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ec553
  [3] Perl_newSVpvf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ec465
  [4] S_anonymise_cv_maybe(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e7d3e
  [5] Perl_sv_kill_backrefs(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e7301
  [6] Perl_magic_killbackrefs(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4bc5cd
  [7] S_sv_unmagicext_flags(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e6e08
  [8] Perl_sv_clear(0x0, 0x0), at 0x4e7f5f
  [9] Perl_sv_free2(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e8add
  [10] S_visit(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ded6e
  [11] perl_destruct(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x44a92b
  [12] S_ithread_clear(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xfffffd7fff03323f
  [13] XS_threads_join(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xfffffd7fff03666c
  [14] Perl_pp_entersub(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4dd719
  [15] Perl_runops_standard(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4d19be
  [16] S_run_body(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x44c94c
  [17] perl_run(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x44c86a
  [18] main(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x431d70

[snip]

op/fork.t ......................................................... ok
op/getpid.t .......................................................
Failed 2/3 subtests

01​:24 PM dogbert t$./perl op/getpid.t
1..3
ok 1 - thread modules loaded
Segmentation Fault (core dumped)

01​:25 PM dogbert t$dbx perl core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your
.dbxrc
Reading perl
core file header read successfully
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libdl.so.1
Reading libm.so.2
Reading libpthread.so.1
Reading libc.so.1
Reading libthread.so.1
Reading threads.so
Reading Util.so
Reading shared.so
Reading attributes.so
t@​1 (l@​1) program terminated by signal SEGV (no mapping at the fault
address)
0x00000000004f0ff0​: Perl_sv_vcatpvfn+0x23e0​: movdqa (%rdx),%xmm1
(dbx) where
current thread​: t@​1
=>[1] Perl_sv_vcatpvfn(0x89b080, 0xfffffd7fffdfdf88, 0x73646165726870,
0xc, 0xfffffd7fffdfe160, 0x0), at 0x4f0ff0
  [2] Perl_vnewSVpvf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ec553
  [3] Perl_newSVpvf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ec465
  [4] S_anonymise_cv_maybe(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e7d3e
  [5] Perl_sv_kill_backrefs(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e7301
  [6] Perl_magic_killbackrefs(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4bc5cd
  [7] S_sv_unmagicext_flags(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e6e08
  [8] Perl_sv_clear(0x0, 0x0), at 0x4e7f5f
  [9] Perl_sv_free2(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e8add
  [10] S_visit(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ded20
  [11] perl_destruct(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x44a92b
  [12] S_ithread_clear(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xfffffd7fff03323f
  [13] XS_threads_join(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xfffffd7fff03666c
  [14] Perl_pp_entersub(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4dd719
  [15] Perl_runops_standard(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4d19be
  [16] S_run_body(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x44c94c
  [17] perl_run(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x44c86a
  [18] main(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x431d70

op/getppid.t ...................................................... ok

[snip]

op/gv.t ...........................................................
Failed 143/234 subtests

01​:30 PM dogbert t$./perl -I ../lib op/gv.t
1..234
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8 - no type coersion when assigning to *{} retval
ok 9 - symbolic *{} returns symtab entry when FAKE
ok 10 - no type coersion when assigning to retval of symbolic *{}
ok 11 - compile-time *{} returns symtab entry when FAKE
ok 12 - no type coersion when assigning to retval of compile-time *{}
ok 13
ok 14
ok 15
ok 16
ok 17
ok 18
ok 19
ok 20
ok 21
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27
ok 28
ok 29 - Warning on conversion to IV
ok 30
ok 31 - Warning on conversion to UV
ok 32
ok 33 - Warning on conversion to NV
ok 34 - Expect floating point zero
ok 35 - No warning on stringification
ok 36
ok 37 - Warning on conversion to IV
ok 38
ok 39 - Warning on conversion to UV
ok 40
ok 41 - Warning on conversion to NV
ok 42 - Expect floating point zero
ok 43 - No warning on stringification
ok 44
ok 45
ok 46
ok 47
ok 48
ok 49
ok 50
ok 51
ok 52
ok 53
ok 54
ok 55
ok 56
ok 57
ok 58
ok 59
ok 60
ok 61
ok 62
ok 63
ok 64
ok 65
ok 66
ok 67
ok 68
ok 69
ok 70
ok 71
ok 72
ok 73
ok 74
ok 75
ok 76
ok 77
ok 78
ok 79
ok 80
ok 81
ok 82
ok 83
ok 84 - lvalue assignment preserves globs
ok 85
ok 86 - __DIE__ handler never called
ok 87
ok 88 - tied elem assignment preserves globs
ok 89 - __DIE__ handler not called
ok 90
ok 91 - __DIE__ handler never called
ok 92 - DESTROY was called
ok 93 - unreferenced symbol tables should be cleaned up immediately
ok 94 - no symbols of any sort to start with for oonk
ok 95 - no symbols of any sort to start with for ga_shloip
ok 96 - String is promoted to prototype
Segmentation Fault (core dumped)
01​:31 PM dogbert t$ dbx perl core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your
.dbxrc
Reading perl
core file header read successfully
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libdl.so.1
Reading libm.so.2
Reading libpthread.so.1
Reading libc.so.1
Reading libthread.so.1
t@​1 (l@​1) program terminated by signal SEGV (no mapping at the fault
address)
0x00000000004f0ff0​: Perl_sv_vcatpvfn+0x23e0​: movdqa (%rdx),%xmm1
(dbx) where
current thread​: t@​1
=>[1] Perl_sv_vcatpvfn(0x5b9970, 0xfffffd7fffdfe298, 0x6e696170, 0x5,
0xfffffd7fffdfe470, 0x0), at 0x4f0ff0
  [2] Perl_vnewSVpvf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ec553
  [3] Perl_newSVpvf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ec465
  [4] S_anonymise_cv_maybe(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e7d3e
  [5] Perl_sv_kill_backrefs(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e7301
  [6] Perl_magic_killbackrefs(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4bc5cd
  [7] S_sv_unmagicext_flags(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e6e08
  [8] Perl_sv_clear(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e7f5f
  [9] Perl_gv_try_downgrade(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x459e4c
  [10] Perl_op_clear(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x432777
  [11] Perl_op_free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x43249b
  [12] Perl_op_free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x43245c
  [13] Perl_op_free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x43245c
  [14] Perl_op_free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x43245c
  [15] Perl_op_free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x43245c
  [16] Perl_op_free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x43245c
  [17] Perl_op_free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x43245c
  [18] Perl_op_free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x43245c
  [19] Perl_op_free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x43245c
  [20] Perl_leave_scope(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x5158da
  [21] Perl_pp_leaveeval(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x523f08
  [22] Perl_runops_standard(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4d19be
  [23] S_run_body(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x44c94c
  [24] perl_run(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x44c86a
  [25] main(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x431d70

op/hash.t ......................................................... ok

[snip]

op/require_errors.t ............................................... ok
Segmentation Fault - core dumped
Segmentation Fault - core dumped
Segmentation Fault - core dumped
Segmentation Fault - core dumped
op/reset.t ........................................................
All 24 subtests passed

01​:33 PM dogbert t$./perl -I ../lib op/reset.t
1..24
ok 1 - mismatch doesn't match
ok 2 - match matches first time
ok 3 - mismatch doesn't match
ok 4 - match doesn't match second time
ok 5 - match matches after reset
ok 6 - mismatch doesn't match
ok 7 - mismatch doesn't match
ok 8 - match matches first time
ok 9 - mismatch doesn't match
ok 10 - match matches first time
ok 11 - mismatch doesn't match
ok 12 - match doesn't match second time
ok 13 - mismatch doesn't match
ok 14 - match doesn't match second time
ok 15 - match matches after reset
ok 16 - mismatch doesn't match
ok 17 - mismatch doesn't match
ok 18 - match doesn't match third time
ok 19 - match matches after reset
ok 20 - mismatch doesn't match
Segmentation Fault - core dumped
ok 21 - first pattern //, second //
Segmentation Fault - core dumped
ok 22 - first pattern //, second ??
Segmentation Fault - core dumped
ok 23 - first pattern ??, second //
Segmentation Fault - core dumped
ok 24 - first pattern ??, second ??
Segmentation Fault (core dumped)

01​:34 PM dogbert t$dbx perl core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your
.dbxrc
Reading perl
core file header read successfully
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libdl.so.1
Reading libm.so.2
Reading libpthread.so.1
Reading libc.so.1
Reading libthread.so.1
Reading threads.so
t@​1 (l@​1) program terminated by signal SEGV (no mapping at the fault
address)
0x00000000004f0ff0​: Perl_sv_vcatpvfn+0x23e0​: movdqa (%rdx),%xmm1
(dbx) where
current thread​: t@​1
=>[1] Perl_sv_vcatpvfn(0x5b9970, 0xfffffd7fffdfe558, 0x64616f6c72657670,
0x7, 0xfffffd7fffdfe730, 0x0), at 0x4f0ff0
  [2] Perl_vnewSVpvf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ec553
  [3] Perl_newSVpvf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ec465
  [4] S_anonymise_cv_maybe(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e7d3e
  [5] Perl_sv_kill_backrefs(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e7301
  [6] Perl_magic_killbackrefs(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4bc5cd
  [7] S_sv_unmagicext_flags(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e6e08
  [8] Perl_sv_clear(0x0, 0x0), at 0x4e7f5f
  [9] Perl_sv_free2(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4e8add
  [10] S_visit(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x4ded6e
  [11] perl_destruct(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x44a92b
  [12] main(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x431dce

So, that seems to be the common issue; all of the failures are coming
because of a segfault in Perl_sv_vcatpvfn.

I can provide additional info for any of the other tests you asked about,
but I'm betting focusing on this issue will clear up most or all of those.

I'll send email again when I'm able to get dbx to actually show me the
source line (or something close) where this is failing. Unfortunately,
gdb doesn't work reliably on solaris on x86_64, so I'm probably going to
be limited to what I can do with dbx.

Tim
--
Tim Mooney Tim.Mooney@​ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2012

From Tim.Mooney@ndsu.edu

In regard to​: [perl #100450] perl 5.14.2 test suite failures on...​:

[snip]

op/fork.t ......................................................... ok
op/getpid.t .......................................................
Failed 2/3 subtests

So I recompiled with both optimization and debugging, and now I can get
something useful out of dbx​:

02​:28 PM dogbert perl-5.14.2$t/perl -I lib t/op/getpid.t
1..3
ok 1 - thread modules loaded
Segmentation Fault (core dumped)

02​:28 PM dogbert perl-5.14.2$cd t/

02​:29 PM dogbert t$dbx perl core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your
.dbxrc
Reading perl
core file header read successfully
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libdl.so.1
Reading libm.so.2
Reading libpthread.so.1
Reading libc.so.1
Reading libthread.so.1
Reading threads.so
Reading Util.so
Reading shared.so
Reading attributes.so
t@​1 (l@​1) program terminated by signal SEGV (no mapping at the fault
address)
Current function is Perl_sv_vcatpvfn (optimized)
10474 elen = strlen(eptr);

(dbx) list
10474 elen = strlen(eptr);
10475 else {
10476 eptr = (char *)nullstr;
10477 elen = sizeof nullstr - 1;
10478 }
10479 }
10480 else {
10481 eptr = SvPV_const(argsv, elen);
10482 if (DO_UTF8(argsv)) {
10483 STRLEN old_precis = precis;
10484 if (has_precis && precis < elen) {
10485 STRLEN ulen = sv_len_utf8(argsv);
10486 I32 p = precis > ulen ? ulen : precis;
10487 sv_pos_u2b(argsv, &p, 0); /* sticks at end
*/
10488 precis = p;
10489 }
10490 if (width) { /* fudge width (can't fudge elen)
*/
10491 if (has_precis && precis < elen)
10492 width += precis - old_precis;
10493 else
(dbx) print eptr
eptr = 0x7364616572687c "<bad address 0x007364616572687c>"

So, it looks like eptr is not null (which is why it isn't caught by the
previous line, that checks for that) *but* it's not valid.

So why would va_arg return something that's invalid? I'm assuming that
there's a va_start somewhere up the chain that I'm not seeing.

(dbx) where
current thread​: t@​1
  [1] Perl_sv_setpvn(my_perl = <value unavailable>, sv = <value
unavailable>, ptr = <value unavailable>, len = <value unavailable>)
(inlined), line 10474 in "sv.c"
=>[2] Perl_sv_vcatpvfn(my_perl = <value unavailable>, sv = 0xa0e390, pat =
<value unavailable>, patlen = <value unavailable>, args =
0xfffffd7fffdfe1a0, svargs = <value unavailable>, svmax = 0, maybe_tainted
= (nil)) (optimized), line 10132 in "sv.c"
  [3] Perl_vnewSVpvf(my_perl = (nil), pat = (nil), args = (nil))
(optimized), at 0x5195ea (line ~9892) in "sv.c"
  [4] Perl_newSVpvf(my_perl = <value unavailable>, pat = <value
unavailable>, ... = <value unavailable>, ...) (optimized), at 0x51943f
(line ~8572) in "sv.c"
  [5] S_anonymise_cv_maybe(my_perl = 0x8e6260, gv = <value unavailable>,
cv = 0xa0e3c0) (optimized), at 0x51367e (line ~6013) in "sv.c"
  [6] Perl_sv_kill_backrefs(my_perl = 0x8e6260, sv = 0xa0e3a8, av = <value
unavailable>) (optimized), at 0x512ba1 (line ~5783) in "sv.c"
  [7] Perl_magic_killbackrefs(my_perl = <value unavailable>, sv = <value
unavailable>, mg = <value unavailable>) (optimized), at 0x4e0edd (line
~2378) in "mg.c"
  [8] Perl_sv_clear(my_perl = 0x8e6260, orig_sv = <value unavailable>)
(optimized), at 0x5138b2 (line ~5437) in "sv.c"
  [9] Perl_sv_free2(my_perl = 0x8e6260, sv = 0xa0e3a8) (optimized), at
0x514c1d (line ~6474) in "sv.c"
  [10] do_clean_all(my_perl = <value unavailable>, sv = <value
unavailable>) (inlined), line 614 in "sv.c"
  [11] Perl_sv_clean_all(my_perl = 0x5e8729) (optimized), line 420 in
"sv.c"
  [12] perl_destruct(my_perl = <value unavailable>) (optimized), at
0x455b58 (line ~1085) in "perl.c"
  [13] XS_threads_join(my_perl = 0x604ae0, cv = <value unavailable>)
(optimized), at 0xfffffd7fff03774a (line ~228) in "threads.xs"
  [14] Perl_pp_entersub(my_perl = 0x604ae0) (optimized), at 0x50650d (line
~3046) in "pp_hot.c"
  [15] Perl_runops_standard(my_perl = 0x604ae0) (optimized), at 0x4fb82e
(line ~42) in "run.c"
  [16] S_run_body(my_perl = 0x604ae0, oldscope = 1) (optimized), at
0x45869c (line ~2350) in "perl.c"
  [17] perl_run(my_perl = <value unavailable>) (optimized), at 0x4585aa
(line ~2268) in "perl.c"
  [18] main(argc = <value unavailable>, argv = <value unavailable>, env =
<value unavailable>) (optimized), at 0x434850 (line ~120) in "perlmain.c"

(dbx) print *args
*args = (
{
  __va_gp_offset = 24U
  __va_fp_offset = 48U
  __va_overflow_arg_area = 0xfffffd7fffdfe1d0
  __va_reg_sve_area = 0xfffffd7fffdfe0f0
}

diff'ing sv.c between 5.12.4 and 5.14.2 turns up a lot of changes, so
there's no trivial smoking gun here. Looks like it's going to take some
hunting to figure out what's going on here.

Suggestions for next steps to take?

Tim
--
Tim Mooney Tim.Mooney@​ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2012

From @hvds

Tim Mooney <Tim.Mooney@​ndsu.edu> wrote​:
[...]
:So, it looks like eptr is not null (which is why it isn't caught by the
:previous line, that checks for that) *but* it's not valid.
:
:So why would va_arg return something that's invalid? I'm assuming that
:there's a va_start somewhere up the chain that I'm not seeing.

That's in Perl_newSVpvf​:
  va_start(args, pat);
  sv = vnewSVpvf(pat, &args);
  va_end(args);

:(dbx) where
:current thread​: t@​1
: [1] Perl_sv_setpvn(my_perl = <value unavailable>, sv = <value
:unavailable>, ptr = <value unavailable>, len = <value unavailable>)
:(inlined), line 10474 in "sv.c"
:=>[2] Perl_sv_vcatpvfn(my_perl = <value unavailable>, sv = 0xa0e390, pat =
:<value unavailable>, patlen = <value unavailable>, args =
:0xfffffd7fffdfe1a0, svargs = <value unavailable>, svmax = 0, maybe_tainted
:= (nil)) (optimized), line 10132 in "sv.c"
: [3] Perl_vnewSVpvf(my_perl = (nil), pat = (nil), args = (nil))
:(optimized), at 0x5195ea (line ~9892) in "sv.c"
: [4] Perl_newSVpvf(my_perl = <value unavailable>, pat = <value
:unavailable>, ... = <value unavailable>, ...) (optimized), at 0x51943f
:(line ~8572) in "sv.c"
: [5] S_anonymise_cv_maybe(my_perl = 0x8e6260, gv = <value unavailable>,
:cv = 0xa0e3c0) (optimized), at 0x51367e (line ~6013) in "sv.c"
[...]
:(dbx) print *args
:*args = (
:{
: __va_gp_offset = 24U
: __va_fp_offset = 48U
: __va_overflow_arg_area = 0xfffffd7fffdfe1d0
: __va_reg_sve_area = 0xfffffd7fffdfe0f0
:}
:
:
:diff'ing sv.c between 5.12.4 and 5.14.2 turns up a lot of changes, so
:there's no trivial smoking gun here. Looks like it's going to take some
:hunting to figure out what's going on here.
:
:Suggestions for next steps to take?

The stack trace shows a discrepancy​: [3] received '(nil)' for args,
which should have been passed as-is to [2]. That looks like maybe an
optimizer bug.

HTH,

Hugo

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2012

From Tim.Mooney@ndsu.edu

On Wed Apr 18 01​:25​:10 2012, hv wrote​:

Tim Mooney <Tim.Mooney@​ndsu.edu> wrote​:
[...]
:So, it looks like eptr is not null (which is why it isn't caught by the
:previous line, that checks for that) *but* it's not valid.
:
:So why would va_arg return something that's invalid? I'm assuming that
:there's a va_start somewhere up the chain that I'm not seeing.

That's in Perl_newSVpvf​:
va_start(args, pat);
sv = vnewSVpvf(pat, &args);
va_end(args);

:(dbx) where
:current thread​: t@​1
: [1] Perl_sv_setpvn(my_perl = <value unavailable>, sv = <value
:unavailable>, ptr = <value unavailable>, len = <value unavailable>)
:(inlined), line 10474 in "sv.c"
:=>[2] Perl_sv_vcatpvfn(my_perl = <value unavailable>, sv = 0xa0e390,
pat =
:<value unavailable>, patlen = <value unavailable>, args =
:0xfffffd7fffdfe1a0, svargs = <value unavailable>, svmax = 0,
maybe_tainted
:= (nil)) (optimized), line 10132 in "sv.c"
: [3] Perl_vnewSVpvf(my_perl = (nil), pat = (nil), args = (nil))
:(optimized), at 0x5195ea (line ~9892) in "sv.c"
: [4] Perl_newSVpvf(my_perl = <value unavailable>, pat = <value
:unavailable>, ... = <value unavailable>, ...) (optimized), at 0x51943f
:(line ~8572) in "sv.c"
: [5] S_anonymise_cv_maybe(my_perl = 0x8e6260, gv = <value unavailable>,
:cv = 0xa0e3c0) (optimized), at 0x51367e (line ~6013) in "sv.c"
[...]
:(dbx) print *args
:*args = (
:{
: __va_gp_offset = 24U
: __va_fp_offset = 48U
: __va_overflow_arg_area = 0xfffffd7fffdfe1d0
: __va_reg_sve_area = 0xfffffd7fffdfe0f0
:}

The stack trace shows a discrepancy​: [3] received '(nil)' for args,
which should have been passed as-is to [2]. That looks like maybe an
optimizer bug.

I think that's just a display artifact because the optimizer may have
inlined all of [3].

I rebuilt 5.14.2 with -xinline= (i.e. all inlining turned off) and I
still get the same failures, but the stack trace is a little more readable​:

12​:26 PM dogbert perl-5.14.2$t/perl -I lib t/op/getpid.t
1..3
ok 1 - thread modules loaded
Segmentation Fault (core dumped)
12​:27 PM dogbert perl-5.14.2$cd t
/local/src/RPM/BUILD/perl-5.14.2/t
12​:27 PM dogbert t$dbx perl core
Reading perl
core file header read successfully
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libdl.so.1
Reading libm.so.2
Reading libpthread.so.1
Reading libc.so.1
Reading libthread.so.1
Reading threads.so
Reading Util.so
Reading shared.so
Reading attributes.so
t@​1 (l@​1) program terminated by signal SEGV (no mapping at the fault
address)
Current function is Perl_sv_vcatpvfn (optimized)
10474 elen = strlen(eptr);
(dbx) where
current thread​: t@​1
=>[1] Perl_sv_vcatpvfn(my_perl = <value unavailable>, sv = 0x9cdc60, pat
= <value unavailable>, patlen = <value unavailable>, args =
0xfffffd7fffdfe100, svargs = <value unavailable>, svmax = 0,
maybe_tainted = (nil)) (optimized), at 0x4f7860 (line ~10474) in "sv.c"
  [2] Perl_sv_vsetpvfn(my_perl = 0x8a5be0, sv = 0x9cdc60, pat = 0x5a7f58
"%s​::__ANON__", patlen = 12U, args = 0xfffffd7fffdfe100, svargs = (nil),
svmax = 0, maybe_tainted = (nil)) (optimized), at 0x4f519e (line ~9892)
in "sv.c"
  [3] Perl_vnewSVpvf(my_perl = 0x8a5be0, pat = 0x5a7f58 "%s​::__ANON__",
args = 0xfffffd7fffdfe100) (optimized), at 0x4f2b63 (line ~8588) in "sv.c"
  [4] Perl_newSVpvf(my_perl = <value unavailable>, pat = <value
unavailable>, ... = <value unavailable>, ...) (optimized), at 0x4f2a65
(line ~8572) in "sv.c"
  [5] S_anonymise_cv_maybe(my_perl = 0x8a5be0, gv = <value unavailable>,
cv = 0x9cdc90) (optimized), at 0x4ee14e (line ~6013) in "sv.c"
  [6] Perl_sv_kill_backrefs(my_perl = 0x8a5be0, sv = 0x9cdc78, av =
<value unavailable>) (optimized), at 0x4ed701 (line ~5783) in "sv.c"
  [7] Perl_magic_killbackrefs(my_perl = <value unavailable>, sv = <value
unavailable>, mg = <value unavailable>) (optimized), at 0x4c1c8d (line
~2378) in "mg.c"
  [8] S_sv_unmagicext_flags(my_perl = 0x8a5be0, sv = 0x9cdc78, type =
60, vtbl = <value unavailable>, flags = <value unavailable>)
(optimized), at 0x4ed1b8 (line ~5437) in "sv.c"
  [9] Perl_sv_unmagic(my_perl = <value unavailable>, sv = <value
unavailable>, type = <value unavailable>) (optimized), at 0x4ed28f (line
~5476) in "sv.c"
  [10] Perl_sv_clear(my_perl = 0x8a5be0, orig_sv = <value unavailable>)
(optimized), at 0x4ee37f (line ~6084) in "sv.c"
  [11] Perl_sv_free2(my_perl = 0x8a5be0, sv = 0x9cdc78) (optimized), at
0x4eef2d (line ~6474) in "sv.c"
  [12] Perl_sv_free(my_perl = 0x8a5be0, sv = 0x9cdc78) (optimized), at
0x4eee26 (line ~6451) in "sv.c"
  [13] do_clean_all(my_perl = <value unavailable>, sv = <value
unavailable>) (optimized), at 0x4e53f2 (line ~614) in "sv.c"
  [14] S_visit(my_perl = <value unavailable>, f = 0x4e53d0 =
&`perl`sv.c`do_clean_all(PerlInterpreter *my_perl, SV *const sv), flags
= 0, mask = 0) (optimized), at 0x4e4fd0 (line ~420) in "sv.c"
  [15] Perl_sv_clean_all(my_perl = <value unavailable>) (optimized), at
0x4e541b (line ~633) in "sv.c"
  [16] perl_destruct(my_perl = <value unavailable>) (optimized), at
0x44d66b (line ~1085) in "perl.c"
  [17] S_ithread_clear(my_perl = 0x5c4310, thread = 0x8b25d0)
(optimized), at 0xfffffd7fff03340f (line ~228) in "threads.xs"
  [18] XS_threads_join(my_perl = 0x5c4310, cv = <value unavailable>)
(optimized), at 0xfffffd7fff0368dc (line ~1306) in "threads.xs"
  [19] Perl_pp_entersub(my_perl = 0x5c4310) (optimized), at 0x4e38c0
(line ~3046) in "pp_hot.c"
  [20] Perl_runops_standard(my_perl = 0x5c4310) (optimized), at 0x4d798e
(line ~42) in "run.c"
  [21] S_run_body(my_perl = 0x5c4310, oldscope = 1) (optimized), at
0x44f6dc (line ~2350) in "perl.c"
  [22] perl_run(my_perl = <value unavailable>) (optimized), at 0x44f5ea
(line ~2268) in "perl.c"
  [23] main(argc = <value unavailable>, argv = <value unavailable>, env
= <value unavailable>) (optimized), at 0x434250 (line ~120) in "perlmain.c"

(dbx) up
Current function is Perl_sv_vsetpvfn (optimized)
9892 sv_vcatpvfn(sv, pat, patlen, args, svargs, svmax,
maybe_tainted);
(dbx) print sv
sv = 0x9cdc60
(dbx) print *sv
*sv = {
  sv_any = 0x9bba20
  sv_refcnt = 1U
  sv_flags = 17412U
  sv_u = {
  svu_pv = 0x9bd920 ""
  svu_iv = 10213664
  svu_uv = 10213664U
  svu_rv = 0x9bd920
  svu_array = 0x9bd920
  svu_hash = 0x9bd920
  svu_gp = 0x9bd920
  svu_fp = 0x9bd920
  }
}
(dbx) print pat
pat = 0x5a7f58 "%s​::__ANON__"
(dbx) print patlen
patlen = 12U
(dbx) print args
args = 0xfffffd7fffdfe100
(dbx) print *args
*args = (
{
  __va_gp_offset = 24U
  __va_fp_offset = 48U
  __va_overflow_arg_area = 0xfffffd7fffdfe130
  __va_reg_sve_area = 0xfffffd7fffdfe050
}

@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2012

From @hvds

"Tim.Mooney@​ndsu.edu via RT" <perlbug-followup@​perl.org> wrote​:
:I rebuilt 5.14.2 with -xinline= (i.e. all inlining turned off) and I
:still get the same failures, but the stack trace is a little more readable​:

Ok, I guess the first question should have been​: is the value being passed
in actually NULL?

As far as I can see it should not be​: the calling code from
S_anonymise_cv_maybe says​:
  gvname = Perl_newSVpvf(aTHX_ "%s​::__ANON__",
  stash ? stash : "__ANON__");
.. but it would be instructive to check what 'stash' is at that point.

Note this is happening within sv_kill_backrefs, which has had several
bugs fixed in recent months (mostly by davem, I think); it may be worth
trying a (soon to be 5.16) bleadperl instead.

But for diagnosing this issue, I think the next step should be to try
compiling sv.c with no optimization at all.

Hugo

@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2012

From Tim.Mooney@ndsu.edu

In regard to​: Re​: [perl #100450] perl 5.14.2 test suite failures on...​:

"Tim.Mooney@​ndsu.edu via RT" <perlbug-followup@​perl.org> wrote​:
:I rebuilt 5.14.2 with -xinline= (i.e. all inlining turned off) and I
:still get the same failures, but the stack trace is a little more readable​:

Ok, I guess the first question should have been​: is the value being passed
in actually NULL?

As far as I can see it should not be​: the calling code from
S_anonymise_cv_maybe says​:
gvname = Perl_newSVpvf(aTHX_ "%s​::__ANON__",
stash ? stash : "__ANON__");
.. but it would be instructive to check what 'stash' is at that point.

(dbx) up
Current function is Perl_vnewSVpvf (optimized)
  8588 sv_vsetpvfn(sv, pat, strlen(pat), args, NULL, 0, NULL);
(dbx) up
Current function is Perl_newSVpvf (optimized)
  8572 sv = vnewSVpvf(pat, &args);
(dbx) up
Current function is S_anonymise_cv_maybe (optimized)
  6013 stash ? stash : "__ANON__");
(dbx) print stash
dbx​: warning​: variable `stash' has no address - unused or optimized out

Note this is happening within sv_kill_backrefs, which has had several
bugs fixed in recent months (mostly by davem, I think); it may be worth
trying a (soon to be 5.16) bleadperl instead.

But for diagnosing this issue, I think the next step should be to try
compiling sv.c with no optimization at all.

I dropped the optimization to -xO2 for just sv.o and the problem no
longer happens. That doesn't necessarily prove it's an optimizer bug,
but I'm comfortable with using that as a workaround. I can still
continue to use the same optimization flags that I've used for years for
the rest of perl, and I'll just use different flags for sv.o.

I'll check 5.16 once it's actually released, to see if the issue is still
present.

Tim
--
Tim Mooney Tim.Mooney@​ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

@p5pRT
Copy link
Author

p5pRT commented Jul 23, 2012

From @khwilliamson

On Thu Apr 19 12​:26​:11 2012, enchanter wrote​:

In regard to​: Re​: [perl #100450] perl 5.14.2 test suite failures
on...​:

"Tim.Mooney@​ndsu.edu via RT" <perlbug-followup@​perl.org> wrote​:
:I rebuilt 5.14.2 with -xinline= (i.e. all inlining turned off)
and I
:still get the same failures, but the stack trace is a little more
readable​:

Ok, I guess the first question should have been​: is the value being
passed
in actually NULL?

As far as I can see it should not be​: the calling code from
S_anonymise_cv_maybe says​:
gvname = Perl_newSVpvf(aTHX_ "%s​::__ANON__",
stash ? stash : "__ANON__");
.. but it would be instructive to check what 'stash' is at that
point.

(dbx) up
Current function is Perl_vnewSVpvf (optimized)
8588 sv_vsetpvfn(sv, pat, strlen(pat), args, NULL, 0, NULL);
(dbx) up
Current function is Perl_newSVpvf (optimized)
8572 sv = vnewSVpvf(pat, &args);
(dbx) up
Current function is S_anonymise_cv_maybe (optimized)
6013 stash ? stash :
"__ANON__");
(dbx) print stash
dbx​: warning​: variable `stash' has no address - unused or optimized
out

Note this is happening within sv_kill_backrefs, which has had
several
bugs fixed in recent months (mostly by davem, I think); it may be
worth
trying a (soon to be 5.16) bleadperl instead.

But for diagnosing this issue, I think the next step should be to
try
compiling sv.c with no optimization at all.

I dropped the optimization to -xO2 for just sv.o and the problem no
longer happens. That doesn't necessarily prove it's an optimizer bug,
but I'm comfortable with using that as a workaround. I can still
continue to use the same optimization flags that I've used for years
for
the rest of perl, and I'll just use different flags for sv.o.

I'll check 5.16 once it's actually released, to see if the issue is
still
present.

Tim

5.16 is now out. Please see if the issue got fixed.
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Aug 22, 2012

From @cpansprout

Fixed by 1bac5ec, according to #91678.

@p5pRT
Copy link
Author

p5pRT commented Aug 22, 2012

From [Unknown Contact. See original ticket]

Fixed by 1bac5ec, according to #91678.

@p5pRT
Copy link
Author

p5pRT commented Aug 22, 2012

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

@p5pRT p5pRT closed this as completed Aug 22, 2012
@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2012

From Tim.Mooney@ndsu.edu

On Wed Aug 22 08​:35​:04 2012, sprout wrote​:

Fixed by 1bac5ec, according to #91678.

Sorry for the delay in responding. I can confirm that #91678 is
correct, the patch fixes the issue.

Thanks!

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