Re: global variables and reparsing question (low priority ;)
I don't quite understand what you're trying to do, but what you have
here is a closure and it looks like you want a real global instead.
(man perlref if "closure" doesn't ring a bell.) Some of your language
makes it look like you may have some confusion between global and
lexicals. At any rate, "do" is nearly always a bad thing and the
business about being parsed twice only applies to Apache's config file
and Perl sections in it, not to your modules.
- Perrin
Marc Lehmann wrote:
While I understand how my problem happens, it just caught me again
(letting me debug another two hours), and so I wanted to ask why this
peculiar behaviour is really necessary.
But straight to the point. If I have a module like this:
=
package othermodule;
my $global = 5;
sub set_global {
$global = shift;
}
=
And use this from another module:
=
othermodule::set_global 7;
=
Then, to my surprise, _sometimes_ the $global will be set, and sometimes not.
The reason for this seems to be that othermodule is parsed twice: Once
during configuration parsing and once later. The first time it is parsed,
$global is created and bound to ste_global. Other modules that call the
function get a reference to it cimpiled in.
Then, when the file is parsed again, _another_ instance of $global gets
created, and another instance of set_global is compiled. Now there are two
versions of set_global, two versions of $global, and which one gets called
very much depends on random factors.
To my pity, _some_ global (non-lexical) variables also get cleared, but
not in all packages.
Now, since this is really hard to debug (the order of function declaration
within the same file and wether the funciton is exported or not, and
wether there are other callers outside the file etc...
To remedy this, many of my modules (the bad point is that even modules I have
no control over suffer from this problem) start with something like this:
=
if (!defined $PApp::Apache::compiled) { eval do { local $/; DATA };
die $@ if $@ } 1;
__DATA__
#line 6 "(PApp::Apache source)"
=
This mostly remedies the situation. The only "side effects" that I found
so far is that my httpds reuqire much _less_ memory and run _much_ more
stable (mod_perl really is very unstable for large applications). Apart
from expected semantics of global lexical variables.
So my very own problem is solvable (either by using package variables
or that ugly but working trick above). Third-party modules (e.g. from
CPAN) however, still suffer from this problem, and due to my dumbness I
fall into that trap again and again.
And so my question is: why does this behaviour exist, and why is it
necessary (the documents I saw so far only told me that this "has
something to do with apache's configuration file parsing", which doesn't
explain much, especially as it does seem unnecessary).
Re: Apache::PerlVINC
I am testing the use of Apache::PerlVINC but I think I must do something wrong because I get an error on the PerlRequire statement in the following bit of httpd.conf when starting apache: PerlINC /opt/ward/IDV/DEV/Modules PerlRequire Ward/IDV/IDVDatabase.pm PerlINC modifies @INC at request time to pick up the different version of your PerlRequire'd module. however, mod_perl needs to be able to find this module at startup time as well. you'll need to 'use lib ...' or similar so your PerlRequire'd module can be found at startup time if it's not already somewhere in @INC. Ok, I have added 'use lib qw(/opt/ward/IDV/DEV/Modules);' to my startup.pl, but now I get the following error in my error log: Syntax error on line 339 of /opt/ward/apache/conf/httpd.conf: Invalid command 'PerlINC', perhaps mis-spelled or defined by a module not included in the server configuration line 339 is the PerlINC line above. I have 'PerlModule Apache::PerlVINC' in my httpd.conf file (I have tried moving it to startup.pl, but that doesn't make any difference). Relevant part of httpd.conf attached again. Any other suggestions? Could it have something to do with my virtual host sections (I have more virtual host sections with Apache::PerlVINC stuff in)? Kees PS. I wouldn't mind helping out maintaining this module, but I am not sure I understand it 100%. (Like why is it failing in this situation.) I had a look at Makefile.PL and PerlVINC.pm, though I have to read up on DynaLoader, ExtUtils::MakeMaker and Apache::ExtUtils, I think I get the gist of it. For instance should PerlINC's 'errmsg' in Makefile.PL say 'a path' instead of 'On or Off'? But I presume that doesn't make any difference to my situation. PerlModule Apache::PerlVINC VirtualHost _default_:8443 DocumentRoot /opt/ward/DocumentRoot SetEnv IDV_ENV DEV Alias /idv/ "/opt/ward/IDV/DEV/Scripts" Location /idv Options +Indexes PerlAuthzHandler Ward::Authorise SetHandler perl-script PerlHandler Apache::Registry AuthType Basic AuthName "IDV Development" AuthAuthoritative on require idvenv DEV #line 339 PerlINC /opt/ward/IDV/DEV/Modules PerlVersionINC On PerlFixupHandler Apache::PerlVINC PerlRequire Ward/IDV/IDVDatabase.pm /Location ## ## This can also go in a VirtualHost section ## IfDefine SSL SSLEngine on SSLCertificateFile/opt/ward/apache/conf/ssl.crt/server.crt SSLCertificateKeyFile /opt/ward/apache/conf/ssl.key/server.key SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown /IfDefine /VirtualHost
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 12:56:28AM -0500, Autarch [EMAIL PROTECTED] wrote: On Tue, 23 May 2000, Marc Lehmann wrote: stable (mod_perl really is very unstable for large applications). Apart Wow, I wish you'd warned me before I did several large applications using mod_perl. Fortunately, they haven't experienced any mod_perl related Well, add XML::Parser, some large and twisted perl modules (like XML::XSLT), do a lot of things dynamically (recompiling etc..) and apache segfaults quite a lot, at random times, and even with some weird effects (adding a comment makes httpd segfault, removing it and it works again). Fortunately, once you found a source form where httpd starts up, mod_perl seems to run fine for a long time. I, too, used mod_perl for large projects _before_ and they ran stable (== Apache::Registry). But the picture changes quite a bit when I started to write my own mod_perl handler and to use the Apache::API extensively. But this is very off-topic, at leats to my real concern (double parsing). OTOH, the instability could very well be related to this as well. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 12:27:58PM +0800, Gunther Birznieks [EMAIL PROTECTED]
wrote:
replace my $global with use vars qw($global); and your problem should
disappear.
If you had read my mail you would have known that I do not search for a
workaround. While in this simple example it is possible to create a package
variable instead of the lexical, it is ugly (I mean, the variable is now
visible everywhere). In other circumstances it is very hard to usea package
variable instead, e.g.:
my $v;
sub xxx { $v }
my $v;
sub yyy { $v }
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: global variables and reparsing question (low priority ;)
On Tue, 23 May 2000, Marc Lehmann wrote: On Tue, May 23, 2000 at 12:56:28AM -0500, Autarch [EMAIL PROTECTED] wrote: On Tue, 23 May 2000, Marc Lehmann wrote: stable (mod_perl really is very unstable for large applications). Apart Wow, I wish you'd warned me before I did several large applications using mod_perl. Fortunately, they haven't experienced any mod_perl related Well, add XML::Parser, some large and twisted perl modules (like XML::XSLT), do a lot of things dynamically (recompiling etc..) and apache segfaults quite a lot, at random times, and even with some weird effects (adding a comment makes httpd segfault, removing it and it works again). Fortunately, once you found a source form where httpd starts up, mod_perl seems to run fine for a long time. Hmm... AxKit does all this, and is very stable for me, and I've only had a couple of reports of segfaults, none of which went unsolved as far as I know... Ah well, there are still stability issues, but that's C programming for you ;-) -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: global variables and reparsing question (low priority ;)
On Mon, May 22, 2000 at 11:24:10PM -0700, Perrin Harkins [EMAIL PROTECTED] wrote: business about being parsed twice only applies to Apache's config file and Perl sections in it, not to your modules. A little followup: Looking at the mod_perl source, I see that INC is tinkered with in a lot of places. Removing modules from %INC would result in exactly the kind of behaviour I described. Unfortunately I don't know under which circumstances this happens, so I am still egaer to find out why and when this happens, and how to shield my application against that. I also forgot (uh-oh) to describe my system configuration (sorry, it was 5am): Currently, I use perl5.6 + mod_perl-1.23, but I see the behaviour since at least perl5.005_03 + mod_perl-1.21. The system is linux + apache 1.3.12 (problem seen since apache-1.3.9). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 09:26:13AM +0100, Matt Sergeant [EMAIL PROTECTED] wrote: Hmm... AxKit does all this, and is very stable for me, and I've only had a couple of reports of segfaults, none of which went unsolved as far as I know... OK. To be fair, I am not 100% sure wether it's an mod_perl problem. The same application works fine in standalone (e.g. SpeedyCGI) mode. It also seems to be related to high perl parsing activity (the application parses at least 60k of perl source per second ;) So, as to not clobber this dicussion with any claims of mod_perl stability, let's consider mod_perl rock-solid, since the I can handle the stability problems (segfaults do not occur on requests, but either after them or while startup, so users aren't affected) What I cannot handle is the reparsing of my modules :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
WANTED: reviewers for mod_perl pocket reference
My Apache Pocket Reference, published by O'Reilly Associates, should be going to press in the next week or so. I originally intended that it should include a chapter on mod_perl, and the manuscript I submitted did indeed include 40-odd pages on mod_perl. However it proved impossible to fit all the material I had included into O'Reilly's pocket reference format, so we pulled the mod_perl chapter and I am expanding it into a separate pocket reference (which will also be published by O'Reilly, hopefully by about October). The existing material has been reviewed by Doug and Stas, but I would very much like a couple more reviewers for the new book, who could look at the material in the latter half of June. If you are interested please email me. I won't be able to cope with more than a few reviewers so I may well have to decline some offers. Thanks Andrew -- Andrew Ford, Director Ford Mason Ltd +44 1531 829900 (tel) [EMAIL PROTECTED] South Wing, Compton House +44 1531 829901 (fax) http://www.ford-mason.co.uk Compton Green, Redmarley +44 385 258278 (mobile) http://www.refcards.com Gloucester, GL19 3JB, UK
Re: LARGE PERL footprint
On Sat, May 20, 2000 at 08:01:36PM +0100, Malcolm Beattie wrote:
Matt Sergeant writes:
On Fri, 19 May 2000, David Larkin wrote:
I require a large array of ints in a real application, just stripped
problem down to bear bones for demo.
Is your array sparse by any chance? If not your modperl daemon is going to
get _much_ larger after you populate that array. If it's sparse, consider
using a hash - that will give you a slight speed penalty at the benefit of
not consuming quite so much ram. Other things to consider:
Re-write this critical bit of code in XS (not as hard as it sounds).
Use a database.
Use the filesystem.
Simply store them in native form in a big long string, just like C
would do. Pre-extend the string first, if you know how big you want it:
$intsize = 4; # alter if sizeof(int) != 4
$intarray = "\0" x (3 * $intsize);
Update index $i with
substr($intarray, $i * $intsize, $intsize) = pack("I", $newval);
which assumes an unsigned int, or use "i" for signed.
To retrieve index $i use
$val = unpack("I", substr($intarray, $i * $intsize, $intsize));
You can even retrive a bunch of them faster with
@ten_to_thirty = unpack("I20", substr(...));
or set a bunch with
substr(..., $intsize * 10) = pack("I20", @ten_to_thirty);
Er, wouldn't using vec() be simpler and faster?
Tim.
CGI-cookie() problem
Hi perlers, It seems that CGI-cookie() is not always returning the right thing. For example, three clients A, B and C send to the server three different session keys X, Y and Z repectively. In some circumstances, CGI-cookie() gives Y as A's cookie, Z as B's and X as C's, while they _are_ sending the correct ones. The problem seems to be solved now by replacing CGI-cookie() with CGI::Cookie-fetch. It works best if I use $r-header_in to fetch them myself, but I tried to keep my script as less mod_perl-specific as possible. Do anybody have problems with CGI and CGI::Cookie too? This is the second time I have problem with them. Kenneth
Re: global variables and reparsing question (low priority ;)
[EMAIL PROTECTED] (Marc Lehmann) wrote:
=
package othermodule;
my $global = 5;
sub set_global {
$global = shift;
}
=
And use this from another module:
=
othermodule::set_global 7;
=
Then, to my surprise, _sometimes_ the $global will be set, and sometimes not.
You know, if I didn't know any better, I'd say that you're simply setting
$global (not the best name) in one httpd child, but of course it's not getting
set in the others.
The reason for this seems to be that othermodule is parsed twice: Once
during configuration parsing and once later. The first time it is parsed,
$global is created and bound to ste_global. Other modules that call the
function get a reference to it cimpiled in.
Then, when the file is parsed again, _another_ instance of $global gets
created, and another instance of set_global is compiled. Now there are two
versions of set_global, two versions of $global, and which one gets called
very much depends on random factors.
I don't think I believe that. Nothing gets parsed twice except http
configuration files. Is this file used inside perl sections of config
files, maybe?
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: mod_perl PHP
I use Apache a very oeucumenic way, for I do mod_perl+Templates HTML pages, and another person includes PHP in it. My problem is that I'd like to have my HTML pages parsed by PHP (or mod_php). Is it possible with handlers ? to add some more to the discussion, maybe PerlHandlers can return DECLINED, and maybe through a transformation of the Content-type from HTL to PHP3 I can have a link to mod_php3 ? N.B. PHP4 can't compile with mod_dav lastest... -- Emmanuel PIERRE A P R - J o b l'Emploi Sur Internet 32, rue Pierret, 92200 Neuilly Tel: 01 41 92 91 50 - Tatoo: 06 57 60 42 17 - Fax: 01 41 92 91 54 [EMAIL PROTECTED] eFAX: +44 0870-122-6748 www.apr-job.com
Apache::Util gives segfault
When I pass an undef (or "", maybe) to Apache::Util-unescape_uri_info
it gives me segfault.
Any idea?
Kenneth
- PerlHandler -
package Apache::SegFault;
use Apache::Util qw(unescape_uri_info);
sub handler
{
my ($r) = shift;
$r-send_http_header("text/html");
print "h1I'll give you segfault ;-)/h1\n";
print unescape_uri_info(scalar $r-args);
OK;
}
1;
- Backtrace -
[root@devel root]# gdb /www/bin/httpd
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols
found)...
(gdb) run -X -f /www/conf/httpd.conf -d /tmp
Starting program: /www/bin/httpd -X -f /www/conf/httpd.conf -d /tmp
defined(@array) is deprecated at /usr/lib/perl5/site_perl/5.6.0/Apache/DBI.pm
line 135.
(Maybe you should just omit the defined()?)
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x8091b30 in XS_Apache_unescape_url_info ()
(gdb) bt
#0 0x8091b30 in XS_Apache_unescape_url_info ()
#1 0x816c355 in Perl_pp_entersub ()
#2 0x81673ed in Perl_runops_standard ()
#3 0x812f475 in perl_call_sv ()
#4 0x812f23e in perl_call_sv ()
#5 0x808ae8b in perl_call_handler ()
#6 0x808a846 in perl_run_stacked_handlers ()
#7 0x808959d in perl_handler ()
#8 0x80ec7f3 in ap_invoke_handler ()
#9 0x80ffe09 in ap_some_auth_required ()
#10 0x80ffe6c in ap_process_request ()
#11 0x80f770e in ap_child_terminate ()
#12 0x80f789c in ap_child_terminate ()
#13 0x80f79f9 in ap_child_terminate ()
#14 0x80f8026 in ap_child_terminate ()
#15 0x80f87b3 in main ()
#16 0x406501eb in __libc_start_main (main=0x80f846c main, argc=6,
argv=0xbbb4,
init=0x806e7c8 _init, fini=0x81a484c _fini, rtld_fini=0x4000a610
_dl_fini,
stack_end=0xbbac) at ../sysdeps/generic/libc-start.c:90
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: On Mon, 22 May 2000, Peter Haworth wrote: In light of the non-dependency on mod_perl, the Apache::Request::Form name is also out. I'd still rather not use the CGI::Form name, in case there are any current users whose interface would change, which is a shame, because that seems like the most appropriate name. Erk, any ideas, or proof that no-one uses the existing CGI::Form? HTML::Form? :) Well, duh! Why didn't I think of that? Unfortunately though, HTML::Form already exists, and doesn't really do the same kind of thing. How about HTML::FormGen? I'd prefer to stick with one style of interface, to keep things small and simple. Named parameters as above seem most flexible, and allow for unexpected things like omMouseOver attributes to be added easily. I'm inclined to only allow method style calls, although I suppose there's nothing wrong with allowing people to import the methods and call them like this: print textfield($form,name = 'name', ...); agree all the way. Good. Anyone disagree? -- Peter Haworth [EMAIL PROTECTED] "The day Microsoft makes something that doesn't suck is the day they start making vacuums"
Re: RFC: Apache::Request::Forms (or something similar)
On Tue, 23 May 2000, Peter Haworth wrote: brian moseley wrote: On Mon, 22 May 2000, Peter Haworth wrote: In light of the non-dependency on mod_perl, the Apache::Request::Form name is also out. I'd still rather not use the CGI::Form name, in case there are any current users whose interface would change, which is a shame, because that seems like the most appropriate name. Erk, any ideas, or proof that no-one uses the existing CGI::Form? HTML::Form? :) Well, duh! Why didn't I think of that? Unfortunately though, HTML::Form already exists, and doesn't really do the same kind of thing. How about HTML::FormGen? HTML::Forms? -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: RFC: Apache::Request::Forms (or something similar)
Peter Haworth wrote: brian moseley wrote: On Mon, 22 May 2000, Peter Haworth wrote: In light of the non-dependency on mod_perl, the Apache::Request::Form name is also out. I'd still rather not use the CGI::Form name, in case there are any current users whose interface would change, which is a shame, because that seems like the most appropriate name. Erk, any ideas, or proof that no-one uses the existing CGI::Form? HTML::Form? :) Well, duh! Why didn't I think of that? Unfortunately though, HTML::Form already exists, and doesn't really do the same kind of thing. How about HTML::FormGen? How about HTML::StickyForm(s)? I'd prefer to stick with one style of interface, to keep things small and simple. Named parameters as above seem most flexible, and allow for unexpected things like omMouseOver attributes to be added easily. I'm inclined to only allow method style calls, although I suppose there's nothing wrong with allowing people to import the methods and call them like this: print textfield($form,name = 'name', ...); agree all the way. Good. Anyone disagree? Nope. But I won't be calling it that way personally. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
global variables and reparsing (short reproducible example)
On Tue, May 23, 2000 at 07:15:46AM -0500, Ken Williams [EMAIL PROTECTED]
wrote:
my $global = 5;
sub set_global {
$global = shift;
}
othermodule::set_global 7;
=
Then, to my surprise, _sometimes_ the $global will be set, and sometimes not.
You know, if I didn't know any better, I'd say that you're simply setting
$global (not the best name) in one httpd child, but of course it's not getting
No, it's completely deterministic ("sometimes" == depending on the when
the function was compiled). The technical aspect is clear (to me at
least, but I am bad at explaining ;): the file is sourced twice, and the
function is compiled twice (and since each "my" generates another instance
of a lexical, there are two variables).
The problem is that some code that was compiled "in between" (i.e. after
the first compilation and before the second) gets "bound" to the first
version of the function (think of it as a kind of callback). This means
that some modifications are not seen by my module.
This is indeed related to config-file-parsing.
As a related note, I wondered why there isn't a mod_perl callback that is
clled _before_ forking, but after configuration parsing. This would allow
a lot of data sharing between the httpd servers. My module requires you to
call "configured PApp" at the end of the configuration section so that it
can pull in most of the code and big data structures before it forks (so
the data gets shared). AFAIK there is no way to make this automatic.
Then, when the file is parsed again, _another_ instance of $global gets
created, and another instance of set_global is compiled. Now there are two
versions of set_global, two versions of $global, and which one gets called
very much depends on random factors.
I don't think I believe that.
You won't believe how long it took until _I_ believed that!!
Nothing gets parsed twice except http configuration files. Is this file
used inside perl sections of config files, maybe?
"Used"? I definitely call it from within my perl sections, but it's not
embedded there (see the httpd.conf excerpt I posted). What happens is
that, somehow, %INC get's reset so perl thinks it hasn't loaded the module
yet, and just loads it again.
Ok, I tried a little bit and hopefully here is a small example that is
reproducible. Install this module as "X.pm" somewhere where mod_perl will
find it:
=
package X;
my $x;
$g;
my $o;
BEGIN {
$d = defined X::x;
$o = x if $d;
$x++; $g++;
}
open FILE, "/tmp/log";
print FILE "hello pid=$$ x=$x g=$g d=$d o=$o\n";
close FILE;
sub x { $x }
=
And use this httpd.conf:
=
ServerType standalone
PerlFreshRestart On
HostnameLookups off
Port 83
ServerRoot /tmp
ErrorLog error
PerlModule X
=
And then start httpd (I had to create conf/mime.types and a logs directory
to make apache run). Then look at the file /tmp/log:
cerebro:/tmp# rm /tmp/log; httpd -f /tmp/httpd.conf; sleep 1; cat /tmp/log
hello pid=32011 x=1 g=1 d= o=
hello pid=32011 x=1 g=2 d=1 o=1
The module is indeed compiled twice. Please note that, on the first time,
X::x is not yet defined (it wasn't compiled yet) but on the second time,
it is ($d==1). Also note that the global "$g" isn't changed (it survives,
as expected), while "$x" (a lexical) is allocated anew. However, a call
to the previous version of X::x returns the old value, i.e. o=1 (X::x is
still bound to the old copy since it wasn't recompiled yet, even if "$x"
is undefined at this moment).
I assumed it _had_ something to do with parsing twice, but, in fact, it
happens without using a perl section. My mod_perl is configured like this:
=
PERL_SECTIONS=1
PERL_STACKED_HANDLERS=1
PERL_DIRECTIVE_HANDLERS=1
PERL_RESTART=1
PERL_AUTHEN=1
PERL_AUTHZ=1
PERL_TYPE=1
DO_HTTPD=1
=
Am I the only one who thinks that
{
my $x = ...;
sub the_only_function_using_x {
}
}
is cleaner then using a global variable? Heck, it's even recommended by
the perl documentation!
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: RFC: Apache::Request::Forms (or something similar)
"PH" == Peter Haworth [EMAIL PROTECTED] writes: HTML::Form? :) PH Well, duh! Why didn't I think of that? Unfortunately though, PH HTML::Form already exists, and doesn't really do the same kind of PH thing. How about HTML::FormGen? How 'bout HTML::StickyForms ? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
PerlTransHandler question.
I want handler a request only if the url is like http://localhost/idTrans=XXX In other case do the default behaviour. How could I do this? I suppose that I have to use PerlTransHandler, but I don't know how. Thanks in advance. Antonio.
RE: PerlTransHandler question.
time to pick up the Eagle book... check out http://www.modperl.com/ specifically http://www.modperl.com/book/chapters/ch7.html#The_URI_Translation_Phase HTH --Geoff -Original Message-From: Antonio Pascual [mailto:[EMAIL PROTECTED]]Sent: Tuesday, May 23, 2000 9:59 AMTo: [EMAIL PROTECTED]Subject: PerlTransHandler question. I want handler a request only if the url is like http://localhost/idTrans=XXX In other case do the default behaviour. How could I do this? I suppose that I have to use PerlTransHandler, but I don't know how. Thanks in advance. Antonio.
Variable value seems to change on it own (huh!)
Hello,
I am seeing a wierd problem that sounds kind of like, but not exactly
like the sharing of lexical variables between inner and outer
subroutines as discussed on pages 161-162 of Apache Modules (the eagle
book).
I am writing a mirror proxy and re-writing links on any document of
content-type text. The module is humming along just fine, and suddenly
the value of one of the variables in the HTML::Parser callback will
change back to a value it held several invocations earlier when it was
parsing a completely different document with a compltely different URI.
Here's the
basic setup:
sub handler {
my $r = shift;
lot's of stuff cut
parse_response($proxy_uri,# original URI up thru $r-filename
$proxied_host, # host handler sent request to
$proxied_path, # proxied filename
$response-content # response content
);
some more stuff cut
return OK;
}
sub parse_response {
my($proxy_uri, $proxied_host, $proxied_path, $html_response) = @_;
some stuff cut
my $p = HTML::Parser-(api_version=3,
start_h = [\$process_tag,
"tagname,
tokenpos,
text"],
default = [sub{print @_;}, "text"]);
$p-unbroken_text;
$p-parse($html_response);
sub process_tag {
my($tagname, $pos, $text) = @_;
process the tag
}
}
Inside "sub process_tag" (a callback handler)the content of of the
variables $proxied_host and $proxied_path all the sudden like revert
back to a value held in the previous invocation of the content handler.
$proxy_uri probably suffered the same fate, but since it's value is
generally the same between invocations there's no easy way to tell.
The other peculiarity is that the problem doesn't show up immediately.
The parent subroutine (sub parse_response) will already be some number
of tags into the response when the variables revert. On the other hand,
the problem as discribed in the eagle book suggests I would see the
problem immediately. Also, these variables are not lexically scoped
inside the start tag callback handler. They are scoped in the parent
parse_response subroutine, the callback handler being lexically within
the scope of its parent.
The result is: I am really confused. If this is that same problem, do
I need to declare those variables globally in the content handler? Or
would changing to a $p-handler(start = sub { ... }, "x, y, z");
anonymous mechanism do as well. Or worse yet, is this problem something
entirely different?
Thanks,
Rob
--
_ _ _ _ __ _ _ _ _
/\_\_\_\_\/\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_//\/_/
/\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
[EMAIL PROTECTED]
Re: Segmentation fault (11) with mod_perl 1.23...
Hi Doug, Sorry for the delayed response - I just got back into town yesterday so was 'out of action' for awhile. Doug MacEachern wrote: On Fri, 12 May 2000, Mark Haviland wrote: Hey all... I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with mod_perl (1.23) as a DSO (outside the Apache tree using apxs). Now, modules that use to work are suddenly causing seg faults. The one in particular that doens't seem to jive with mod_perl is Sybase::CTlib. Has anybody else seen this problem ? what versions of things did you upgrade from? where you using dso with the older versions? I upgraded from mod_perl 1.21. Yes I was using dso with the prior version. Here's some info about the version of perl that I compiled against: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.5-15, archname=i686-linux uname='linux hsimrhpc1.harmonic.com 2.2.5-15 #1 mon apr 19 23:00:46 edt 1999 i686 unknown ' hint=previous, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-Dbool=char -DHAS_BOOL' ccflags ='-Dbool=char -DHAS_BOOL' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Built under linux Compiled at Oct 13 1999 10:39:19 %ENV: PERL5LIB="/usr/hsi/perl5/lib" @INC: /usr/hsi/perl5/lib /usr/hsi/perl5/lib/5.00503/i686-linux /usr/hsi/perl5/lib/5.00503 /usr/hsi/perl5/lib/site_perl/5.005/i686-linux /usr/hsi/perl5/lib/site_perl/5.005 . unload_xs_so: 0x8396fc0 hmm, i wonder if the dso "fix" broke things for you, what happens if you comment out this line of mod_perl.c: unload_xs_so(librefs); I uncommented the line and now the server (httpd) just cores when I attempt to start... /usr/hsi/apache-1.3.12/bin/hsi-httpd -X -f /usr/hsi/apache-1.3.12/conf/hsi-httpd.conf.2080 perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...ok perl_section: /FilesMatch perl_section: /DirectoryMatch perl_section: /Files perl_section: /Directory perl_section: /VirtualHost perl_section: /LocationMatch perl_section: /Location PerlRequire: arg=`conf/startup_cfg.pl' attempting to require `conf/startup_cfg.pl' Segmentation fault (core dumped) It seems that is cores when it reaches the line for "use Sybase::CTlib;" in my 'conf/statup_cfg.pl' file. Now, when I look at the CTlib.pm I notice the following: package Sybase::CTlib; require Exporter; use AutoLoader; require DynaLoader; use Carp; . . . Perhaps something to do with the Exporter or DynaLoader ?? -Mark
Re: CGI-cookie() problem
"Kenneth" == Kenneth Lee [EMAIL PROTECTED] writes: Kenneth Hi perlers, Kenneth It seems that CGI-cookie() is not always returning the right thing. Kenneth For example, three clients A, B and C send to the server three different Kenneth session keys X, Y and Z repectively. In some circumstances, CGI-cookie() Kenneth gives Y as A's cookie, Z as B's and X as C's, while they _are_ sending Kenneth the correct ones. The problem seems to be solved now by replacing Kenneth CGI- cookie() with CGI::Cookie-fetch. You know, I'd give a wager that this is because CGI::cookie is not always recognizing that the first parameter is "CGI" when called as CGI-cookie(). In fact, I had a problem the other day with that too. Try changing CGI-cookie() (not documented as working, I see only instance calls, not class calls in "perldoc CGI") with CGI::cookie(). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: PerlTransHandler question.
"Antonio" == Antonio Pascual [EMAIL PROTECTED] writes: Antonio I want handler a request only if the url is like http://localhost/idTrans=XXX Antonio In other case do the default behaviour. Antonio How could I do this? Antonio I suppose that I have to use PerlTransHandler, but I don't know how. Nahh. Use basic core functionality, in your top-level conf file: LocationMatch "^/idTrans=" SetHandler perl-script PerlHandler My::Handler /LocationMatch -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Fine-grained authorization w. Apache::AuthCookie
I'm using Apache::AuthCookie for general authentication/authorization for a site I'm working on. However, there's a requirement for fine-grained authorization down to the page level - a user may have access to most pages in a directory, but be disalllowed access to a single page. Note that the pages in question are in a single directory. What I don't want is to have the user tossed to a login page if they try to access a page for which they have no access, which is what AuthCookie currently does. I thought about chaining an additional authorization handler, but that won't work since if the first one in the chain approves access, then the rest won't be called. I think that AuthCookie should come first, since it verifies that the user has actually logged in. So, if the user passes muster on the first stage of authorization (general access to directory) then any other handlers in the chain won't be called. Or is there a way to override this behaviour? What's the best way to do this? I can always stuff some code into my main handler, but that's ugly. Thanks. Cheers! -klm. --- Ken Miller, Consultant Shetland Software Services Inc.
Re: Segmentation fault (11) with mod_perl 1.23...
Doug, I think I just figured out my problem. I upgraded my system, but was using a version of perl that I had compiled before my upgrade (duh!). I set up an httpd server that came with redhat 6.2 (and mod_perl 1.23) and things seems to work fine. It looks like i need to recompile perl :). -Mark Mark Haviland wrote: Hi Doug, Sorry for the delayed response - I just got back into town yesterday so was 'out of action' for awhile. Doug MacEachern wrote: On Fri, 12 May 2000, Mark Haviland wrote: Hey all... I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with mod_perl (1.23) as a DSO (outside the Apache tree using apxs). Now, modules that use to work are suddenly causing seg faults. The one in particular that doens't seem to jive with mod_perl is Sybase::CTlib. Has anybody else seen this problem ? what versions of things did you upgrade from? where you using dso with the older versions? I upgraded from mod_perl 1.21. Yes I was using dso with the prior version. Here's some info about the version of perl that I compiled against: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.5-15, archname=i686-linux uname='linux hsimrhpc1.harmonic.com 2.2.5-15 #1 mon apr 19 23:00:46 edt 1999 i686 unknown ' hint=previous, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-Dbool=char -DHAS_BOOL' ccflags ='-Dbool=char -DHAS_BOOL' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Built under linux Compiled at Oct 13 1999 10:39:19 %ENV: PERL5LIB="/usr/hsi/perl5/lib" @INC: /usr/hsi/perl5/lib /usr/hsi/perl5/lib/5.00503/i686-linux /usr/hsi/perl5/lib/5.00503 /usr/hsi/perl5/lib/site_perl/5.005/i686-linux /usr/hsi/perl5/lib/site_perl/5.005 . unload_xs_so: 0x8396fc0 hmm, i wonder if the dso "fix" broke things for you, what happens if you comment out this line of mod_perl.c: unload_xs_so(librefs); I uncommented the line and now the server (httpd) just cores when I attempt to start... /usr/hsi/apache-1.3.12/bin/hsi-httpd -X -f /usr/hsi/apache-1.3.12/conf/hsi-httpd.conf.2080 perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...ok perl_section: /FilesMatch perl_section: /DirectoryMatch perl_section: /Files perl_section: /Directory perl_section: /VirtualHost perl_section: /LocationMatch perl_section: /Location PerlRequire: arg=`conf/startup_cfg.pl' attempting to require `conf/startup_cfg.pl' Segmentation fault (core dumped) It seems that is cores when it reaches the line for "use Sybase::CTlib;" in my 'conf/statup_cfg.pl' file. Now, when I look at the CTlib.pm I notice the following: package Sybase::CTlib; require Exporter; use AutoLoader; require DynaLoader; use Carp; . . . Perhaps something to do with the Exporter or DynaLoader ?? -Mark
not porn at all !
Hey... I hope that it is the correct address to post this : Josh is it ? ;-) I am a Recruiter (a nice one... for the moment) and I have a client who need an "army" of Java prog. in NYC... a start-up... permanent or contractors... whatever... not too cheap not too expensive... Their environment is : Java Linux Apache Enhydra PostgreSQL Radware Linkproof JDBC Dreamweaver Anyone interested... it is a Tribeca Start-up... nice office... artistic... they might be 10 people... everything possible... !! Let me know Brigitte Defoort [EMAIL PROTECTED]
Re: global variables and reparsing question (low priority ;)
helu. Marc Lehmann wrote: And so my question is: why does this behaviour exist, and why is it necessary (the documents I saw so far only told me that this "has something to do with apache's configuration file parsing", which doesn't explain much, especially as it does seem unnecessary). I'm not sure this makes sense for your case, but it might help, so... From "Writing Apache Modules with Perl and C", p59 "When the server [apache] is restarted, the configuration and module initialization phases are called again. To ensure such restarts will be uneventful, Apache actually runs these two phases twice during server startup just to check that all modules can survive a restart." signed, gustavo
Re: not porn at all !
On Tue, 23 May 2000, Brigitte Defoort wrote: Hey... I hope that it is the correct address to post this : Josh is it ? ;-) It's not the correct address. You included a mod_perl mailing list, and your job has no perl content at all. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Apache::DBI
Mark Holt wrote: Newbie to the list, apologies if this is a FAQ, but I checked the archives... I built a modperl-enabled server, (Apache/1.3.9 Ben-SSL/1.37 (Unix) mod_perl/1.21) and have been running it for some time. I have the mod_perl as a shared module, and I recently enabled it to start currently this does not work with DBI modules. You have to re-build mod_perl + apache as a statically linked binary. development. I have a startup script in operation and things work fine, until I try to preload any sort of DBI module. I tried Mysql, DBI::mysql, Apache::DBI, all to no avail. The server gives no error message, it simply acts as though it is starting, but does not show up in the process list. Is there something I'm missing? Thanks in advance. Edmund -- Edmund Mergl mailto:[EMAIL PROTECTED] http://www.edmund-mergl.de fon: +49 700 EDEMERGL
Re: Fine-grained authorization w. Apache::AuthCookie
Ken Miller [EMAIL PROTECTED] wrote:
I'm using Apache::AuthCookie for general authentication/authorization for a
site I'm working on. However, there's a requirement for fine-grained
authorization down to the page level - a user may have access to most pages
in a directory, but be disalllowed access to a single page. Note that the
pages in question are in a single directory.
What I don't want is to have the user tossed to a login page if they try to
access a page for which they have no access, which is what AuthCookie
currently does.
I thought about chaining an additional authorization handler, but that
won't work since if the first one in the chain approves access, then the
rest won't be called. I think that AuthCookie should come first, since it
verifies that the user has actually logged in. So, if the user passes
muster on the first stage of authorization (general access to directory)
then any other handlers in the chain won't be called. Or is there a way to
override this behaviour?
What's the best way to do this? I can always stuff some code into my main
handler, but that's ugly.
Short answer is `yes, it can be done.' Next comes the question of how...
What we don't want is the login page being presented if a valid user is
accessing the page. What you could do is return the proper error status when
the person is unauthorized, and then in the error document check to see if the
person has authenticated or not (basically, a valid $ENV{REMOTE_USER} or
equivalent). If so, then throw up a page explaining that they do not have
proper permissions. Otherwise, present the login page.
I'm not familiar with Apache::AuthCookie enough (or haven't looked at it
recently enough) to know exactly how the above would be accomplished, or how
Apache::AuthCookie would interact with the ErrorDocument, but it would seem
the cleanest way to me.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
Re: Apache::DBI
"EM" == Edmund Mergl [EMAIL PROTECTED] writes: mod_perl as a shared module, and I recently enabled it to start EM EM currently this does not work with DBI modules. EM You have to re-build mod_perl + apache as a EM statically linked binary. I disagree. mod_perl DSO works fine with DBI and DBD::mysql.
Re: [Re: Questions about Apache::Session]
On Tue, 23 May 2000, Michael Schout wrote:
On Sun, Jun 29, 2036 at 12:21:26AM +, Edgardo Szulsztein wrote:
Hi again
It worked great. Thanks for the help!
Now, I would like to make it work with the postgresql database server. How
could I do it (I don't like the list, but I couldn't find this information in
the documentation).
One of the problems I ran into when doing this was that Apache::Session uses
Storable to freeze the session data before storing it in the database, put
PostgreSQL does not like binary data in TEXT fields. So out of the box, it
doesnt seem that you can use Apache::Session::DBI with postgresql.
However, its very simple to get around this. I just created my own
Apache::Session::UUDBI and Apache::Session::UUDBIStore modules (by copying the
source for Apache::Session::DBI and Apache::Session::DBIStore). I then
modified it so that every time it wrote the session data it called pack("u*",
$data) to uuencode the session data. And everywhere it retrieved the session
data it calls unpack("u*" $data) so that it reverses the operation. This
results in storing the session data in the db in uuencoded format (text-only)
and makes postgresql happy.
Anyway, thats how I got around it. I'm sure there are several others.
If you would be interested in my Apache::Session::UUDBI modules, send me an
email and I will send you (or anyone else who might be interested) a copy of
it.
That's precisely the right solution. The forthcoming Apache::Session 1.50
is slightly redisigned so that you can plug in the serialization scheme of
your choice, just as you can currently swap out the backing stores. The
codebase currently consists of the regular Storable, Storable wrapped with
MIME::Base64, and Storable wrapped with pack/unpack.
Are there other serialization schemes that need to be considered? I need
to test this stuff with a running Postgres, but other than that the code
is ready to be shipped.
-jwb
Re: [newbie] Passing Session Object Twixt Handlers
On Mon, 22 May 2000, Perrin Harkins wrote: On Mon, 22 May 2000 [EMAIL PROTECTED] wrote: It seems the Apache::Session::DBI isn't actually changing anything in the database, since next time I tie the session the only thing it has is the _session_id I tied it with in the first place. Keep in mind that Apache::Session only writes to the database when the object is destroyed. Make sure it is really going out of scope. Almost. Apache::Session will commit to the backing store when the object goes out of scope, or when the programmer calls the save() method. tied(%session)-save; Cheers, Jeffrey
Re: unsubscribe instructions
Yeah!!! ME TOO. How the heck do I unsubscribe. The e-mail is increasing exponentially. From: "Fabio Arciniegas A." [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: unsubscribe instructions Date: Tue, 23 May 2000 09:46:53 -0400 Hello, I'm sorry to send administrative questions to the list, but could you please include at the end of the messages the addresses for tasks such as unsubscribing? (or at least send me a private email with them? :) ) Thank you, Fabio Fabio Arciniegas A. [EMAIL PROTECTED] Viaduct Technologies, Inc.Software Engineer http://www.thefaactory.com(301) 6563002x125 "The world is all that is the case" - Wittgenstein ~-Original Message- ~From: [EMAIL PROTECTED] ~[mailto:[EMAIL PROTECTED]]On Behalf Of ~Autarch ~Sent: Tuesday, May 23, 2000 1:56 AM ~To: Marc Lehmann ~Cc: [EMAIL PROTECTED] ~Subject: Re: global variables and reparsing question (low priority ;) ~ ~ ~On Tue, 23 May 2000, Marc Lehmann wrote: ~ ~ stable (mod_perl really is very unstable for large applications). Apart ~ ~Wow, I wish you'd warned me before I did several large applications using ~mod_perl. Fortunately, they haven't experienced any mod_perl related ~problems. Just a fluke, I guess. ~ ~Anyway... ~ ~-dave ~ ~/*== ~www.urth.org ~We await the New Sun ~==*/ ~ ~ FabioArciniegasA..vcf Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
RE: unsubscribe instructions
egads... http://perl.apache.org/#maillists -Original Message- From: Jon Wasserman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 23, 2000 1:12 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: unsubscribe instructions Yeah!!! ME TOO. How the heck do I unsubscribe. The e-mail is increasing exponentially. From: "Fabio Arciniegas A." [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: unsubscribe instructions Date: Tue, 23 May 2000 09:46:53 -0400 Hello, I'm sorry to send administrative questions to the list, but could you please include at the end of the messages the addresses for tasks such as unsubscribing? (or at least send me a private email with them? :) ) Thank you, Fabio Fabio Arciniegas A. [EMAIL PROTECTED] Viaduct Technologies, Inc.Software Engineer http://www.thefaactory.com(301) 6563002x125 "The world is all that is the case" - Wittgenstein ~-Original Message- ~From: [EMAIL PROTECTED] ~[mailto:[EMAIL PROTECTED]]On Behalf Of ~Autarch ~Sent: Tuesday, May 23, 2000 1:56 AM ~To: Marc Lehmann ~Cc: [EMAIL PROTECTED] ~Subject: Re: global variables and reparsing question (low priority ;) ~ ~ ~On Tue, 23 May 2000, Marc Lehmann wrote: ~ ~ stable (mod_perl really is very unstable for large applications). Apart ~ ~Wow, I wish you'd warned me before I did several large applications using ~mod_perl. Fortunately, they haven't experienced any mod_perl related ~problems. Just a fluke, I guess. ~ ~Anyway... ~ ~-dave ~ ~/*== ~www.urth.org ~We await the New Sun ~==*/ ~ ~ FabioArciniegasA..vcf __ __ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: strange httpd mod_perl segfault details
On Mon, 22 May 2000, Roger Foskett (2) wrote: MOD_PERL VERSION mod_perl-1.23 - MOD_PERL CONFIGURATION perl ./Makefile.PL \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ EVERYTHING=1 thanks for the complete bug report, if only you had tried the latest version (1.24), Makefile.PL explains the problem/solution(s): Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild Apache with CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) pick the least painful of those three and your problem will be gone.
Re: mod_perl 1.24, nmake test causes Apache Win32 to crash.
On Sat, 20 May 2000, Thomas wrote:
hi,
I've run into some oddities..
running nmake test causes to seriously crash
at "internal/table" while the same test with 1.22 passes fine.
Test "internal/api" FAILS for both 1.22 / 1.24
Both are compiled with identical setups using VC6 / WinNT
with the 1.3.12 / 5.00503 libs .
suggestions, anyone ??
randy found the problem, the patch below is in cvs now..
--- src/modules/perl/Table.xs 2000/05/12 22:45:32 1.9
+++ src/modules/perl/Table.xs 2000/05/23 15:56:12 1.10
@@ -58,7 +58,11 @@
}
-static void table_delete(table *tab, const char *key, const char *val)
+static void
+#ifdef WIN32
+_stdcall
+#endif
+table_delete(table *tab, const char *key, const char *val)
{
table_unset(tab, val);
}
Re: Cookies
On Mon, 22 May 2000, Jim Serio wrote: I'm still having trouble writing cookies while using Apache::Sandwich (thanks Vivek for the explination). Searching through the list archives, I found an example from David Pisoni to add the cookie to an image using the PerlFixupHandler. It doesn't seem to be workign for me though.. I also tried using CGI (in the handler) to write out the cooke with the same results. Here's the snippet from httpd.conf: Location /images/header_top_left.gif PerlFixupHandler Cookieme /Location And here's teh entire Cookieme module: i dropped your code in mod_perl-1.xx/t/docs/startup.pl and config in t/conf/httpd.conf (in the /perl/perl-status Location), it works just fine. your cookie format looks wrong though, maybe netscape can't parse it? % telnet localhost 8529 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. GET /perl/perl-status http/1.0 HTTP/1.1 200 OK Date: Tue, 23 May 2000 18:07:06 GMT Server: Apache/1.3.13-dev (Unix) mod_perl/1.24_01-dev Perl/v5.6.0 Set-Cookie: cobrand=cobrand= ;domain=.hotwired.com;path=/ Connection: close Content-Type: text/html ...
Re: Apache::DBI
On Mon, 22 May 2000, Mark Holt wrote: Newbie to the list, apologies if this is a FAQ, but I checked the archives... I built a modperl-enabled server, (Apache/1.3.9 Ben-SSL/1.37 (Unix) mod_perl/1.21) and have been running it for some time. I have the sounds like you need upgrade your mod_perl, dso fixes happened post-1.21
Re: Apache::PerlVINC
On Tue, 23 May 2000, Kees Vonk 7249 24549 wrote:
Ok, I have added 'use lib qw(/opt/ward/IDV/DEV/Modules);' to my startup.pl,
but now I get the following error in my error log:
Syntax error on line 339 of /opt/ward/apache/conf/httpd.conf:
Invalid command 'PerlINC', perhaps mis-spelled or defined by a module not
included in the server configuration
try this in httpd.conf:
Perl
delete $INC{'Apache/PerlVINC.pm'};
require Apache::PerlVINC;
/Perl
mod_perl is supposed to do that for you, so the module is reloaded again
when apache re-reads it's configuration on startup.
mod_perl 1.24 testing keeps failing
I'm having a problem with the make test in mod_perl 1.24. It doesn't seem to be configured correctly. Here are the steps I've taken so far. mod_perl 1.24 - 1. perl Makefile.PL APACHE_SRC=/usr/local/src/apache/1.3.12/apache_1.3.12/src DO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 mod_ssl 2.6.4-1.3.12 2. ./configure --with-apache=/usr/local/src/apache/1.3.12/apache_1.3.12 Apache 1.3.12 - 3. SSL_BASE=/usr/local/src/openSSL/0.9.5a/openssl-0.9.5a \ RSA_BASE=/usr/local/src/rsaref/2.0/rsaref20/sun \ ./configure \ --enable-module=most \ --enable-shared=max \ --prefix=/usr/local/apache \ --enable-module=ssl \ --activate-module=src/modules/perl/libperl.a \ --enable-shared=perl 4. make 5. make certificate TYPE=test 6. su 7. make install mod_perl 1.24 - 8. make 9. make test It seems that the t/conf/httpd.conf file is not created properly. I tried hand editing the file and removing the =pod and related lines from this file, however, when I run the test I get the following... bash(mark:opus)1503% make test cp t/conf/mod_perl_srm.conf t/conf/srm.conf /usr/local/src/apache/1.3.12/apache_1.3.12/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...Syntax error on line 5 of /usr/local/src/perl-modules/mod_perl/1.24/mod_perl-1.24/t/conf/httpd.conf: Invalid command 'PerlTaintCheck', perhaps mis-spelled or defined by a module not included in the server configuration done /usr/local/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. *** Error code 9 make: Fatal error: Command failed for target `run_tests' There is nothing in the t/logs/error_log. Any ideas to what is wrong here? does the make test under mod_perl even work?? Should I skip this step all together? ANy help would be greatly appreciated. Thanks Mark MurphyWayne State University Systems Analyst II Computing Information Technology (CIT) (313) 577-4795 Voice Academic Computing Customer Services (ACCS) (313) 577-8787 Fax 5425 Woodward Ave. Detroit, MI. 48202 Email: [EMAIL PROTECTED] WWW : http://www.wayne.edu/
[Fwd: Apache::DBI, bug?]
Hi,
I installed Apache::DBI a while ago and it worked
fine then on Apache 1.3.12 using mod_perl 1.21.
Now I'm reinstalling apache still 1.3.12 with php4,
mod_perl 1.24, apache::dbi (most recent version) and the child processes of the
apache segfault on start. This happens as soon as I try to use PerlRequire in
httpd.conf.
The startup.pl file comes from
wwwthread.
The line theserver segfaults in:
Apache::DBI-connect_on_init("DBI:$w3tvars::config{'dbdriver'}:$w3tvars::config{'dbname'}:$w3tvars::config{'dbserver'}",
"$w3tvars::config{'dbuser'}", "$w3tvars::config{'dbpass'}");
I've put the debug level to 2 and this is what I
get into the error_log:
[Tue May 23 17:36:40 2000] [notice] Apache/1.3.12
(Unix) mod_perl/1.24 PHP/4.0.0 configured -- resuming normal operations[Tue
May 23 17:36:40 2000] [info] Server built: May 23 2000 09:59:4120965
Apache::DBI
PerlChildInitHandler20966
Apache::DBI
PerlChildInitHandler20965
Apache::DBI
need ping: yes20966
Apache::DBI
need ping: yes20967
Apache::DBI
PerlChildInitHandler20969
Apache::DBI
PerlChildInitHandler20967
Apache::DBI
need ping: yes20969
Apache::DBI
need ping: yes20968
Apache::DBI
PerlChildInitHandler20968
Apache::DBI
need ping: yes[Tue May 23 17:36:41 2000] [notice] child pid 20969 exit
signal Segmentation fault (11)[Tue May 23 17:36:41 2000] [notice] child pid
20968 exit signal Segmentation fault (11)[Tue May 23 17:36:41 2000] [notice]
child pid 20967 exit signal Segmentation fault (11)[Tue May 23 17:36:41
2000] [notice] child pid 20966 exit signal Segmentation fault (11)[Tue May
23 17:36:41 2000] [notice] child pid 20965 exit signal Segmentation fault
(11)
It would be very nice if you could help me with
this one.
regards,
Gudmundur.
Re: Apache::Util gives segfault
On Tue, 23 May 2000, Kenneth Lee wrote:
When I pass an undef (or "", maybe) to Apache::Util-unescape_uri_info
it gives me segfault.
Any idea?
i'm surprised this hasn't bitten anybody before. thanks for the
report, patch below.
--- src/modules/perl/Apache.xs 2000/04/21 06:03:52 1.96
+++ src/modules/perl/Apache.xs 2000/05/23 18:06:21
@@ -668,6 +672,10 @@
CODE:
register char * trans = url ;
char digit ;
+
+if (!url || !*url) {
+XSRETURN_UNDEF;
+}
RETVAL = url;
Re: mod_perl 1.24 testing keeps failing
On Tue, 23 May 2000, Mark Murphy wrote: I'm having a problem with the make test in mod_perl 1.24. It doesn't seem to be configured correctly. Here are the steps I've taken so far. Invalid command 'PerlTaintCheck', perhaps mis-spelled or defined by a module not this indicates that mod_perl is not configured with your server. try building using the steps in INSTALL.simple.mod_ssl
Re: Variable value seems to change on it own (huh!)
sub parse_response {
sub process_tag {
}
}
why do you nest this subroutine? the guide and other docs explain the
"variable will not stay shared" problem that normally bites people under
Apache::Registry. just move the process_tag subroutine declaration
outside of parse_response:
sub parse_response {
...
}
sub process_tag {
}
Re: global variables and reparsing (short reproducible example)
On Tue, 23 May 2000, Marc Lehmann wrote: As a related note, I wondered why there isn't a mod_perl callback that is clled _before_ forking, but after configuration parsing. This would allow a lot of data sharing between the httpd servers. My module requires you to call "configured PApp" at the end of the configuration section so that it can pull in most of the code and big data structures before it forks (so the data gets shared). AFAIK there is no way to make this automatic. what's wrong with having 'PerlModule foo' at the bottom of your config file? apache 1.3 has no 'post-config' hook, 2.0 does though. Then, when the file is parsed again, _another_ instance of $global gets PerlFreshRestart On PerlModule X The module is indeed compiled twice. yes, because apache does module-init/config-read twice at startup, since you have 'PerlFreshRestart On', your module is re-compiled on this second pass.
Re: Segmentation fault (11) with mod_perl 1.23...
Doug, Sorry for the consistent eMails, but I guess I wasn't entirely correct in my statment about my version of perl being the problem. After some more tests, I've found that things go wrong (ie. I get a Segfault) when I attempt to pre load the Sybase::CTlib module (or any module that uses it) in the PerlRequire file. But, when I have the 'use Sybase::CTlib' inside of my handler, then everything is ok. Any ideas ? -Mark Mark Haviland wrote: Doug, I think I just figured out my problem. I upgraded my system, but was using a version of perl that I had compiled before my upgrade (duh!). I set up an httpd server that came with redhat 6.2 (and mod_perl 1.23) and things seems to work fine. It looks like i need to recompile perl :). -Mark Mark Haviland wrote: Hi Doug, Sorry for the delayed response - I just got back into town yesterday so was 'out of action' for awhile. Doug MacEachern wrote: On Fri, 12 May 2000, Mark Haviland wrote: Hey all... I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with mod_perl (1.23) as a DSO (outside the Apache tree using apxs). Now, modules that use to work are suddenly causing seg faults. The one in particular that doens't seem to jive with mod_perl is Sybase::CTlib. Has anybody else seen this problem ? what versions of things did you upgrade from? where you using dso with the older versions? I upgraded from mod_perl 1.21. Yes I was using dso with the prior version. Here's some info about the version of perl that I compiled against: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.5-15, archname=i686-linux uname='linux hsimrhpc1.harmonic.com 2.2.5-15 #1 mon apr 19 23:00:46 edt 1999 i686 unknown ' hint=previous, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-Dbool=char -DHAS_BOOL' ccflags ='-Dbool=char -DHAS_BOOL' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Built under linux Compiled at Oct 13 1999 10:39:19 %ENV: PERL5LIB="/usr/hsi/perl5/lib" @INC: /usr/hsi/perl5/lib /usr/hsi/perl5/lib/5.00503/i686-linux /usr/hsi/perl5/lib/5.00503 /usr/hsi/perl5/lib/site_perl/5.005/i686-linux /usr/hsi/perl5/lib/site_perl/5.005 . unload_xs_so: 0x8396fc0 hmm, i wonder if the dso "fix" broke things for you, what happens if you comment out this line of mod_perl.c: unload_xs_so(librefs); I uncommented the line and now the server (httpd) just cores when I attempt to start... /usr/hsi/apache-1.3.12/bin/hsi-httpd -X -f /usr/hsi/apache-1.3.12/conf/hsi-httpd.conf.2080 perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...ok perl_section: /FilesMatch perl_section: /DirectoryMatch perl_section: /Files perl_section: /Directory perl_section: /VirtualHost perl_section: /LocationMatch perl_section: /Location PerlRequire: arg=`conf/startup_cfg.pl' attempting to require `conf/startup_cfg.pl' Segmentation fault (core dumped) It seems that is cores when it reaches the line for "use Sybase::CTlib;" in my 'conf/statup_cfg.pl' file. Now, when I look at the CTlib.pm I notice the following: package Sybase::CTlib; require Exporter; use AutoLoader; require DynaLoader; use Carp; . . . Perhaps something to do with the Exporter or DynaLoader ?? -Mark
Re: Apache::Resource on Linux
On Mon, 22 May 2000, Ian Kallen wrote:
BSD::Resource passed all of the make test tests but when I tried enabling
Apache::Resource on a rh6.1 installation the error log barfed with these:
Ouch! malloc failed in malloc_block()
on problem is that the values were not coverted to MB, patch below fixes
that. this error is correct when the limit has been reached and clearly
isn't graceful, you might want to use Apache::SizeLimit instead.
--- lib/Apache/Resource.pm 2000/03/23 04:48:56 1.9
+++ lib/Apache/Resource.pm 2000/05/23 18:41:44
@@ -26,7 +26,7 @@
sub DEFAULT_RLIMIT_FSIZE () { 10 } #file size (MB)
sub DEFAULT_RLIMIT_STACK () { 20 } #stack size (MB)
-my %is_mb = map {$_,1} qw{DATA RSS STACK FSIZE CORE MEMLOCK};
+my %is_mb = map {$_,1} qw{DATA RSS STACK FSIZE CORE MEMLOCK AS};
sub debug { print STDERR @_ if $Debug }
Re: Segmentation fault (11) with mod_perl 1.23...
On Tue, 23 May 2000, Mark Haviland wrote: Doug, Sorry for the consistent eMails, but I guess I wasn't entirely correct in my statment about my version of perl being the problem. After some more tests, I've found that things go wrong (ie. I get a Segfault) when I attempt to pre load the Sybase::CTlib module (or any module that uses it) in the PerlRequire file. But, when I have the 'use Sybase::CTlib' inside of my handler, then everything is ok. the next step would be to get a stacktrace (mod_perl built with PERL_DEBUG=1 prefered), see the SUPPORT doc for hints.
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 10:08:46AM -0700, Gustavo Duarte [EMAIL PROTECTED] wrote: I'm not sure this makes sense for your case, but it might help, so... It probably makes a lot of sense. Thanks! "When the server [apache] is restarted, the configuration and module initialization phases are called again. To ensure such restarts will be uneventful, Apache actually runs these two phases twice during server startup just to check that all modules can survive a restart." If this were true, it would be very bad. If there is no technical need to do this "half-reloading" then it should definitely be turned off. It breaks perfectly valid perl code, creating some kind of "mod_perl-language-subset". At least _I_ lost days of debugging to find out about these subtle differences to standard perl. (And this also means that some CPAN modules would need to be patched to run with mod_perl). Or in other words: mod_perl should either do it cleanly or not at all. Or have a very good reason to break code ;) Does the book say what "module initialization phase" means, and how one can work around that? (Apart from patching _every_ module with a hack like the one I posted)? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: mod_perl and IPC
On Mon, 22 May 2000, DeWitt Clinton wrote: The problem had to do with large numbers of objects in the cache. ... Right now, things are in a holding pattern because I'm finding a limit on the number of objects I can put in the cache (less than 100, so it is an issue). Hopefully Sam will offer some insight here. I ran into this with IPC::SharedCache a couple of months ago and had some discussion with Sam about it. The problem is a lack of shared memory segments and/or semaphores compiled into the kernel. IIRC, the default for both under Linux is 128. The BSD system I was trying to use only had 32 segments and something like 10 semaphore identifiers. In order to scale a system, you'll need to recompile the kernel with higher limits. - Matt
Problem compiling mod_perl 1.24 on Solaris 2.6
On 4/26/2000, Steve Hay wrote about "Problem compiling mod_perl 1.23 on Solaris 2.4" I am experiencing what appears to be a very similar problem, but with more recent modules and OS. I am running mod_perl 1.24, Perl 5.6.0, Apache 1.3.12, Solaris 2.6 Perl Makefile.PL with options runs successfully. When I run make, I get output nearly identical to that reported by Steve Hay. Here are the last few lines output from my make: "/usr/local/lib/perl5/5.6.0/sun4-solaris/CORE/perl.h", line 1929: warning: operand treated as unsigned: 0x87654321 "./mod_perl.h", line 584: warning: macro replacement within a string literal "./mod_perl.h", line 587: warning: macro replacement within a string literal "./mod_perl.h", line 590: warning: macro replacement within a string literal "./mod_perl.h", line 593: warning: macro replacement within a string literal "mod_perl.c", line 347: fatal: macro recursion cc: acomp failed for mod_perl.c make[5]: *** [mod_perl.o] Error 2 make[4]: *** [all] Error 1 make[3]: *** [subdirs] Error 1 make[3]: Leaving directory `/export/home/fmiller/apache_1.3.12/src' make[2]: *** [build-std] Error 2 make[2]: Leaving directory `/export/home/fmiller/apache_1.3.12' make[1]: *** [build] Error 2 make[1]: Leaving directory `/export/home/fmiller/apache_1.3.12' make: *** [apaci_httpd] Error 2 I have previously successfully installed Apache 1.3.12 on this system without mod_perl. Steve Hay reported that he solved his problem by re=compiling "everything with the -Xa compiler flag". I confess to being a bit naive when it comes to compiling and installing. Are there some simple steps I should follow to proceed? Thanks for all the support. Fred Miller -- [EMAIL PROTECTED] http://titan.iwu.edu/~fmiller/
Re: global variables and reparsing (short reproducible example)
On Tue, May 23, 2000 at 11:53:04AM -0700, Doug MacEachern [EMAIL PROTECTED] wrote: a lot of data sharing between the httpd servers. My module requires you to call "configured PApp" at the end of the configuration section so that it can pull in most of the code and big data structures before it forks (so the data gets shared). AFAIK there is no way to make this automatic. what's wrong with having 'PerlModule foo' at the bottom of your config Nothing. It's just that users of my module constantly forget that ;) file? apache 1.3 has no 'post-config' hook, 2.0 does though. Another non-issue, then ;) PerlFreshRestart On PerlModule X yes, because apache does module-init/config-read twice at startup, since you have 'PerlFreshRestart On', your module is re-compiled on this second BINGO, exactly. Thanks a lot for clarifying!! Here is a proposed extension for perldoc mod_perl / RESTARTING: PerlFreshRestart On Please note that setting this option results in parsing your modules twice at server startup, and reparsing at every restart. Old code and variables are not cleared and might interfere with your module. Avoiding lexical variables at global scope and not referencing subs before declaration/definition is therefore recommended. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: unsubscribe instructions
like most mailing lists. the information is in the extended headers: From [EMAIL PROTECTED] Tue May 23 12:36:34 2000 Return-Path: [EMAIL PROTECTED] Received: from mail.genwax.com (images.genwax.com [209.101.170.83]) by genwax.com (8.8.7/8.8.7) with ESMTP id MAA01307 for [EMAIL PROTECTED]; Tue, 23 May 2000 12:36:26 -0700 Received: from locus.apache.org (locus.apache.org [63.211.145.10]) by mail.genwax.com (8.8.7/8.8.7) with SMTP id MAA32308 for [EMAIL PROTECTED]; Tue, 23 May 2000 12:41:00 -0700 Received: (qmail 33517 invoked by uid 500); 23 May 2000 19:35:42 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 33496 invoked from network); 23 May 2000 19:35:35 - Sender: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Date: Tue, 23 May 2000 14:33:32 -0500 From: Fred Miller [EMAIL PROTECTED] X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: [EMAIL PROTECTED] Subject: Problem compiling mod_perl 1.24 on Solaris 2.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Status: O X-Status: X-Keywords: X-UID: 5060 -- ___cliff [EMAIL PROTECTED] Jon Wasserman wrote: Yeah!!! ME TOO. How the heck do I unsubscribe. The e-mail is increasing exponentially. From: "Fabio Arciniegas A." [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: unsubscribe instructions Date: Tue, 23 May 2000 09:46:53 -0400 Hello, I'm sorry to send administrative questions to the list, but could you please include at the end of the messages the addresses for tasks such as unsubscribing? (or at least send me a private email with them? :) ) Thank you, Fabio Fabio Arciniegas A. [EMAIL PROTECTED] Viaduct Technologies, Inc.Software Engineer http://www.thefaactory.com(301) 6563002x125 "The world is all that is the case" - Wittgenstein ~-Original Message- ~From: [EMAIL PROTECTED] ~[mailto:[EMAIL PROTECTED]]On Behalf Of ~Autarch ~Sent: Tuesday, May 23, 2000 1:56 AM ~To: Marc Lehmann ~Cc: [EMAIL PROTECTED] ~Subject: Re: global variables and reparsing question (low priority ;) ~ ~ ~On Tue, 23 May 2000, Marc Lehmann wrote: ~ ~ stable (mod_perl really is very unstable for large applications). Apart ~ ~Wow, I wish you'd warned me before I did several large applications using ~mod_perl. Fortunately, they haven't experienced any mod_perl related ~problems. Just a fluke, I guess. ~ ~Anyway... ~ ~-dave ~ ~/*== ~www.urth.org ~We await the New Sun ~==*/ ~ ~ FabioArciniegasA..vcf Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
[Embperl] - non-alpha characters disappearing in %fdat
Can anyone tell me why the '*' is not coming through in the fdat stuff? Even better, does anyone know how to allow it? I assume this is some kind of HTML-escaping for our safety. I amusing 1.3b2 with the following options: $optRawInput = 0; $optDisableTableScan = 2048; $escmode = 0; Thanks, Tom
Re: Problem compiling mod_perl 1.24 on Solaris 2.6
On Tue, 23 May 2000, Fred Miller wrote: On 4/26/2000, Steve Hay wrote about "Problem compiling mod_perl 1.23 on Solaris 2.4" I am experiencing what appears to be a very similar problem, but with more recent modules and OS. I am running mod_perl 1.24, Perl 5.6.0, Apache 1.3.12, Solaris 2.6 perl -V would help. is your cc gcc or sun's? looking at the line number, i would try replacing any occurance of: perl_eval_sv - eval_sv perl_call_sv - call_sv perl_call_pv - call_pv why your compiler is tripping on those macros, i have no idea.
Re: overriding warn()
On Tue, 23 May 2000, Amy wrote: Is there an easy way to override warn() the way Apache overrides die() - I'm trying to disable warn() calls in production without changing any code. I think I should probably be using Apache::Log, but is there an easier way to accomplish this without changing code? you can: use Apache qw(warn); which overrides the builtin with Apache::warn. to enable those warnings, in httpd.conf: LogLevel warn (or debug) to disable: LogLevel error
Re: mod_perl 1.24 / DBD:: Sybase - Can't find loadable object
On Tue, 23 May 2000, Graf, Chris wrote: This is driving me crazy. I upgraded Perl to 5.6 (from 5.005) and mod_perl to 1.24 (from 1.22) trying to correct weird DBD::Sybase errors somehow related to decaying connections. are you sure it was properly installed? do you get errors with this? % perl -MDBD::Sybase -e0
Re: global variables and reparsing question (low priority ;)
On Tue, 23 May 2000, Marc Lehmann wrote: At leats in the example I sent in there is no sign of any closure. There is a closure, and this might be the thing that's making trouble for you, or at least part of it. This is a closure: that example is only a closure if it's compiled by Apache::Registry, which, is not in this case.
Re: mod_perl 1.24 testing keeps failing
On Tue, 23 May 2000, Mark Murphy wrote:
Here is some more information I gathered from trying the "make test" under
mod_perl. I ran the command by hand and discovered that I'm getting a core dump.
(gdb) backtrace
#0 0xff1c5568 in _smalloc () from /usr/lib/libc.so.1
#1 0xff1c55ac in malloc () from /usr/lib/libc.so.1
#2 0xff0e2940 in Perl_savepvn ()
ah, looks like typical solaris dso problem, which mod_perl's Makefile.PL
should have warned you about and suggested solutions to pick from:
if ($] 5.006) {
phat_warn(EOF, $abort);
Your current configuration will most likely trigger core dumps,
suggestions:
*) Do not configure mod_perl as a DSO
*) Upgrade your Perl version to 5.6.0 or higher (w/ -Ubincompat5005)
*) Configure Perl with -Uusemymalloc (not recommended for performance)
EOF
}
elsif ($bincompat) {
phat_warn(EOF, $abort);
Your current configuration will most likely trigger core dumps,
suggestions:
*) Do not configure mod_perl as a DSO
*) Rebuild Perl without malloc pollution (Configure -Ubincompat5005)
EOF
}
Re: global variables and reparsing (short reproducible example)
On Tue, 23 May 2000, Perrin Harkins wrote: Your sub x is a closure. That's why it returns the previous value of $x. When it gets re-defined, it should start looking at the value of the new $x. nevermind what i said in the other reply about not being a closure. you're right, it is by definition, i just assumed you were refering to the Apache::Registry trap.
RE: [Embperl] - non-alpha characters disappearing in %fdat
Can anyone tell me why the '*' is not coming through in the fdat stuff? Embperl doesn't do anything with * in %fdat. So there must be another problem. Can you give a small example what you are doing? Gerald P.S. The Embperl mailing list would be a better place to discuss this - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Cookies
Like I said, the cookie is being set, but I can't read the cookie.
Apache::Cookie-fetch('cookie_name'); doesn't work.
this is a fixup handler? you shouldn't be sending the complete http
header there. you should use $r-headers_out like you did in your
original example. and, use telnet to see what your module is actually
sending, or a log handler that dumps $r-as_string, or Apache::DumpHeaders
(on cpan).
This brings up a not-so-mod_perl question. Is there a way to telnet
to name-based virtual hosts? Can I spoof the GET request?
Jim
Re: Cookies
On Tue, 23 May 2000, Jim Serio wrote:
Like I said, the cookie is being set, but I can't read the cookie.
Apache::Cookie-fetch('cookie_name'); doesn't work.
this is a fixup handler? you shouldn't be sending the complete http
header there. you should use $r-headers_out like you did in your
original example. and, use telnet to see what your module is actually
sending, or a log handler that dumps $r-as_string, or Apache::DumpHeaders
(on cpan).
This brings up a not-so-mod_perl question. Is there a way to telnet
to name-based virtual hosts? Can I spoof the GET request?
telnet www.thesite.com 80
Trying xxx.xxx.xxx.xxx...
Connected to www.thesite.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.virtualhost.com
HTTP/1.1 200 OK
Server: blah blah blah blah
...
Cheers,
Jeffrey
cvs commit: modperl/src/modules/perl Table.xs
dougm 00/05/23 08:56:13
Modified:.Changes
src/modules/perl Table.xs
Log:
fix 1.24's Apache::Table-unset changes for win32
Revision ChangesPath
1.489 +3 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.488
retrieving revision 1.489
diff -u -r1.488 -r1.489
--- Changes 2000/05/19 16:01:22 1.488
+++ Changes 2000/05/23 15:56:04 1.489
@@ -10,6 +10,9 @@
=item 1.24_01-dev
+fix 1.24's Apache::Table-unset changes for win32
+[Randy Kobes [EMAIL PROTECTED]]
+
fix broken Win32 build (unresolved external symbol _ap_configtestonly)
[Eric Cholet [EMAIL PROTECTED]]
1.10 +5 -1 modperl/src/modules/perl/Table.xs
Index: Table.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Table.xs,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Table.xs 2000/05/12 22:45:32 1.9
+++ Table.xs 2000/05/23 15:56:12 1.10
@@ -58,7 +58,11 @@
}
-static void table_delete(table *tab, const char *key, const char *val)
+static void
+#ifdef WIN32
+_stdcall
+#endif
+table_delete(table *tab, const char *key, const char *val)
{
table_unset(tab, val);
}
cvs commit: modperl/lib/Apache Resource.pm
dougm 00/05/23 11:45:09
Modified:.Changes
lib/Apache Resource.pm
Log:
Apache::Resource was not converting PERL_RLIMIT_AS to MB values
Revision ChangesPath
1.491 +3 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.490
retrieving revision 1.491
diff -u -r1.490 -r1.491
--- Changes 2000/05/23 18:15:45 1.490
+++ Changes 2000/05/23 18:45:07 1.491
@@ -10,6 +10,9 @@
=item 1.24_01-dev
+Apache::Resource was not converting PERL_RLIMIT_AS to MB values
+thanks to Ian Kallen for the spot
+
fix unescape_url_info() when url is undef or "",
thanks to Kenneth Lee for the spot
1.10 +1 -1 modperl/lib/Apache/Resource.pm
Index: Resource.pm
===
RCS file: /home/cvs/modperl/lib/Apache/Resource.pm,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Resource.pm 2000/03/23 04:48:56 1.9
+++ Resource.pm 2000/05/23 18:45:09 1.10
@@ -26,7 +26,7 @@
sub DEFAULT_RLIMIT_FSIZE () { 10 } #file size (MB)
sub DEFAULT_RLIMIT_STACK () { 20 } #stack size (MB)
-my %is_mb = map {$_,1} qw{DATA RSS STACK FSIZE CORE MEMLOCK};
+my %is_mb = map {$_,1} qw{DATA RSS STACK FSIZE CORE MEMLOCK AS};
sub debug { print STDERR @_ if $Debug }
cvs commit: modperl-2.0/src/modules/perl modperl_tipool.c modperl_tipool.h
dougm 00/05/23 13:53:38
Added: src/modules/perl modperl_tipool.c modperl_tipool.h
Log:
"thread item pool" - generic logic broken out from modperl_interp.c so it can be
reused for other things, e.g. database connection handles
Revision ChangesPath
1.1 modperl-2.0/src/modules/perl/modperl_tipool.c
Index: modperl_tipool.c
===
#ifdef USE_ITHREADS
#include "mod_perl.h"
/*
* tipool == "thread item pool"
* this module is intended to provide generic stuctures/functions
* for managing a "pool" of a given items (data structures) within a threaded
* process. at the moment, mod_perl uses this module to manage a pool
* of PerlInterpreter objects. it should be quite easy to reuse for
* other data, such as database connection handles and the like.
* while it is "generic" it is also tuned for Apache, making use of
* ap_pool_t and the like, and implementing start/max/{min,max}_spare/
* max_requests configuration.
* this is another "proof-of-concept", plenty of room for improvement here
*/
modperl_list_t *modperl_list_new(ap_pool_t *p)
{
modperl_list_t *listp =
(modperl_list_t *)ap_pcalloc(p, sizeof(*listp));
return listp;
}
modperl_list_t *modperl_list_last(modperl_list_t *list)
{
while (list-next) {
list = list-next;
}
return list;
}
modperl_list_t *modperl_list_first(modperl_list_t *list)
{
while (list-prev) {
list = list-prev;
}
return list;
}
modperl_list_t *modperl_list_append(modperl_list_t *list,
modperl_list_t *new_list)
{
modperl_list_t *last;
new_list-prev = new_list-next = NULL;
if (!list) {
return new_list;
}
last = modperl_list_last(list);
last-next = new_list;
new_list-prev = last;
return list;
}
modperl_list_t *modperl_list_prepend(modperl_list_t *list,
modperl_list_t *new_list)
{
new_list-prev = new_list-next = NULL;
if (!list) {
return new_list;
}
if (list-prev) {
list-prev-next = new_list;
new_list-prev = list-prev;
}
list-prev = new_list;
new_list-next = list;
return new_list;
}
modperl_list_t *modperl_list_remove(modperl_list_t *list,
modperl_list_t *rlist)
{
modperl_list_t *tmp = list;
while (tmp) {
if (tmp != rlist) {
tmp = tmp-next;
}
else {
if (tmp-prev) {
tmp-prev-next = tmp-next;
}
if (tmp-next) {
tmp-next-prev = tmp-prev;
}
if (list == tmp) {
list = list-next;
}
break;
}
}
#ifdef MP_TRACE
if (!tmp) {
/* should never happen */
MP_TRACE_i(MP_FUNC, "failed to find 0x%lx in list 0x%lx\n",
(unsigned long)rlist, (unsigned long)list);
}
#endif
return list;
}
modperl_list_t *modperl_list_remove_data(modperl_list_t *list,
void *data,
modperl_list_t **listp)
{
modperl_list_t *tmp = list;
while (tmp) {
if (tmp-data != data) {
tmp = tmp-next;
}
else {
*listp = tmp;
if (tmp-prev) {
tmp-prev-next = tmp-next;
}
if (tmp-next) {
tmp-next-prev = tmp-prev;
}
if (list == tmp) {
list = list-next;
}
break;
}
}
return list;
}
modperl_tipool_t *modperl_tipool_new(ap_pool_t *p,
modperl_tipool_config_t *cfg,
modperl_tipool_vtbl_t *func,
void *data)
{
modperl_tipool_t *tipool =
(modperl_tipool_t *)ap_pcalloc(p, sizeof(*tipool));
tipool-ap_pool = p;
tipool-cfg = cfg;
tipool-func = func;
tipool-data = data;
MUTEX_INIT(tipool-tiplock);
COND_INIT(tipool-available);
return tipool;
}
void modperl_tipool_init(modperl_tipool_t *tipool)
{
int i;
for (i=0; itipool-cfg-start; i++) {
void *item =
(*tipool-func-tipool_sgrow)(tipool, tipool-data);
modperl_tipool_add(tipool, item);
}
MP_TRACE_i(MP_FUNC, "start=%d, max=%d, min_spare=%d, max_spare=%d\n",
tipool-cfg-start, tipool-cfg-max,
tipool-cfg-min_spare, tipool-cfg-max_spare);
cvs commit: modperl-2.0/src/modules/perl mod_perl.c mod_perl.h modperl_config.c modperl_config.h modperl_interp.c modperl_types.h
dougm 00/05/23 13:54:47
Modified:lib/ModPerl Code.pm
src/modules/perl mod_perl.c mod_perl.h modperl_config.c
modperl_config.h modperl_interp.c modperl_types.h
Log:
integrate with tipool
implement PerlInterpMaxRequests
Revision ChangesPath
1.25 +1 -1 modperl-2.0/lib/ModPerl/Code.pm
Index: Code.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- Code.pm 2000/04/30 18:36:51 1.24
+++ Code.pm 2000/05/23 20:54:42 1.25
@@ -377,7 +377,7 @@
generate_trace = {h = 'modperl_trace.h'},
);
-my @c_src_names = qw(interp log config callback gtop);
+my @c_src_names = qw(interp tipool log config callback gtop);
my @g_c_names = map { "modperl_$_" } qw(hooks directives xsinit);
my @c_names = ('mod_perl', (map "modperl_$_", @c_src_names));
sub c_files { [map { "$_.c" } @c_names, @g_c_names] }
1.14 +2 -0 modperl-2.0/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- mod_perl.c2000/04/29 02:37:36 1.13
+++ mod_perl.c2000/05/23 20:54:44 1.14
@@ -79,6 +79,8 @@
"Max number of spare Perl interpreters"),
MP_SRV_CMD_TAKE1("PerlInterpMinSpare", interp_min_spare,
"Min number of spare Perl interpreters"),
+MP_SRV_CMD_TAKE1("PerlInterpMaxRequests", interp_max_requests,
+ "Max number of requests per Perl interpreters"),
#endif
MP_CMD_ENTRIES,
{ NULL },
1.14 +1 -0 modperl-2.0/src/modules/perl/mod_perl.h
Index: mod_perl.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- mod_perl.h2000/04/28 20:07:34 1.13
+++ mod_perl.h2000/05/23 20:54:44 1.14
@@ -34,6 +34,7 @@
#include "modperl_types.h"
#include "modperl_config.h"
#include "modperl_callback.h"
+#include "modperl_tipool.h"
#include "modperl_interp.h"
#include "modperl_log.h"
1.10 +3 -2 modperl-2.0/src/modules/perl/modperl_config.c
Index: modperl_config.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- modperl_config.c 2000/04/27 21:42:25 1.9
+++ modperl_config.c 2000/05/23 20:54:44 1.10
@@ -119,7 +119,7 @@
#ifdef USE_ITHREADS
scfg-interp_pool_cfg =
-(modperl_interp_pool_config_t *)
+(modperl_tipool_config_t *)
ap_pcalloc(p, sizeof(*scfg-interp_pool_cfg));
/* XXX: determine reasonable defaults */
@@ -127,7 +127,7 @@
scfg-interp_pool_cfg-max_spare = 3;
scfg-interp_pool_cfg-min_spare = 3;
scfg-interp_pool_cfg-max = 5;
-
+scfg-interp_pool_cfg-max_requests = 2000;
#endif /* USE_ITHREADS */
return scfg;
@@ -198,5 +198,6 @@
MP_IMP_INTERP_POOL_CFG(max);
MP_IMP_INTERP_POOL_CFG(max_spare);
MP_IMP_INTERP_POOL_CFG(min_spare);
+MP_IMP_INTERP_POOL_CFG(max_requests);
#endif /* USE_ITHREADS */
1.10 +1 -0 modperl-2.0/src/modules/perl/modperl_config.h
Index: modperl_config.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.h,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- modperl_config.h 2000/04/27 21:42:25 1.9
+++ modperl_config.h 2000/05/23 20:54:44 1.10
@@ -30,6 +30,7 @@
MP_DECLARE_SRV_CMD(interp_max);
MP_DECLARE_SRV_CMD(interp_max_spare);
MP_DECLARE_SRV_CMD(interp_min_spare);
+MP_DECLARE_SRV_CMD(interp_max_requests);
#endif
#define MP_SRV_CMD_TAKE1(name, item, desc) \
1.12 +38 -231 modperl-2.0/src/modules/perl/modperl_interp.c
Index: modperl_interp.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- modperl_interp.c 2000/05/01 23:29:04 1.11
+++ modperl_interp.c 2000/05/23 20:54:44 1.12
@@ -7,120 +7,6 @@
#ifdef USE_ITHREADS
-modperl_list_t *modperl_list_new(ap_pool_t *p)
-{
-modperl_list_t *listp =
-(modperl_list_t *)ap_pcalloc(p, sizeof(*listp));
-return
