All the Perl that's Practical to Extract and Report
use Perl Log In
phillup (4419)
Strange Segfault
I needed to write a quick script today to iterate over my database and update some records. Pretty standard stuff.
If I'm having a problem with a section of code, I will usually wrap it in a "sub" statement to skip it while I figure out what is going on.
But... I noticed that when I did this and the program was finished (it prints "done" when finished) it would segfault. I reduced the script to this...
#!
/usr/bin/perl
use strict;
use MyDB::GradeBook::Session;
my $session = new MyDB::GradeBook::Session('phillup','mypassword');
sub skip_this{
$session->update_status_all();
}
print "\ndone\n";
I must be having a major brain f*rt today, because I just can't see what would cause this to segfault. To make matters worse... if I remove the "sub" wrapper... the code executes as expected, does what I want... and does not segfault.
And... if I just comment out the line of code, like this:
#!
/usr/bin/perl
use strict;
use MyDB::GradeBook::Session;
my $session = new MyDB::GradeBook::Session('phillup','mypassword');
# commented out instead of wrapping in a sub
# $session->update_status_all();
print "\ndone\n";
It works fine.
Any ideas why wrapping this line in a "sub" would cause a segfault?
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Order of Destruction (Score:1)
Since the subroutine is a closure, the object won't go out of scope until the subroutine is destroyed. That tends to be quite bad news for objects with some sort of DESTROY action.
Re:Order of Destruction (Score:1)
That explains why I tracked it down to a problem in the destructor of the session object. The closure would change *when* the object is being destroyed... do I have that right?
The problem goes away when I use a different serializer for my CGI::Session object, which is contained in the session object (has a, not is a). I close the CGI::Session object in the destructor of my session object.
I have not thought of subroutines being a closure... just a different lexical scope. I'm st
Re:Order of Destruction (Score:1)
I didn't realize that *accessing* a variable from within a closure makes it hang around until the closure goes away. Actually, it makes sense... I simply had not thought too deeply about it.
It looks like it does this by increasing the ref count of the variable... which would definitely change when it gets destroyed.
*Now* I'll go play with the kid.