Re: Howto use emacs and perldb to debug mod_perl?
On Thu, 06 May 2004 12:22:49 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote:
If someone can write a section explaining how to do that properly, I
think it'll be a great addition to our docs. Just post the pod here and
I'll add it. Thanks.
OK, I'm not exactly a hand at writing pod but I had a go. Here it is:
=head1 NAME
perldbemacs - How do debug mod_perl using perldb in Emacs
=head1 DESCRIPTION
The perldb function in Emacs allows you to run the Perl debugger while
viewing the source code in another window. It is a much nicer environment
for debugging Perl than the plain standalone Perl debugger. This
is how to use perldb to debug mod_perl code.
=head2 Modifying perl5db.pl
Unfortunately, this requires a modification to perl5db.pl. First you need
to locate your copy of perl5db.pl. You can use perldoc to do it:
perl /usr/bin/perldoc -l Apache::perl5db.pl
or if you're using a specially built perl:
/my/perl `which perldoc` -l Apache::perl5db.pl
it will print out something like this:
/usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Apache/perl5db.pl
That's the file you need to edit. Locate the line:
$rl = 0, shift (@main::ARGV) if $slave_editor;
and right before it insert the line
$slave_editor ||= $ENV{SLAVE_EMACS};
=head2 Preparing httpd.conf
Now you need to make sure that the SLAVE_EMACS environment variable makes
it to the perl code that runs inside Apache. Fortunately this is easy:
PerlPassEnv SLAVE_EMACS
=head2 Your debugging script
Prepare a script for debugging. Call it, say, C.
It should go something like this:
#!/bin/sh
SLAVE_EMACS=1 exec httpd -X -DPERLDB=1
That is, of course, assuming that your mod_perl httpd is on the C
=head2 Starting the debugger
=over 4
=item 1.
Launch emacs.
=item 2.
Run the perldb function (Alt-X perldb)
=item 3.
It will prompt you by saying C, with a
default response after the colon. Instead of the default, type in
C, i.e. the script you prepared above.
The C is a dummy argument to keep emacs happy.
=item 4.
You should now be running the debugger.
=back
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Howto use emacs and perldb to debug mod_perl?
On Thu, 6 May 2004 16:12:16 +, <[EMAIL PROTECTED]> wrote:
James Moore claimed to have gotten it right:
http://groups.google.ch/groups?q=emacs+mod_perl&hl=en&lr=lang_en|lang_de&ie=UTF-8&oe=UTF-8&selm=1051404465.5094
+85%40yasure&rnum=1
It partially works for me. The last part doesn't:
James Moore wrote:
Not elegant, but it does get you full functionality (or at least the
only
bit I cared about, the => pointer into your code buffer for the current
line
of execution).
His method ruins it if you want to run the debugger w/o emacs.
Here's a modification that gets around that problem:
in the Apache/perl5db.pl file add the line:
$slave_editor ||= $ENV{SLAVE_EMACS};
right after the assignment to $slave_editor.
Then in your httpd.conf add the line:
PerlPassEnv SLAVE_EMACS
And in the script you pass to emacs when it says Run perldb (like this):
SLAVE_EMACS=1 exec httpd -X -DPERLDB
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: VirtualHost + PerlSetVar
On Mon, 22 Dec 2003 15:26:53 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
You don't need to walk the config tree to accomplish that. There is a
much simpler way:
sub post_config {
my($conf_pool, $log_pool, $temp_pool, $s) = @_;
for (my $vhost_s = $s->next; $vhost_s; $vhost_s = $vhost_s->next) {
my $port = $vhost_s->port;
my $val = $vhost_s->dir_config->{PostConfig};
warn "port: $port, val $val\n";
}
...
That is indeed much simpler. Is the fact that you can get from the root
server to vhost to vhost documented anywhere? I couldn't find it in the
docs.
But unfortunately I don't think it will work in the general case for
Apache::PageKit, because it needs to support different values in different
locations, i.e. for this configuration:
PerlSetVar PKIT_SERVER xyz
PerlSetVar PKIT_ROOT /pk/a
PerlSetVar PKIT_ROOT /pk/b
PerlSetVar PKIT_ROOT /pk/c
PerlSetVar PKIT_SERVER pqr
I should make three calls:
Apache::PageKit->startup("/pk/a", "xyz");
Apache::PageKit->startup("/pk/b", "xyz");
Apache::PageKit->startup("/pk/c", "pqr");
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: VirtualHost + PerlSetVar
Let me see if I have this straight.
With your patch, if I have:
PerlPostConfigHandler A
PerlPostConfigHandler B
PerlPostConfigHandler C
then A gets run once, B gets run once, and C gets run once.
But if I have:
PerlPostConfigHandler A
PerlPostConfigHandler C
then A gets run twice (once for the main server and once for the vhost)
and C gets run once?
If so, that would be even more confusing, and any author of a
PostConfigHandler would need to make sure that the code is safe if run for
each vhost. I think that would cause more problems than it would solve.
In my case a better solution would be to write a PerlPostConfigHandler
that walked the config tree and did the right thing for each vhost. In
the case of Apache::PageKit, Boris Zenter has already posted a
workaround. An alternative to that would be something like this:
PerlPostConfigHandler PageKitHandler::handle
PerlSetVar PKIT_ROOT onevalue
PerlSetVar PKIT_SERVER serverone
PerlSetVar PKIT_ROOT twovalue
PerlSetVar PKIT_SERVER servervalue
sub handle {
my $tree = Apache::Directive->conftree;
my @pkitroots = $tree->lookup('PerlSetVar', 'PKIT_ROOT');
foreach my $node (@pkitroots) {
my $rootvalue = $node->args->[1];
my $servervalue;
my $sib = $node->parent->first_child;
while ($sib) {
if (lc $sib->directive eq 'perlsetvar' && $sub->args->[0] eq
'PKIT_SERVER') {
$servervalue = $sub->args->[1];
last;
}
$sib = $sib->next;
}
Apache::PageKit->startup($rootvalue, $servervalue);
}
In other words, look for places where PKIT_ROOT is set and then look up
the value of PKIT_SERVER set in the same scope, and call
Apache::PageKit->startup with both args.
Actually this doesn't quite work because if PKIT_SERVER is inherited from
an enclosing scope, then the code above won't find it -- it really should
recurse upward on the parent if it doesn't find a value for PKIT_SERVER.
Furthermore, it doesn't consider PerlAddVar. It would be nice if
Apache::Directive was extended so that one could do the equivalent of
$node->dir_config("value").
-P
On Sun, 21 Dec 2003 19:46:15 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
Stas Bekman wrote:
Paul G. Weiss wrote:
Rats! PerlPostConfigHandler appears to have absolutely no effect when
placed inside a scope. It does indeed run when placed
outside. I know this because I have something like:
open(H, ">", "/tmp/output");
print H "something\n"
in my handler and the file written to only when PerlPostConfigHandler
is outside the scope. By the way, this is also true
with PostOpenLogsHandler. In fact, when I set
PerlTrace all
in my configuration file, I see the line:
modperl_callback_run_handlers: no PerlPostConfigHandler handlers
configured ()
You are right. I added a test and it fails :( I was pretty sure that it
should have worked.
OK, we have to do it ourselves, which is easy (.e.g with the patch
below). The problem is this: all vhosts inherit PerlPostConfigHandler
from the main server and run it. They all inherit the PerlSetVar as
well. I'm not sure this is the wanted behavior. I suppose this is why
Apache doesn't do it for each vhost. Comments?
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.205
diff -u -r1.205 mod_perl.c
--- src/modules/perl/mod_perl.c 15 Dec 2003 08:24:57 - 1.205
+++ src/modules/perl/mod_perl.c 22 Dec 2003 03:31:13 -
@@ -588,6 +588,17 @@
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s,
"mod_perl: using Perl HASH_SEED: %"UVuf,
MP_init_hash_seed);
#endif
+
+/* run PerlPostConfigHandler for each vhost (apache already does
+ * that for the main server) */
+for (s=s->next; s; s=s->next) {
+int rc = modperl_callback_files(MP_POST_CONFIG_HANDLER,
+pconf, plog, ptemp, s,
+MP_HOOK_RUN_ALL);
+if (rc != OK) {
+return rc;
+}
+}
return OK;
}
Here is the test:
--- /dev/null 1969-12-31 16:00:00.0 -0800
+++ t/hooks/startup.t 2003-12-21 19:05:29.0 -0800
@@ -0,0 +1,28 @@
+
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestUtil;
+use Apache::TestRequest;
+
+my $config = Apache::Test::config();
+my $path = Apache::TestRequest::module2path('TestHooks::startup');
+
+# XXX: vhosts are not run for postconfig at the moment
+my @modules = qw(default TestHooks::startup);
+#my @modules = qw(default TestHooks::);
+
+plan tests => scalar @modules;
+
+for my $module (sort @modules) {
+
+Apache::TestRequest::module($module);
Re: VirtualHost + PerlSetVar
Rats! PerlPostConfigHandler appears to have absolutely no effect when
placed inside a scope. It does indeed run when placed
outside. I know this because I have something like:
open(H, ">", "/tmp/output");
print H "something\n"
in my handler and the file written to only when PerlPostConfigHandler is
outside the scope. By the way, this is also true with
PostOpenLogsHandler. In fact, when I set
PerlTrace all
in my configuration file, I see the line:
modperl_callback_run_handlers: no PerlPostConfigHandler handlers
configured ()
in the errors log.
-Paul
On Sat, 20 Dec 2003 16:52:09 -0500, Paul G. Weiss <[EMAIL PROTECTED]> wrote:
Great suggestion. I'll certainly try that.
As to why I expected PerlSetVar to be available during startup, it is
because that is how it was with mod_perl1, and I wasn't considering the
fact that configuration in mod_perl2 is a very different animal. I'll
pass your suggestion on to the maintainer of Apache::PageKit (that is,
if he doesn't read this list), because it will affect his documentation.
-Paul
On Fri, 19 Dec 2003 18:32:46 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
Paul G. Weiss wrote:
[...]
The reason this is important is that I'm trying to get Apache::PageKit
to run in virtual hosts, and it depends on the availability of
PerlSetVar variables on startup.
First of all, why do you expect PerlSetVar to be available at the
server startup? The config phase is not completed and the value can be
overriden several times by the end of config.
Second, Apache->server always gives you the global (top-level) server,
so of course once you move PerlSetVar outside of vhost, you get to see
its value.
I think using PerlPostConfigHandler will let you achieve what you want:
PerlRequire /var/www/perl/startup.pl
# set value in global scope
PerlSetVar foo global
SetHandler perl-script
PerlHandler Module
# set value in virtual host scope
PerlSetVar foo virtual
PerlModule Module
PerlPostConfigHandler Module::start
package Module;
sub start {
my($conf_pool, $log_pool, $temp_pool, $s) = @_;
print "Module->start sees foo=" . $s->dir_config('foo') . "\n";
}
(this code is untested, but I think it should do what you want)
The difference is that you get the correct $s object here (which you
can't get during the config phase). Sounds like your case can be a
useful addition to the existing example:
http://perl.apache.org/docs/2.0/user/handlers/server.html#PerlPostConfigHandler
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: VirtualHost + PerlSetVar
Great suggestion. I'll certainly try that.
As to why I expected PerlSetVar to be available during startup, it is
because that is how it was with mod_perl1, and I wasn't considering the
fact that configuration in mod_perl2 is a very different animal. I'll
pass your suggestion on to the maintainer of Apache::PageKit (that is, if
he doesn't read this list), because it will affect his documentation.
-Paul
On Fri, 19 Dec 2003 18:32:46 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
Paul G. Weiss wrote:
[...]
The reason this is important is that I'm trying to get Apache::PageKit
to run in virtual hosts, and it depends on the availability of
PerlSetVar variables on startup.
First of all, why do you expect PerlSetVar to be available at the server
startup? The config phase is not completed and the value can be
overriden several times by the end of config.
Second, Apache->server always gives you the global (top-level) server,
so of course once you move PerlSetVar outside of vhost, you get to see
its value.
I think using PerlPostConfigHandler will let you achieve what you want:
PerlRequire /var/www/perl/startup.pl
# set value in global scope
PerlSetVar foo global
SetHandler perl-script
PerlHandler Module
# set value in virtual host scope
PerlSetVar foo virtual
PerlModule Module
PerlPostConfigHandler Module::start
package Module;
sub start {
my($conf_pool, $log_pool, $temp_pool, $s) = @_;
print "Module->start sees foo=" . $s->dir_config('foo') . "\n";
}
(this code is untested, but I think it should do what you want)
The difference is that you get the correct $s object here (which you
can't get during the config phase). Sounds like your case can be a
useful addition to the existing example:
http://perl.apache.org/docs/2.0/user/handlers/server.html#PerlPostConfigHandler
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: VirtualHost + PerlSetVar
More interesting info...
First of all, I've upgraded to mod_perl-1.99_11 with no change.
Second, I've determined that the per-VirtualHost values are visible in the
request, but not during server startup.
Here's the situation in an (I hope) easy to reproduce format:
-- config --
PerlRequire /var/www/perl/startup.pl
# set value in global scope
PerlSetVar foo global
SetHandler perl-script
PerlHandler Module
# set value in virtual host scope
PerlSetVar foo virtual
Module->start;
-- /var/www/perl/startup.pl --
use Apache2 ();
use Apache::RequestIO ();
use Apache::ServerUtil ();
use Apache::RequestRec ();
use Apache::Const -compile => ':common';
package Module;
sub start {
my $s = Apache->server;
print "Module->start sees foo=" . $s->dir_config('foo') . "\n";
}
sub handler {
my $r = shift;
my $value = $r->dir_config('foo');
$r->content_type('text/plain');
$r->print("Request sees foo=$value\n");
return Apache::OK;
}
1;
-- the output --
[EMAIL PROTECTED] pgweiss]# /usr/sbin/apachectl start
Module->start sees foo=global
[EMAIL PROTECTED] pgweiss]# access handle w/o virtual host
[EMAIL PROTECTED] pgweiss]# lwp-request http://localhost/module
foo=global
[EMAIL PROTECTED] pgweiss]# now access handle w/ virtual host
[EMAIL PROTECTED] pgweiss]# lwp-request http://localhost:9900/module
foo=virtual
[EMAIL PROTECTED] pgweiss]#
The reason this is important is that I'm trying to get Apache::PageKit to
run in virtual hosts, and it depends on the availability of PerlSetVar
variables on startup.
-Paul
On Fri, 19 Dec 2003 06:28:10 -0500, Paul G. Weiss <[EMAIL PROTECTED]> wrote:
I have something like this:
PerlModule Module
PerlSetVar abc def
Module->start;
and in Module.pm
use Apache::ServerUtil ()
...
sub startup
{
my $value = Apache->server->dir_config("abc");
...
}
and lo and behold - $value is undef ! However, if I take the PerlSetVar
and move it outside the VirtualHost, then $value is "def".
I'm using 2.0.47 + 1.99_10, only because I have rpms build for them (for
RH9). Has this problem been noticed and fixed in the latest release? I
don't see any mention of it in the mail archives.
-Paul Weiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
VirtualHost + PerlSetVar
I have something like this:
PerlModule Module
PerlSetVar abc def
Module->start;
and in Module.pm
use Apache::ServerUtil ()
...
sub startup
{
my $value = Apache->server->dir_config("abc");
...
}
and lo and behold - $value is undef ! However, if I take the PerlSetVar
and move it outside the VirtualHost, then $value is "def".
I'm using 2.0.47 + 1.99_10, only because I have rpms build for them (for
RH9). Has this problem been noticed and fixed in the latest release? I
don't see any mention of it in the mail archives.
-Paul Weiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Upgrading RedHat 9
I had found those. No _10 version. I'm currently trying to modify the srpm for mod_perl-1.99_07, which is available from RedHat, to use the .tar.gz for _10. I'm hopeful it will work. -P On Tue, 30 Sep 2003 14:09:10 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote: Paul G. Weiss wrote: I have httpd-2.0.40-21.5 installed with mod_perl-1.99_07-5 on a Red Hat 9 system. I'd like to upgrade to 2.0.47 for mod_perl-1.99_10 but there are no rpms available from RedHat. I can uninstall the existing rpms and build from source (at least I think I can, theoretically), but instead, I would like to build new rpms and replace the old ones. Any pointers to instructions on how to do this? Or advice on whether or not this is advisable? http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution lists: http://www.rpmfind.net/linux/rpm2html/search.php?query=mod_perl&submit=Search+ __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Upgrading RedHat 9
I have httpd-2.0.40-21.5 installed with mod_perl-1.99_07-5 on a Red Hat 9 system. I'd like to upgrade to 2.0.47 for mod_perl-1.99_10 but there are no rpms available from RedHat. I can uninstall the existing rpms and build from source (at least I think I can, theoretically), but instead, I would like to build new rpms and replace the old ones. Any pointers to instructions on how to do this? Or advice on whether or not this is advisable? -Paul
