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
Comments
From @mschoutSince upgrading to 5.20, we started seeing our modperl process crash for my $mod (@modules) { 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 *** I bisected for where this broke, and the first bad commit is: commit ebdc880 S_process_special_blocks() should use a new stack for BEGIN blocks. Inline Patchdiff --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 reversed the above commit against 5.20.3 and the problem goes away (although It does seem to matter what modules are that are loaded to trigger the bug, so Regards, |
From @mschoutOn Wed Sep 23 11:21:00 2015, mschout@gkg.net wrote:
Just to clarify: The above crash was produced with plain "perl". Outside of modperl. So modperl is not involved with this bug. |
From @mschoutAfter further investigation, this commit seems to be related to Sub::Attribute. I dropped Sub::Attribute and the problem went away. |
From @jkeenanOn Wed Sep 23 15:01:00 2015, mschout@gkg.net wrote:
Can you explain what role Sub::Attribute was playing in the code in which you encountered the problem? Thank you very much. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @mschoutOn Wed Sep 23 17:01:40 2015, jkeenan wrote:
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 Program received signal SIGSEGV, Segmentation fault. On my system this happens on the 32nd time add_trigger is called. |
From @mschoutOn Thu Sep 24 12:27:31 2015, mschout@gkg.net wrote:
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 $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.
|
From @mschoutHere's the crash from the above RunMode implementation: *** Error in `perl': corrupted double-linked list: 0x000000000192bf50 *** Note that this too is different from the original crash (free() invalid next pointer). But this backtrace looks more like the original one. strange. |
From @iabynOn Wed, Sep 23, 2015 at 11:21:00AM -0700, Michael Schout wrote:
It appears to be a bug in Sub::Attribute (note that this modules is at 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 It probably needs to be rewritten as: I32 retcount; retcount = call_sv(method, G_VOID | G_EVAL); or possibly retcount = call_sv(method, G_VOID | G_EVAL | G_DISCARD); -- |
From @bulk88On Tue Oct 06 06:32:12 2015, davem wrote:
Remind me of problem described in https://rt.cpan.org/Public/Bug/Display.html?id=92570 -- |
From @bulk88On Tue Oct 06 12:53:50 2015, bulk88 wrote:
*That RemindS me of problem described in https://rt.cpan.org/Public/Bug/Display.html?id=92570 -- |
From @mschoutOn Tue Oct 06 06:32:12 2015, davem wrote:
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! |
@iabyn - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#126145 (status was 'rejected')
Searchable as RT126145$
The text was updated successfully, but these errors were encountered: