Segmentation fault
Just found that Apache::Util::unescape_uri when gets undefined value as parameter not returns undefined value, but make SUBJ! Why that's happens? And one more question. We have well-known-2-apaches-config and when the "power" one gets SF, the "simple" returns and logs 502 Proxy error to the _virtual host_ error_log. And mod_perl-powered server logs SF to the _server_ log. Comparing time of two errors we can get request, that leads to this error. And the question is: if we have to use one mod_perl-powered Apache - how we can find request, that breaks server? (we have more than 100 virtual hosts of our customers and that will be PITA - found the error request) Gregory Belenky WebZavod (http://www.webzavod.ru) programmer
DBI handle cleared whilst still active
Hi all,
i have just installed DBI-1.20, ApacheDBI-0.88 and DBD-Oracle-1.12 on a
tru64 Unix 5.1a. Also installed is Oracle 8.1.7 with Oracle supplied Apache
1.3.12 and Oracle supplied perl 5.005_03.
After some problems i got it work together with DBD::Oracle. The problem now
is as follows:
I run the following script (just select the dbname and hostname from a
function, commented out host user and password)
#!/usr/bin/perl
# Perl script start ##
$ENV{'ORACLE_HOME'}="/u01/app/oracle/product/8.1.7";
use DBI;
print "Content-type: text/plain\n\n";
$dbh = DBI->connect("dbi:Oracle:host=host;SID=sid", "usr", "pwd") || die
$DBI::errstr;
$stmt = $dbh->prepare("select fc_get_dbname from dual")|| die $DBI::errstr;
$rc = $stmt->execute() || die $DBI::errstr;
while (($dbname) = $stmt->fetchrow()) { print "$dbname\n"; }
warn $DBI::errstr if $DBI::err;
die "fetch error: " . $DBI::errstr if $DBI::err;
$stmt->finish() || die "can't close cursor";
$dbh->disconnect() || die "cant't log off Oracle";
# Perl script End ##
which puts the following message:
abba02.orgdv> perl test4.pl
Content-type: text/plain
DB: ENTWICKL auf Maschine: abbaentwickel.orgdv
DBI handle cleared whilst still active during global destruction.
DBI Handle has 1 uncleared child handles during global destruction.
dbih_clearcom (h 0x14012c8f0, com 0x140043880):
FLAGS 0x211: COMSET Warn AutoCommit
TYPE 1
PARENT undef
KIDS 1 (0 active)
IMP_DATA undef in 'DBD::Oracle::dr'
thread cond var 0x140130f30, tid 65535
if i run an application in Apache and call a cgi script it puts the same
message in the error_log from apache.
did i forget something or is it a bug which should be posted as described in
the manuals?
MfG
Volker Winter
plan business AG
NDR Projekt ABBA
email: [EMAIL PROTECTED]
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?)
Hi Mike, On Fri, 8 Feb 2002, Mike McLagan 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. 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. 73, Ged.
Re: Weird mod_perl & CGI.pm interaction (Bug?)
This is aparently the nature of Apache::Include. It executes the given
script within the current request while ignoring any query string that you
may provide.
So, including B from A makes all parameters supplied to A available to B,
and supplying a query string to B does nothing. Moreover, calling new CGI
from B will do just that. It will have the params supplied in the initial
request. So, if you modify $q in script A before including B, B will not be
aware of those changes made in A.
Are we all completely confused now?
Regards,
Tim Tompkins
--
Programmer
http://www.arttoday.com/
http://www.rebelartist.com/
--
- Original Message -
From: "Mike McLagan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 07, 2002 10:59 AM
Subject: 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: DBI handle cleared whilst still active
Hi there, On Fri, 8 Feb 2002 [EMAIL PROTECTED] wrote: > I run the following script (just select the dbname and hostname from a > function, commented out host user and password) [snip] > > abba02.orgdv> perl test4.pl > Content-type: text/plain > > DB: ENTWICKL auf Maschine: abbaentwickel.orgdv > DBI handle cleared whilst still active during global destruction. [snip] As mod_perl and Apache don't seem to be involved, would this question be better asked on a DBI list? 73, Ged.
Re: DBI handle cleared whilst still active
At 4:09 PM +0100 2/8/02, [EMAIL PROTECTED] wrote:
>Hi all,
>i have just installed DBI-1.20, ApacheDBI-0.88 and DBD-Oracle-1.12 on a
>tru64 Unix 5.1a. Also installed is Oracle 8.1.7 with Oracle supplied Apache
>1.3.12 and Oracle supplied perl 5.005_03.
>After some problems i got it work together with DBD::Oracle. The problem now
>is as follows:
>I run the following script (just select the dbname and hostname from a
>function, commented out host user and password)
>
>#!/usr/bin/perl
># Perl script start ##
>$ENV{'ORACLE_HOME'}="/u01/app/oracle/product/8.1.7";
>use DBI;
>print "Content-type: text/plain\n\n";
Try the following instead...
eval {
$dbh = DBI->connect(DSN,USERNAME,PASSWORD) || die $DBI::errstr;
};
if($@) {
print "DB Connect error: $@";
exit;
}
eval {
$sth = $dbh->prepare("select fc_get_dbname from dual");
$sth->execute;
($dbname) = $sth->fetchrow_array;
$sth->finish;
};
if($@) {
print "DB Select failure: $@");
$dbh->disconnect if(defined $dbh);
exit;
}
print $dbname."\n";
$dbh->disconnect if(defined $dbh);
Rob
>$dbh = DBI->connect("dbi:Oracle:host=host;SID=sid", "usr", "pwd") || die
>$DBI::errstr;
>$stmt = $dbh->prepare("select fc_get_dbname from dual")|| die $DBI::errstr;
>$rc = $stmt->execute() || die $DBI::errstr;
>while (($dbname) = $stmt->fetchrow()) { print "$dbname\n"; }
>warn $DBI::errstr if $DBI::err;
>die "fetch error: " . $DBI::errstr if $DBI::err;
>$stmt->finish() || die "can't close cursor";
>$dbh->disconnect() || die "cant't log off Oracle";
># Perl script End ##
>
>which puts the following message:
>
>abba02.orgdv> perl test4.pl
>Content-type: text/plain
>
>DB: ENTWICKL auf Maschine: abbaentwickel.orgdv
>DBI handle cleared whilst still active during global destruction.
>DBI Handle has 1 uncleared child handles during global destruction.
>dbih_clearcom (h 0x14012c8f0, com 0x140043880):
> FLAGS 0x211: COMSET Warn AutoCommit
> TYPE 1
> PARENT undef
> KIDS 1 (0 active)
> IMP_DATA undef in 'DBD::Oracle::dr'
> thread cond var 0x140130f30, tid 65535
>
>if i run an application in Apache and call a cgi script it puts the same
>message in the error_log from apache.
>did i forget something or is it a bug which should be posted as described in
>the manuals?
>
>MfG
>Volker Winter
>plan business AG
>NDR Projekt ABBA
>email: [EMAIL PROTECTED]
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
[OT] Opera Cookies
I've recently come across some interesting behavior with Opera on linux. When I set a cookie using CGI::Cookie and Set-Cookie: headers, and then perform a JavaScript redirect to another page, the cookie IS NOT SET. That doesn't mean that the Cookie: header wasn't returned from the browser, I mean the cookie doesn't even seem to be present. Opera even says that it's going to set it (after turning on "ask about cookies" pref). Taking away the JavaScript redirect fixed the missing cookie problem, but still doesn't tell me why anything JavaScript related would have an effect on an HTTP header. The javascript looks like document.location = '$url'; Has anyone had any troubles with Opera/Cookies/mod_perl? Every other browser seems to work just fine (Konqueror, Netscape, IE, Galleon). Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Segmentation fault
Hi there, On Fri, 8 Feb 2002, Gregory Belenky wrote: > Just found that Apache::Util::unescape_uri when gets undefined value as > parameter not returns undefined value, but make SUBJ! > Why that's happens? Perhaps I'm being dense, I do not understand the question. What is "SUBJ"? > if we have to use one mod_perl-powered Apache - how we can find > request, that breaks server? Would it not be better to prevent the server from breaking? 73, Ged.
Re: [WOT] Google Programming Contest.
On Thu, 7 Feb 2002, Medi Montaseri wrote: > This reaminds me of a Brain Bowl competition at USC a few years > ago, where the winner (a one man Perl speaking team) solved 4 out > of 6 problems in the given time (compared to other multiple member > teams) and the school of engineering decided to remove Perl as one > of the possible languages The myth lives on. :-) It's not quite true. It was at UCLA and the story was different: http://nntp.perl.org/group/perl.advocacy;max=961 http://nntp.perl.org/group/perl.advocacy/956 - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: choice of mod_perl technology for news site
On Thu, 2002-02-07 at 17:30, Ian Kallen wrote: > > I'm not really involved with the project but it looks to me that bricolage > is heading towards content generation abstraction (there's support for > Mason and HTML::Template). Therefore, I would imagine that if you wanted > to use AxKit as a content generator, you could. Yes, this is true. Bricolage features a pluggable Templating architecture, which means that any templating system could be added. Currently it supports HTML::Mason and HTML::Template. Those who'd like to contribute Template Toolkit and XML/XSLT/AxKit support would be welcomed! Join the Bricolage developers list and join the discussion there if you're interested. https://sourceforge.net/mail/?group_id=34789 Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
try/finally without catch
In Graham Barr's Error module, the documentation indicates that finally is called after either a successful try block or a catch handler, but says nothing about an unsuccessful try block without a catch handler. Does it handle this situation or am I forced to create dummy catch blocks whose only job is to re-throw the exception so that finally can execute? -- Milo Hyson CyberLife Labs, LLC
Re: Perl Section Bug?
Yes, It's a bug in Sections. Confirmed in 1.26.
But it is worse.
With the following in httpd.conf try /info vs /status vs /status/info vs
/info/status, with and without the commented part, (if one section
fails, if two sections works)
$Location{'/status'} = {
SetHandler => 'server-status',
Allow => 'from localhost'
};
#
#
$Location{'/info'} = {
SetHandler => 'server-info',
Allow => 'from localhost'
};
I'm digging into it.
Regards,
Salvador Ortiz.
On Fri, 2002-02-01 at 20:56, David Wheeler wrote:
> Okay, let me try again.
>
> I have a simple module I've written that demonstrates the problem. here
> it is:
>
> package MyTest;
> our $VERSION = '0.1';
> use Apache;
>
> sub one {
> print STDERR "One\n";
> print STDOUT "One\n";
> return Apache::OK;
> }
>
> sub two {
> print STDERR "Two\n";
> print STDOUT "Two\n";
> return Apache::OK;
> }
>
> package Apache::ReadConfig;
> use strict;
> use warnings;
>
> our $NameVirtualHost = '*:80';
>
> our %VirtualHost = ('*:80' => {
> ServerName => '_default_',
> DocumentRoot => '/usr/local/apache/htdocs',
> Location => {
> '/one' => {
> SetHandler => 'perl-script',
> PerlHandler=> 'MyTest::one'
> },
> '/two' => {
> SetHandler => 'perl-script',
> PerlHandler=> 'MyTest::two'
> }
> }
> });
>
>
> Now, if I execute this from httpd.conf by simply calling
>
> PerlModule MyTest
>
> Here's what I get for my requests:
>
> URL Prints
> === ==
> http://myserver/one One
> http://myserver/two Two
> http://myserver/one/foo One
> http://myserver/two/foo Two
> http://myserver/one/two One
> http://myserver/one/twofoo One
> http://myserver/one/two/foo One
> http://myserver/two/one One
> http://myserver/two/onefoo One
> http://myserver/two/one/foo One
>
> It's the last three requests that are the problem. Because I'm hitting
> the '/two' location, I expect each of those examples to print "Two". But
> because they each have "one" in the URL, they all print "One"!
>
> Why is this? It seems to be acting like LocationMatch directives rather
> than Location. Could this be a bug in how the Perl sections work? If
> not, how do I get that last request to print "Two" instead of "One"?
> Even if it *is* a bug, how do I get the proper behavior?
>
> TIA,
>
> David
>
> --
> David Wheeler AIM: dwTheory
> [EMAIL PROTECTED] ICQ: 15726394
>Yahoo!: dew7e
>Jabber: [EMAIL PROTECTED]
>
Caching LDAP connections
Hello Is there an Apache::Net::LDAP type module that would cache LDAP connections? Something that behaves in the same manner as Apache::DBI I went searching on cpan and sourceforge but didn't find what I was looking for. Thanks in advance. /--\ | Remi Godin | The greatest risk| | Metrex.net |is not taking one. | | (204) 943-0156 | \--/ Remi L Godin (E-mail).vcf Description: Binary data
Re: [OT] Unsubscribe help
On Thu, 7 Feb 2002, Per Møller wrote: > I have send a mail to [EMAIL PROTECTED] but it does not > seem to work. I'm still getting the mails from this mailinglist. If you are not even getting an autoreply back, it's probably because you have misconfigured the envelope sender. If you get a bounce back that the address [EMAIL PROTECTED] doesn't exist, then it's because your Outlook is messing up the address when you reply to the confirmation mail. > Who's the person responsible for this list? I am over at [EMAIL PROTECTED] Send mail there if you still have problems. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: Caching LDAP connections
On Fri, 8 Feb 2002, Remi Godin wrote: > Is there an Apache::Net::LDAP type module that would > cache LDAP connections? Something that behaves in the > same manner as Apache::DBI how about ResourcePool? it includes a ResourcePool::Resource::Net::LDAP class.
