p5pRT
commented
12 years ago From Tim.Mooney@ndsu.edu
Body was too large for import. Click here for the attachment in RT
Closed p5pRT closed 12 years ago
p5pRT
commented
12 years ago Body was too large for import. Click here for the attachment in RT
p5pRT
commented
12 years ago 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
commented
12 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
12 years ago 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
commented
12 years ago 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
commented
12 years ago 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
commented
12 years ago 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 = \
(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
commented
12 years ago 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 = \
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
commented
12 years ago 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 = \
\, sv = \<value :unavailable>\, ptr = \ \, len = \ ) :(inlined)\, line 10474 in "sv.c" :=>[2] Perl_sv_vcatpvfn(my_perl = \ \, sv = 0xa0e390\, pat = :\ \, patlen = \ \, args = :0xfffffd7fffdfe1a0\, svargs = \ \, 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 = \ \, pat = \<value :unavailable>\, ... = \ \, ...) (optimized)\, at 0x51943f :(line ~8572) in "sv.c" : [5] S_anonymise_cv_maybe(my_perl = 0x8e6260\, gv = \ \, :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 = \
(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
commented
12 years ago "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
commented
12 years ago 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
commented
12 years ago 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
commented
12 years ago Fixed by 1bac5ec\, according to #91678.
p5pRT
commented
12 years ago Fixed by 1bac5ec\, according to #91678.
p5pRT
commented
12 years ago @cpansprout - Status changed from 'open' to 'resolved'
p5pRT
commented
12 years ago 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!
Migrated from rt.perl.org#100450 (status was 'resolved')
Searchable as RT100450$