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

Problem with stack moving fix for Perl_load_module #14921

Closed
p5pRT opened this issue Sep 23, 2015 · 14 comments
Closed

Problem with stack moving fix for Perl_load_module #14921

p5pRT opened this issue Sep 23, 2015 · 14 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 23, 2015

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

Searchable as RT126145$

@p5pRT
Copy link
Author

p5pRT commented Sep 23, 2015

From @mschout

Since upgrading to 5.20, we started seeing our modperl process crash
while pre-compiling a long list of modules in our code. We have a chunk
of code that uses File​::Find and converts the filenames it finds into
module names, then uses Class​::Load to load each module in turn​:

  for my $mod (@​modules) {
  unless (is_class_loaded($mod)) {
  eval "require $mod;";
  }
  }

This crashes on my codebase under CentOS 7 since 5.20.

Here is one such crash with 5.20.3 with DEBUGGING enabled​:

*** Error in `perl'​: free()​: invalid pointer​: 0x000000000adb5978 ***
======= Backtrace​: =========
/lib64/libc.so.6(+0x7d1fd)[0x7f16c3dd01fd]
perl(Perl_parser_free+0xca)[0x45a78a]
perl(Perl_leave_scope+0xa48)[0x5500f8]
perl(Perl_pp_leaveeval+0x1eb)[0x56e0bb]
perl(Perl_runops_debug+0x43)[0x4c8b23]
perl(Perl_call_sv+0x5f1)[0x4406d1]
/home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Sub/Attribute/Attribute.so(+0x271b)[0x7f16ba2cb71b]
perl[0x4d2b38]
perl(Perl_mg_free+0x3e)[0x4d383e]
perl(Perl_sv_clear+0x807)[0x50f8e7]
perl(Perl_sv_free2+0x5d)[0x51045d]
perl(Perl_leave_scope+0x12ab)[0x55095b]
perl(Perl_block_end+0x3d6)[0x42c676]
perl(Perl_yyparse+0x127e)[0x483dae]
perl[0x5546d8]
perl(Perl_pp_require+0x12fa)[0x56b10a]
perl(Perl_runops_debug+0x43)[0x4c8b23]
perl(Perl_call_sv+0x5f1)[0x4406d1]
perl(Perl_call_list+0x465)[0x443be5]
perl[0x41f3e4]
perl(Perl_newATTRSUB_x+0xa6f)[0x43819f]
perl(Perl_utilize+0x3b0)[0x43ba30]
perl(Perl_yyparse+0x218c)[0x484cbc]
perl[0x5546d8]
perl(Perl_pp_require+0x12fa)[0x56b10a]
perl(Perl_runops_debug+0x43)[0x4c8b23]
perl(Perl_call_sv+0x5f1)[0x4406d1]
perl(Perl_call_list+0x465)[0x443be5]
perl[0x41f3e4]
perl(Perl_newATTRSUB_x+0xa6f)[0x43819f]
perl(Perl_utilize+0x3b0)[0x43ba30]
perl(Perl_yyparse+0x218c)[0x484cbc]
perl[0x5546d8]
perl(Perl_pp_require+0x12fa)[0x56b10a]
perl(Perl_runops_debug+0x43)[0x4c8b23]
perl(Perl_call_sv+0x5f1)[0x4406d1]
perl(Perl_call_list+0x465)[0x443be5]
perl[0x41f3e4]
perl(Perl_newATTRSUB_x+0xa6f)[0x43819f]
perl(Perl_utilize+0x3b0)[0x43ba30]
perl(Perl_yyparse+0x218c)[0x484cbc]
perl[0x5546d8]
perl(Perl_pp_require+0x12fa)[0x56b10a]
perl(Perl_runops_debug+0x43)[0x4c8b23]
perl(perl_run+0x663)[0x44a603]
perl(main+0x11b)[0x41e8fb]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f16c3d74af5]
perl[0x41e935]
======= Memory map​: ========
00400000-006bd000 r-xp 00000000 fd​:01 2200335 /home/mschout/test/build/bin/perl
008bc000-008c1000 r--p 002bc000 fd​:01 2200335 /home/mschout/test/build/bin/perl
008c1000-008c4000 rw-p 002c1000 fd​:01 2200335 /home/mschout/test/build/bin/perl
008c4000-008c5000 rw-p 00000000 00​:00 0
02408000-0ade1000 rw-p 00000000 00​:00 0 [heap]
7f16b301d000-7f16b3032000 r-xp 00000000 fd​:01 67150711 /usr/lib64/libgcc_s-4.8.3-20140911.so.1
7f16b3032000-7f16b3231000 ---p 00015000 fd​:01 67150711 /usr/lib64/libgcc_s-4.8.3-20140911.so.1
7f16b3231000-7f16b3232000 r--p 00014000 fd​:01 67150711 /usr/lib64/libgcc_s-4.8.3-20140911.so.1
7f16b3232000-7f16b3233000 rw-p 00015000 fd​:01 67150711 /usr/lib64/libgcc_s-4.8.3-20140911.so.1
7f16b3233000-7f16b3260000 r-xp 00000000 fd​:01 67229680 /home/mschout/test/build/lib/libGeoIP.so.1.5.0
7f16b3260000-7f16b345f000 ---p 0002d000 fd​:01 67229680 /home/mschout/test/build/lib/libGeoIP.so.1.5.0
7f16b345f000-7f16b3460000 r--p 0002c000 fd​:01 67229680 /home/mschout/test/build/lib/libGeoIP.so.1.5.0
7f16b3460000-7f16b3462000 rw-p 0002d000 fd​:01 67229680 /home/mschout/test/build/lib/libGeoIP.so.1.5.0
7f16b3462000-7f16b3477000 r-xp 00000000 fd​:01 105018346 /home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Geo/IP/IP.so
7f16b3477000-7f16b3676000 ---p 00015000 fd​:01 105018346 /home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Geo/IP/IP.so
7f16b3676000-7f16b3677000 r--p 00014000 fd​:01 105018346 /home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Geo/IP/IP.so
7f16b3677000-7f16b3678000 rw-p 00015000 fd​:01 105018346 /home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Geo/IP/IP.so
7f16b3678000-7f16b3691000 r-xp 00000000 fd​:01 74911406 /home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Text/CSV_XS/CSV_XS.so
7f16b3691000-7f16b3890000 ---p 00019000 fd​:01 74911406 /home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Text/CSV_XS/CSV_XS.so
7f16b3890000-7f16b3891000 r--p 00018000 fd​:01 74911406 /home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Text/CSV_XS/CSV_XS.so
7f16b3891000-7f16b3892000 rw-p 00019000 fd​:01 74911406 /home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Text/CSV_XS/CSV_XS.so
7f16b3892000-7f16b38b6000 r-xp 00000000 fd​:01 67237851 /usr/lib64/liblzma.so.5.0.99
7f16b38b6000-7f16b3ab5000 ---p 00024000 fd​:01 67237851 /usr/lib64/liblzma.so.5.0.99
7f16b3ab5000-7f16b3ab6000 r--p 00023000 fd​:01 67237851 /usr/lib64/liblzma.so.5.0.99
7f16b3ab6000-7f16b3ab7000 rw-p 00024000 fd​:01 67237851 /usr/lib64/liblzma.so.5.0.99
7f16b3ab7000-7f16b3b16000 r-xp 00000000 fd​:01 67251479 /usr/lib64/libpcre.so.1.2.0
7f16b3b16000-7f16b3d16000 ---p 0005f000 fd​:01 67251479 /usr/lib64/libpcre.so.1.2.0
7f16b3d16000-7f16b3d17000 r--p 0005f000 fd​:01 67251479 /usr/lib64/libpcre.so.1.2.0
7f16b3d17000-7f16b3d18000 rw-p 00060000 fd​:01 67251479 /usr/lib64/libpcre.so.1.2.0
7f16b3d18000-7f16b3d39000 r-xp 00000000 fd​:01 67251496 /usr/lib64/libselinux.so.1
7f16b3d39000-7f16b3f39000 ---p 00021000 fd​:01 67251496 /usr/lib64/libselinux.so.1
7f16b3f39000-7f16b3f3a000 r--p 00021000 fd​:01 67251496 /usr/lib64/libselinux.so.1
7f16b3f3a000-7f16b3f3b000 rw-p 00022000 fd​:01 67251496 /usr/lib64/libselinux.so.1
7f16b3f3b000-7f16b3f3d000 rw-p 00000000 00​:00 0
7f16b3f3d000-7f16b3f53000 r-xp 00000000 fd​:01 67150751 /usr/lib64/libresolv-2.17.so
7f16b3f53000-7f16b4153000 ---p 00016000 fd​:01 67150751 /usr/lib64/libresolv-2.17.so
7f16b4153000-7f16b4154000 r--p 00016000 fd​:01 67150751 /usr/lib64/libresolv-2.17.so
7f16b4154000-7f16b4155000 rw-p 00017000 fd​:01 67150751 /usr/lib64/libresolv-2.17.so
7f16b4155000-7f16b4157000 rw-p 00000000 00​:00 0
7f16b4157000-7f16b415a000 r-xp 00000000 fd​:01 67328820 /usr/lib64/libkeyutils.so.1.5
7f16b415a000-7f16b4359000 ---p 00003000 fd​:01 67328820 /usr/lib64/libkeyutils.so.1.5
7f16b4359000-7f16b435a000 r--p 00002000 fd​:01 67328820 /usr/lib64/libkeyutils.so.1.5

I bisected for where this broke, and the first bad commit is​:

commit ebdc880
Author​: Nicholas Clark <nick@​ccl4.org>
Date​: Fri Oct 4 14​:54​:00 2013 +0200

  S_process_special_blocks() should use a new stack for BEGIN blocks.
 
  This avoids the stack moving underneath anything that directly or indirectly
  calls Perl_load_module().
 
  [Committer’s note​:
 
  This fixes bug #119993.
 
  Furthermore, under STRESS_REALLOC, t/io/layers.t was crashing like this​:
 
  $ ./perl -Ilib -e ' open(UTF, "<​:raw​:encoding(utf8)", 'tmp75851B') or die $!; ref #blahblahblahblahblahblahblahblahblah'
  Segmentation fault​: 11
 
  (The comment seems to be necessary to make it crash.)
 
  It was happening because open() was causing a module to be loaded
  while the arguments to open() were still on the stack.
  ]

Inline Patch
diff --git a/op.c b/op.c
index 030039d..8a60800 100644
--- a/op.c
+++ b/op.c
@@ -7957,8 +7957,10 @@ S_process_special_blocks(pTHX_ I32 floor, const char *const fullname,
     if (*name == 'B') {
        if (strEQ(name, "BEGIN")) {
            const I32 oldscope = PL_scopestack_ix;
+            dSP;
            if (floor) LEAVE_SCOPE(floor);
            ENTER;
+            PUSHSTACKi(PERLSI_REQUIRE);
            SAVECOPFILE(&PL_compiling);
            SAVECOPLINE(&PL_compiling);
            SAVEVPTR(PL_curcop);
@@ -7968,6 +7970,7 @@ S_process_special_blocks(pTHX_ I32 floor, const char *const fullname,
            GvCV_set(gv,0);             /* cv has been hijacked */
            call_list(oldscope, PL_beginav);
 
+            POPSTACK;
            LEAVE;
        }
        else

I also tested this on OS X Darwin and it does NOT crash there. So perhaps this is linux specific?

I reversed the above commit against 5.20.3 and the problem goes away (although
probably bringing back whatever problem that commit was attempting to solve).
A quick skim of #119993 leads me to think that this commit was not an ideal fix.
If anyone has any insight as to how to improve the fix or why it might cause the
crash I am seeing I'd love to hear it.

It does seem to matter what modules are that are loaded to trigger the bug, so
I have not been able to create a simplified test case for this at this time.

Regards,
Michael Schout

@p5pRT
Copy link
Author

p5pRT commented Sep 23, 2015

From @mschout

On Wed Sep 23 11​:21​:00 2015, mschout@​gkg.net wrote​:

Since upgrading to 5.20, we started seeing our modperl process crash

Just to clarify​:

The above crash was produced with plain "perl". Outside of modperl.

So modperl is not involved with this bug.

@p5pRT
Copy link
Author

p5pRT commented Sep 23, 2015

From @mschout

After further investigation, this commit seems to be related to Sub​::Attribute. I dropped Sub​::Attribute and the problem went away.

@p5pRT
Copy link
Author

p5pRT commented Sep 24, 2015

From @jkeenan

On Wed Sep 23 15​:01​:00 2015, mschout@​gkg.net wrote​:

After further investigation, this commit seems to be related to
Sub​::Attribute. I dropped Sub​::Attribute and the problem went away.

Can you explain what role Sub​::Attribute was playing in the code in which you encountered the problem?

Thank you very much.

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

@p5pRT
Copy link
Author

p5pRT commented Sep 24, 2015

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

@p5pRT
Copy link
Author

p5pRT commented Sep 24, 2015

From @mschout

On Wed Sep 23 17​:01​:40 2015, jkeenan wrote​:

On Wed Sep 23 15​:01​:00 2015, mschout@​gkg.net wrote​:

After further investigation, this commit seems to be related to
Sub​::Attribute. I dropped Sub​::Attribute and the problem went away.

Can you explain what role Sub​::Attribute was playing in the code in
which you encountered the problem?

James​:

I had a bit of time today to dig into this a bit more by deleting all of the ATTR_SUB bodies in my code and adding things back a few lines at a time to figure out what makes it crash.

Bottom line is that its a combination of using Sub​::Attribute and Class​::Trigger.

Armed with that I was finally able to create a simple test case.

I've attached a short perl script that crashes (with segmentation fault) for me on centos 7.

FWIW, I'm using the latest versions of Class​::Trigger (0.14), and Sub​::Attribute (0.05)

Starting program​: /home/mschout/test/build/bin/perl testme.pl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
Perl_pp_entersub () at pp_hot.c​:2541
2541 if (!LIKELY(SvTYPE(sv) == SVt_PVGV && (cv = GvCVu((const GV *)sv)))) {
(gdb) bt
#0 Perl_pp_entersub () at pp_hot.c​:2541
#1 0x0000000000440b10 in Perl_call_sv (sv=0x8e9220, flags=<optimized out>) at perl.c​:2775
#2 0x00007ffff0174fbd in sa_process_queue () from /home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-linux/auto/Sub/Attribute/Attribute.so
#3 0x00000000004d2b38 in S_mg_free_struct (sv=sv@​entry=0x8c7088, mg=0x8f3c70) at mg.c​:549
#4 0x00000000004d383e in Perl_mg_free (sv=sv@​entry=0x8c7088) at mg.c​:579
#5 0x000000000050f8e7 in Perl_sv_clear (orig_sv=orig_sv@​entry=0x8c7088) at sv.c​:6334
#6 0x000000000051045d in Perl_sv_free2 (sv=0x8c7088, rc=<optimized out>) at sv.c​:6805
#7 0x000000000055095b in S_SvREFCNT_dec (sv=<optimized out>) at inline.h​:123
#8 Perl_leave_scope (base=base@​entry=22) at scope.c​:1197
#9 0x000000000042c676 in Perl_block_end (floor=22, seq=<optimized out>) at op.c​:3180
#10 0x0000000000483dae in Perl_yyparse (gramtype=gramtype@​entry=258) at perly.y​:147
#11 0x0000000000448340 in S_parse_body (env=env@​entry=0x0, xsinit=xsinit@​entry=0x41ea00 <xs_init>) at perl.c​:2302
#12 0x0000000000449b5f in perl_parse (my_perl=<optimized out>, xsinit=xsinit@​entry=0x41ea00 <xs_init>, argc=2, argv=0x7fffffffe048, env=env@​entry=0x0)
  at perl.c​:1607
#13 0x000000000041e874 in main (argc=2, argv=0x7fffffffe048, env=0x7fffffffe060) at perlmain.c​:112

On my system this happens on the 32nd time add_trigger is called.

@p5pRT
Copy link
Author

p5pRT commented Sep 24, 2015

From @mschout

testme.pl

@p5pRT
Copy link
Author

p5pRT commented Sep 24, 2015

From @mschout

On Thu Sep 24 12​:27​:31 2015, mschout@​gkg.net wrote​:

On Wed Sep 23 17​:01​:40 2015, jkeenan wrote​:

On Wed Sep 23 15​:01​:00 2015, mschout@​gkg.net wrote​:

After further investigation, this commit seems to be related to
Sub​::Attribute. I dropped Sub​::Attribute and the problem went
away.

Can you explain what role Sub​::Attribute was playing in the code in
which you encountered the problem?

James​:

I had a bit of time today to dig into this a bit more by deleting all
of the ATTR_SUB bodies in my code and adding things back a few lines
at a time to figure out what makes it crash.

Bottom line is that its a combination of using Sub​::Attribute and
Class​::Trigger.

Hmm.. I'm not sure that the segv the above test case creates is the same bug.\

In my *real* code, the minimum amount needed to crash it is the following ATTR_SUB handler​:

sub RunMode :ATTR_SUB {
  my ($class, $sym_ref, $code_ref, $name, $attr_data) = @​_;

  (my $mode = $sym_ref) =~ s/^.*​:://;

  $class->add_trigger(before_setup => sub { shift->run_mode_methods($mode) });
}

This crashes when processed by loading modules in the loop at the beginning of this bug report.

There are other ATTR_SUB's, but I have deleted the contents of all of those.

e.g.​:

sub Cache :ATTR_SUB {
}

the only one I have left filled in is RunMode, and only with the minimum amount necessary to crash the interpreter.

Again, not sure if this is the same bug as the test case attached earlier or not, but this is enough to crash it for me.

I switched from Sub​::Attribute to an Attribute​::Handlers based implementation and the problem went away.

Armed with that I was finally able to create a simple test case.

I've attached a short perl script that crashes (with segmentation
fault) for me on centos 7.

FWIW, I'm using the latest versions of Class​::Trigger (0.14), and
Sub​::Attribute (0.05)

Starting program​: /home/mschout/test/build/bin/perl testme.pl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
Perl_pp_entersub () at pp_hot.c​:2541
2541 if (!LIKELY(SvTYPE(sv) == SVt_PVGV && (cv = GvCVu((const
GV *)sv)))) {
(gdb) bt
#0 Perl_pp_entersub () at pp_hot.c​:2541
#1 0x0000000000440b10 in Perl_call_sv (sv=0x8e9220, flags=<optimized
out>) at perl.c​:2775
#2 0x00007ffff0174fbd in sa_process_queue () from
/home/mschout/test/build/lib/perl5/site_perl/5.20.3/x86_64-
linux/auto/Sub/Attribute/Attribute.so
#3 0x00000000004d2b38 in S_mg_free_struct (sv=sv@​entry=0x8c7088,
mg=0x8f3c70) at mg.c​:549
#4 0x00000000004d383e in Perl_mg_free (sv=sv@​entry=0x8c7088) at
mg.c​:579
#5 0x000000000050f8e7 in Perl_sv_clear
(orig_sv=orig_sv@​entry=0x8c7088) at sv.c​:6334
#6 0x000000000051045d in Perl_sv_free2 (sv=0x8c7088, rc=<optimized
out>) at sv.c​:6805
#7 0x000000000055095b in S_SvREFCNT_dec (sv=<optimized out>) at
inline.h​:123
#8 Perl_leave_scope (base=base@​entry=22) at scope.c​:1197
#9 0x000000000042c676 in Perl_block_end (floor=22, seq=<optimized
out>) at op.c​:3180
#10 0x0000000000483dae in Perl_yyparse (gramtype=gramtype@​entry=258)
at perly.y​:147
#11 0x0000000000448340 in S_parse_body (env=env@​entry=0x0,
xsinit=xsinit@​entry=0x41ea00 <xs_init>) at perl.c​:2302
#12 0x0000000000449b5f in perl_parse (my_perl=<optimized out>,
xsinit=xsinit@​entry=0x41ea00 <xs_init>, argc=2, argv=0x7fffffffe048,
env=env@​entry=0x0)
at perl.c​:1607
#13 0x000000000041e874 in main (argc=2, argv=0x7fffffffe048,
env=0x7fffffffe060) at perlmain.c​:112

On my system this happens on the 32nd time add_trigger is called.

@p5pRT
Copy link
Author

p5pRT commented Sep 24, 2015

From @mschout

Here's the crash from the above RunMode implementation​:

*** Error in `perl'​: corrupted double-linked list​: 0x000000000192bf50 ***
======= Backtrace​: =========
/lib64/libc.so.6(+0x7bc67)[0x7f0243a97c67]
/lib64/libc.so.6(+0x7fb85)[0x7f0243a9bb85]
/lib64/libc.so.6(realloc+0xd2)[0x7f0243a9c702]
perl(Perl_safesysrealloc+0x35)[0x4cb395]
perl(Perl_sv_grow+0xd4)[0x5127a4]
perl(Perl_lex_grow_linestr+0xf5)[0x45a9d5]
perl(Perl_block_start+0xfa)[0x42364a]
perl(Perl_yyparse+0x13a5)[0x483ed5]
perl[0x5546d8]
perl(Perl_pp_entereval+0x533)[0x56d473]
perl(Perl_runops_debug+0x43)[0x4c8b23]
perl(Perl_call_sv+0x5f1)[0x4406d1]
perl(Perl_call_list+0x465)[0x443be5]
perl[0x41f3e4]
perl(Perl_newATTRSUB_x+0xa6f)[0x43819f]
perl(Perl_utilize+0x3b0)[0x43ba30]
perl(Perl_yyparse+0x218c)[0x484cbc]
perl[0x5546d8]
perl(Perl_pp_require+0x12fa)[0x56b10a]
perl(Perl_runops_debug+0x43)[0x4c8b23]
perl(perl_run+0x663)[0x44a603]
perl(main+0x11b)[0x41e8fb]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f0243a3daf5]
perl[0x41e935]

