Quoting Arnon Weinberg <[EMAIL PROTECTED]>: > > I'm getting the following in my error_log: > [asp] [12696] [error] Can't undef active subroutine at > /usr/lib/perl5/site_perl/5.8.0/Apache/ASP.pm line 1320. <--> , > /usr/lib/perl5/site_perl/5.8.0/Apache/ASP.pm line 1518 > > The following code is sufficient to replicate the problem. Basically, a > recursive script that declares a subroutine. I saw in the style guide that > in-script subroutine declaration is bad because of closures, but I'm > getting a run-time error here, and there are no variables being declared - > in fact the subroutine is not even being called. > > <% > sub foo {} >
This is interesting, but possibly unavoidable. If there is a good reason to create a fix for this, perhaps we can find one. Like the prior post said, its bad form to have subs in the script, and causes no end of problems. To work around the closure issue that was catching a lot of people, recent releases of Apache::ASP do not cache a script compilation that has a subroutine defined in it, so the script is recompiled each time. Now it seems that you are calling a routine, which calls itself and Apache::ASP tries to undefine the existing subroutine with another compilation, and of course this does not work since the subroutine is actively executing. Perhaps this is a "feature" because having the subs in the script itself could result in a closure/sticky variable again when it tries to execute itself if it were still compiled and we cached the compilation. My advice is if you really need to have subs in your script, then define it as a code ref like so: my $foo = sub {}; &$foo; this will not have closure problems since you are executing it per request, and it will therefore do the right thing, as well as allow recursive calling of the script. Better yet if the subs can be moved to the global.asa or perl module. Regards, Josh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]