Re: Weird mod_perl & CGI.pm interaction (Bug?)
On Fri, 8 Feb 2002 17:02:20 + (GMT), Ged Haywood wrote: >>My message is about data space. The data space for the modules does not >> seem to be recreated or reinitialized (BEGIN blocks are not rerun) from one >> invocation of a script to another. > >Yes, this is well known to mod_perl users and it's in the Guide, in >the same chapter that I've already suggested that you read: > >=head1 BEGIN blocks > >Perl executes C blocks as soon as possible, at the time of >compiling the code. The same is true under mod_perl. However, since >mod_perl normally only compiles scripts and modules once, either in >the parent server or once per-child, C blocks in that code will >only be run once. As the C manpage explains, once a C >block has run, it is immediately undefined. In the mod_perl >environment, this means that C blocks will not be run during >the response to an incoming request unless that request happens to be >the one that causes the compilation of the code. Broken behavior, defined or not, is still broken behavior. Maybe it's up to the CGI.pm author to investigate what he has to do to work around this problem, but that's still a work around for broken behavior. >If you are having trouble coping with mod_perl and CGI.pm perhaps it >would better if you tried different approach, Apache::Request for >example has some useful features. Linux Online has been using mod_perl and CGI.pm for over 4 years now, I'm not about to change because I've tripped over this bug. As my original message said, I found a solution, albeit an unreasonable one. If Apache::Request was perl only, I might look into it since we only use CGI.pm for it's query parsing abilities but with the need to drag along a C library, I'll pass. Michael
Re: Weird mod_perl & CGI.pm interaction (Bug?)
On Fri, 8 Feb 2002 02:42:31 + (GMT), Ged Haywood wrote: >Hi again >> Could you give me the specific jump tag for the section you are refering to please? > > >=head3 Reloading Configuration Files Ged, I read this over. It does not directly address the issue that I brought up in my original email. This discussed the loading and compilation of code. I recognise and acknowledge that one of the main points of mod_perl is that the code does not need to be recompiled from invocation to invocation. This, however, is not the point of my message. My message is about data space. The data space for the modules does not seem to be recreated or reinitialized (BEGIN blocks are not rerun) from one invocation of a script to another. This has some rather serious, if not downright disturbing consequences. The equating of my bug report with module loading and query retrieval implies a number of things. Specifically, based on the above referenced guide text, module CGI.pm is not reloaded by the server from invocation to invocation. A good thing, for the most part. The problem comes when a child server does not die between client services on a busy server. Unless mod_perl is specifically working around it, this implies that the global data space for CGI.pm is not cleared and therefore is available to the next caller. IE, client1 comes and executes /cgi-bin/login with a particular set of POST parameters (his name/password). If the child which serviced client1 does not exit and client2 comes along and tries to execute /cgi-bin/login within the same child, he would presumably get logged in with the name/pwd that were supplied by client1. VERY BAD. If this is not the case, mod_perl has a work-around built into it that clears out the data space of precompiled modules for each external request. If that work around is coded into mod_perl, I am saying that there is a bug in that it (if such a work around does exist) is not being executed by sub-requests made from the initial request. There is no reason that the same data space clearing should not take place for a sub-request as would be done for an outside request. If I had the familiarity with the code and the time, I would dig into the source some and see what I could find in terms of code which is related to this issue but I really don't have either right now. I would strongly suggest that someone who is familiar with the code involved in this part of mod_perl, Apache.pm and CGI.pm take a hard look at this because, IMHO, it has some serious implications. Michael
Re: Weird mod_perl & CGI.pm interaction (Bug?)
On Fri, 8 Feb 2002 01:18:19 + (GMT), Ged Haywood wrote: >On Thu, 7 Feb 2002, Mike McLagan wrote: > >> >Isn't this mentioned in the mod_perl Guide? >> > >> >http://perl.apache.org/guide >> > >> >> I dug thru the guide and I found no mention at all of anything >> similar to this. > >http://perl.apache.org/guide/porting.html Ged, I looked thru most of those and I can't see which of the large collection of items you believe describes the situation I brought up. Could you give me the specific jump tag for the section you are refering to please? Michael
Re: Weird mod_perl & CGI.pm interaction (Bug?)
On Thu, 7 Feb 2002 18:38:53 + (GMT), Ged Haywood wrote: >Hi there, > >On Thu, 7 Feb 2002, Mike McLagan wrote: > >>I have two scripts, call them A and B. >[snip] >>$q = new CGI; >[snip] >> Inveriably, I end up with "B::show()" in my output, not at all what I wanted, > >Isn't this mentioned in the mod_perl Guide? > >http://perl.apache.org/guide > I dug thru the guide and I found no mention at all of anything similar to this. If you happen to know where it is, please point it out because I was not at all successful. Guide or not, it still represents undesirable behavior. Michael
Weird mod_perl & CGI.pm interaction (Bug?)
Hello,
I have two scripts, call them A and B. Here's what I'm doing (paraphrased
heavily to save posting a huge pile of code):
In data.html, I have:
In A, I have:
$q = new CGI;
show() if $q->param('action') eq 'show';
sub show
{
Apache::Include->virtual("B?action=remove");
}
In B, I have:
$q = new CGI;
show() if $q->param('action') eq 'show';
remove() if $q->param('action') eq 'remove';
sub show
{
print "B::show()\n";
}
sub remove
{
print "B::remove()\n";
}
Inveriably, I end up with "B::show()" in my output, not at all what I wanted,
expected or hoped for.
What I see happening is that Apache::Registry is loading CGI.pm into the httpd
child the first time it encounters a script that uses it. This runs a number
of functions within CGI.pm which set up variables, etc. The call to new() in A
then reads the query (GET or POST, doesn't matter) into @QUERY_PARAM.
When B is invoked, within the same child, Apache::Registry DOES NOT reload
CGI.pm and therefore does not initialize any of the variables, etc. This
results in the new() call in B REUSING (!) the @QUERY_PARAM which was built up
during the new() call in A! OOOPS!
In order to make it work, I had to dig thru CGI.pm and found a function that's
in there with comments about mod_perl around it, specifically:
CGI::initialize_globals();
If I add this call in before both of the new() invocations, I get the desired,
expected results.
I'm not sure who to pin this on, mod_perl, Apache::Registry or CGI but it would
seem to me that this qualifies as a bug, somewhere.
Michael
Re: Segment fault in Perl_pp_leavetry
On Fri, 9 Jun 2000 10:28:14 -0700 (PDT), Doug MacEachern wrote: >try this: >(gdb) source mod_perl-x.xx/.gdbinit >(gdb) curinfo > >hopefully that will print the filename:line of the code Perl was running >here. maybe that will shed some light. (gdb) set args -X (gdb) run Starting program: /usr/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x401e2758 in net_write_command () from /usr/lib/apache/mod_auth_mysql.so (gdb) bt #0 0x401e2758 in net_write_command () from /usr/lib/apache/mod_auth_mysql.so #1 0x40341238 in ?? () from /usr/lib/apache/mod_perl.so #2 0x78756e69 in ?? () Cannot access memory at address 0x6c2e6264 (gdb) source /usr/src/redhat/BUILD/mod_perl-1.24/.gdbinit (gdb) curinfo Attempt to extract a component of a value that is not a structure pointer. (gdb) bt #0 0x401e2758 in net_write_command () from /usr/lib/apache/mod_auth_mysql.so #1 0x40341238 in ?? () from /usr/lib/apache/mod_perl.so #2 0x78756e69 in ?? () Cannot access memory at address 0x6c2e6264 (gdb) There is no "net_write_command" call within the mod_auth_mysql code or object based on the output of 'strings' and 'grep'. >do you have these same troubles if mod_perl is linked static? I don't know. Building it statically is not a process I'm familiar with. I've been trying to start from a known point -- mod_auth.c and cut back in the code for various mod_auth_mysql functions. I've got a version of mod_auth_mysql.c that if I compile in 1 more function, it dies in mod_perl.so when I access a mod_perl handled script. I've messed with structure variables, etc by including and excluding items and it comes back to the same thing, touch a mod_perl script with too much code in mod_auth_mysql (or even mod_example which I was screwing around with) and *BOOM* the server seg faults. Any help would be greatly appreciated. Michael
Segment fault in Perl_pp_leavetry
Hello, I am having the above segfault using mod_perl 1.23 and mod_perl 1.24 on a RedHat 6.2 system with Perl 5.00503. The Apache daemon was compiled with max DSO and included the mod_ssl patches, etc as shown below. mod_perl is compiled with -DEAPI per it's request. If I operate without mod_auth_mysql, the server is fine. If I operate without mod_perl, the server is fine but my perl programs don't work. The code for mod_auth_mysql hasn't changed in over a year or more so I am inclined to believe that it's not the source of the problem. [root #] gdb httpd (gdb) set args -X (gdb) run [notice] Apache/1.3.12 (Unix) AuthMySQL/2.20 mod_ssl/2.6.2 OpenSSL/0.9.5 mod_perl/1.24 configured -- resuming normal operations Program received signal SIGSEGV, Segmentation fault. 0x40286b78 in Perl_pp_leavetry () from /usr/lib/apache/mod_perl.so (gdb) bt #0 0x40286b78 in Perl_pp_leavetry () from /usr/lib/apache/mod_perl.so #1 0x40204238 in ?? () from /usr/lib/apache/mod_perl.so #2 0x78756e69 in ?? () Cannot access memory at address 0x6c2e6264 (gdb) If I can provide more information please let me know how. If there's any good suggestions out there, I'd be most appreciative. Michael