Note that this too is different from the original crash (free() invalid next pointer). But this backtrace looks more like the original one. strange.

@p5pRT
Copy link
Author

p5pRT commented Oct 6, 2015

From @iabyn

On Wed, Sep 23, 2015 at 11​:21​:00AM -0700, Michael Schout wrote​:

Since upgrading to 5.20, we started seeing our modperl process crash
while pre-compiling a long list of modules in our code. We have a chunk
of code that uses File​::Find and converts the filenames it finds into
module names, then uses Class​::Load to load each module in turn​:

for my $mod (@​modules) {
unless (is_class_loaded($mod)) {
eval "require $mod;";
}
}

It appears to be a bug in Sub​::Attribute (note that this modules is at
v0.05 and was least released 5 years ago, so it might not be actively
maintained).

At one point it does​:

  PL_stack_sp -= call_sv(method, G_VOID | G_EVAL);

If the stack happens to to be grown and reallocated during the call to
call_sv(), then the new value of PL_stack_sp is overwritten with the
*old* value less whatever call_sv returns.

It probably needs to be rewritten as​:

  I32 retcount;

  retcount = call_sv(method, G_VOID | G_EVAL);
  PL_stack_sp -= retcount;

or possibly

  retcount = call_sv(method, G_VOID | G_EVAL | G_DISCARD);

