mod_perl caches your Perl scripts when it runs them; this provides a nice efficiency boost, but it also has a few extra gotchas.
You have to be very careful to initialize all your variables before you use them. Additionally, you must avoid my variables that are used both inside and outside of subroutines.
Failing either one of those could lead to a variable holding a value that it got from a previous execution of the mod_perl script.
How is $r declared and set in your code?
| [reply] |
That code was not cut and paste, I am aware of how scope works inside mod_perl
$r was just an example of a Apache::Request object and
is defined correctly.
I am almost sure that this problem is not coming from my code, considering that I am using XML::Simple in the same way outside of mod_perl and it works correctly
p.s. yes everything is defined with a my()
lindex
| [reply] |
my $var = rand;
sub do_something {
print "$var\n";
}
That will lead to the 'Variable "$var" will not stay shared' error, and $var in do_something will keep the same value it had the first time do_something was called, including previous calls from earlier executions of the script in the same mod_perl fork.
Since the behavior is different under mod_perl, my first thought is to check on the differences between running normally and running under mod_perl... If that's not it, I'll work on thinking of other possible causes for this odd behavior. Although at that point you may want someone with more experience with the XML modules. :) | [reply] [d/l] |
I don't think this is necessarily a bug in Expat.pm, but it is definitely an artifact. Since the expat interface can handle so many different types of data (scalars, scalar refs, tied handles), this warning is generated when Expat.pm is trying to determine how to parse the argument given. Apparently XML::Simple passes the argument as a string, which causes that eval block to puke.
I think mod_perl is setting up a $SIG{__DIE__} handler, and it doesn't care whether or not it occured in an eval. As to a solution, what about enclosing XMLin in its own block, that contains no strict 'refs' ?
| [reply] [d/l] [select] |
Well the block in XML::Parser::Expat that puks is inside a
eval, how ever I did modify the $SIG{__DIE__} for mod_perl on my server, as well as recompiled mod_perl and apache to no-longer use expat-lite (the reason behind the module causeing the system to &die(); was accually a segfault due to conflicting links to different expat libs) its working now. But something should be done about the warning that XML::Parser::Expat throws :\
lindex
| [reply] |