--
Music lesson​: a symbiotic relationship whereby a pupil's embellishments
concerning the amount of practice performed since the last lesson are
rewarded with embellishments from the teacher concerning the pupil's
progress over the corresponding period.

@p5pRT
Copy link
Author

p5pRT commented Oct 6, 2015

From @bulk88

On Tue Oct 06 06​:32​:12 2015, davem wrote​:

It appears to be a bug in Sub​::Attribute (note that this modules is at
v0.05 and was least released 5 years ago, so it might not be actively
maintained).

At one point it does​:

PL\_stack\_sp \-= call\_sv\(method\, G\_VOID | G\_EVAL\);

If the stack happens to to be grown and reallocated during the call to
call_sv(), then the new value of PL_stack_sp is overwritten with the
*old* value less whatever call_sv returns.

It probably needs to be rewritten as​:

I32 retcount;

retcount = call\_sv\(method\, G\_VOID | G\_EVAL\);
PL\_stack\_sp \-= retcount;

or possibly

retcount = call\_sv\(method\, G\_VOID | G\_EVAL | G\_DISCARD\);

Remind me of problem described in https://rt.cpan.org/Public/Bug/Display.html?id=92570

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Oct 6, 2015

From @bulk88

On Tue Oct 06 12​:53​:50 2015, bulk88 wrote​:

Remind me of problem described in
https://rt.cpan.org/Public/Bug/Display.html?id=92570

*That RemindS me of problem described in https://rt.cpan.org/Public/Bug/Display.html?id=92570

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Oct 6, 2015

From @mschout

On Tue Oct 06 06​:32​:12 2015, davem wrote​:

It appears to be a bug in Sub​::Attribute (note that this modules is at
v0.05 and was least released 5 years ago, so it might not be actively
maintained).

At one point it does​:

PL\_stack\_sp \-= call\_sv\(method\, G\_VOID | G\_EVAL\);

If the stack happens to to be grown and reallocated during the call to
call_sv(), then the new value of PL_stack_sp is overwritten with the
*old* value less whatever call_sv returns.

It probably needs to be rewritten as​:

I32 retcount;

retcount = call\_sv\(method\, G\_VOID | G\_EVAL\);
PL\_stack\_sp \-= retcount;

I can confirm that this fixes the problem for me.

I will file a bug report and patch with the maintainer of Sub​::Attribute.

This ticket can be resolved as the issue is not perl itself, but a CPAN module.

Thanks!

@p5pRT p5pRT closed this as completed Oct 8, 2015
@p5pRT
Copy link
Author

p5pRT commented Oct 8, 2015

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

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