Re: Callback called exit.

2004-05-07 Thread Glenn
On Thu, May 06, 2004 at 10:55:14AM -0600, Brian Hirt wrote:
 
 On May 6, 2004, at 10:27 AM, Perrin Harkins wrote:
 
 On Wed, 2004-05-05 at 22:11, Brian Hirt wrote:
 I've been running across a problem lately where a child process
 terminates because of an out of memory error.   It prints Out of 
 Memory
 once, the the process sucks up all available cpu print Callback 
 called
 exit. to the log file until it hit's it's 2GB max size.
 
 I'm just guessing here, but this is probably because apache is trying 
 to
 spawn new processes, and they keep dying because there's no memory.
 
 
 Thanks for the response, interesting insight into the history of $^M.
 
  When I've seen this happen, it's the same PID spewing the messages, 
 there are no forkings going on.   The system isn't actually out of 
 memory, and there is plenty of it available for the parent httpd 
 process to fork.The child process has an rlimit set which is why 
 it's getting an out of memory error.  I initially set the rlimit, 
 because at one point in the past the ImageMagick module would every now 
 and then go crazy and consume all available memory which would bring 
 down everything.

Yes, thanks as well.  I didn't know how ineffective that was, and am
glad I wasn't setting aside too much memory for it.

Brian, if you can trigger the OOM and Callback called exit loop,
would you try my example mod_perl_startup.pl and use this at the end:

## Importing CGI::Carp sets $main::SIG{__DIE__} = \CGI::Carp::die;
## Override that to additionally give a stack backtrace
$main::SIG{__DIE__} = sub { undef $M; CGI::Carp::confess; };


The 'undef $M' will mark the memory as unused (as long as nothing
else has a reference to it), and if Perl garbage collection kicks
in before the looping problem, then you might have some memory to
work with.  I don't know the threshold offhand that Perl uses to
trigger freeing the memory back to the system when using the
system malloc, but a couple of MBs would most likely do it.

Of course, this assumes that the loop is occurring somewhere after
die() is called, and after this routine is called.  Worth a shot...

Cheers,
Glenn

-- 
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: mp2 static build on HPUX11i: tests

2004-05-07 Thread olivier . blanc

Hey Stas,







Stas Bekman [EMAIL PROTECTED]
04/05/2004 19:38


Pour :[EMAIL PROTECTED], mod_perl Mailing List [EMAIL PROTECTED], Philippe M. Chiasson [EMAIL PROTECTED]
cc :
Objet :Re: mp2 static build on HPUX11i: tests




2) the rest of the tests fail on $ENV{REMOTE_ADDR} and $r-remote_address 
returning 0.0.0.0 instead of 127.0.0.1. Sounds like an ipv6 issue to me. but 
since all those running ipv6 didn't report that problem that sounds as either 
a bug in Apache on HPUX11i or some OS issues. Olivier, could you try a mod_cgi 
script that prints out $ENV{REMOTE_ADDR}, when your client is running on the 
same machine and when it's running from another machine? Thanks.

I checked that variable through PHP. It gave me the same result : 0.0.0.0

What could I check to go further ?

olivier



Re: Database handle destroyed.....

2004-05-07 Thread Frank Wiles
On Thu, 06 May 2004 19:00:46 -0700
Stas Bekman [EMAIL PROTECTED] wrote:

 Hulya Gurer wrote:
  
  Sorry Stas, here it's.
  
  We are already using Apache::DBI-connect_on_init() and there are
  not many accesses
  to the database at this point that concern more than one connection.
 
 As I suggested:
 
   Apache::DBI doc doesn't claim to be ported to 2.0, it only
  suggests that it may work or may not. I suppose that someone needs
  to port it.
 
 Anybody to port it? Shouldn't be too hard to do that. It'd be nice to
 equip it with a full Apache-Test based test suite, but that could be a
 next step.

  Well the source leads me to believe they already know it doesn't work
  with mp2.  To quote it TODO - Should check for mod_perl 2 and do
  the right thing there.  

  I'll give it a go over the weekend and see if I can get it ported. 

  I'll probably need it for my current project once it goes production
  anyway. 

 -
   Frank Wiles [EMAIL PROTECTED]
   http://frank.wiles.org
 -


-- 
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



[ANNOUNCE] Apache-AuthenNTLM-2.07

2004-05-07 Thread Shannon Eric Peevey
The uploaded file

   Apache-AuthenNTLM-2.07.tar.gz

has entered CPAN as

 file: $CPAN/authors/id/S/SP/SPEEVES/Apache-AuthenNTLM-2.07.tar.gz
 size: 55379 bytes
  md5: 27c2f1126cabef88f16cf349931acc4d
This release fixes the lazy finger problem in the previous module.  (Thanks for catching it Dan Roegelein!)

--
Shannon Eric Peevey =  speeves
Dyno-Mite! System Administrator =  [EMAIL PROTECTED]
Central Web Support =  (940) 369-8876
University of North Texas   =  http://web2.unt.edu


--
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: Database handle destroyed.....

2004-05-07 Thread Mark A. Downing
On Fri, 7 May 2004, Frank Wiles wrote:

   Well the source leads me to believe they already know it doesn't work
   with mp2.  To quote it TODO - Should check for mod_perl 2 and do
   the right thing there.

I made some changes to make Apache-DBI work with mod_perl2 a few months ago.
It works great for me. I gave them to Ask, but nothing was apparently done
with it.

It's not elegant, but it works for me. Here is the diff:


--- DBI.pm  Tue Feb 17 16:18:50 2004
+++ DBI.pm.new  Thu Feb 26 14:52:49 2004
@@ -8,6 +8,7 @@
 use Carp qw(carp);

 require_version DBI 1.00;
+use constant MP2 = $mod_perl::VERSION = 1.99;

 $Apache::DBI::VERSION = '0.94';

@@ -32,9 +33,14 @@
 # provide a handler which creates all connections during server startup

 # TODO - Should check for mod_perl 2 and do the right thing there
-carp Apache.pm was not loaded\n and return unless $INC{'Apache.pm'};
-if([EMAIL PROTECTED] and Apache-can('push_handlers')) {
-Apache-push_handlers(PerlChildInitHandler = \childinit);
+if (MP2) {
+   Apache-server-push_handlers(PerlChildInitHandler = \childinit);
+}
+else {
+   carp Apache.pm was not loaded\n and return unless $INC{'Apache.pm'};
+   if([EMAIL PROTECTED] and Apache-can('push_handlers')) {
+   Apache-push_handlers(PerlChildInitHandler = \childinit);
+   }
 }
 # store connections
 push @ChildConnect, [EMAIL PROTECTED];
@@ -94,12 +100,23 @@
 # this PerlCleanupHandler is supposed to initiate a rollback after the script has 
finished if AutoCommit is off.
 my $needCleanup = ($Idx =~ /AutoCommit[^\d]+0/) ? 1 : 0;
 # TODO - Fix mod_perl 2.0 here
-if(!$Rollback{$Idx} and $needCleanup and Apache-can('push_handlers')) {
-print STDERR $prefix push PerlCleanupHandler \n if $Apache::DBI::DEBUG  1;
-Apache-push_handlers(PerlCleanupHandler, \cleanup);
-# make sure, that the rollback is called only once for every
-# request, even if the script calls connect more than once
-$Rollback{$Idx} = 1;
+if (MP2) {
+   if(!$Rollback{$Idx} and $needCleanup) {
+   print STDERR $prefix push PerlCleanupHandler \n if $Apache::DBI::DEBUG  
1;
+   Apache-server-push_handlers(PerlCleanupHandler, \cleanup);
+   # make sure, that the rollback is called only once for every
+   # request, even if the script calls connect more than once
+   $Rollback{$Idx} = 1;
+}
+}
+else {
+   if(!$Rollback{$Idx} and $needCleanup and Apache-can('push_handlers')) {
+   print STDERR $prefix push PerlCleanupHandler \n if $Apache::DBI::DEBUG  
1;
+   Apache-push_handlers(PerlCleanupHandler, \cleanup);
+   # make sure, that the rollback is called only once for every
+   # request, even if the script calls connect more than once
+   $Rollback{$Idx} = 1;
+   }
 }

 # do we need to ping the database ?

-- 
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: Database handle destroyed.....

2004-05-07 Thread Frank Wiles
On Fri, 7 May 2004 09:31:44 -0700 (PDT)
Mark A. Downing [EMAIL PROTECTED] wrote:

 On Fri, 7 May 2004, Frank Wiles wrote:
 
Well the source leads me to believe they already know it doesn't
work with mp2.  To quote it TODO - Should check for mod_perl 2
and do the right thing there.
 
 I made some changes to make Apache-DBI work with mod_perl2 a few
 months ago. It works great for me. I gave them to Ask, but nothing was
 apparently done with it.
 
 It's not elegant, but it works for me. Here is the diff:

  Could be that he just hasn't had time to release a new version yet.

  Thanks for letting me know so I didn't waste my time this weekend! :) 

 -
   Frank Wiles [EMAIL PROTECTED]
   http://frank.wiles.org
 -


-- 
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: Database handle destroyed.....

2004-05-07 Thread Hulya Gurer


Actually everything works with Perl 5.8.0 mod_perl 1.99.08 gcc
2.95.3 configuration,
this error showed up after we upgraded one of our server to perl 5.8.3,
mod_1.99.13, gcc.295.3
H.

At 07:33 AM 5/7/2004, Frank Wiles wrote:
On Thu, 06 May 2004 19:00:46
-0700
Stas Bekman [EMAIL PROTECTED] wrote:
 Hulya Gurer wrote:
  
  Sorry Stas, here it's.
  
  We are already using Apache::DBI-connect_on_init() and
there are
  not many accesses
  to the database at this point that concern more than one
connection.
 
 As I suggested:
 
  Apache::DBI doc doesn't claim to be ported to 2.0, it
only
 suggests that it may work or may not. I suppose that
someone needs
 to port it.
 
 Anybody to port it? Shouldn't be too hard to do that. It'd be nice
to
 equip it with a full Apache-Test based test suite, but that could be
a
 next step.
 Well the source leads me to believe they already know it doesn't
work
 with mp2. To quote it TODO - Should check for mod_perl
2 and do
 the right thing there. 
 I'll give it a go over the weekend and see if I can get it ported.

 I'll probably need it for my current project once it goes
production
 anyway. 
-
 Frank Wiles [EMAIL PROTECTED]

http://frank.wiles.org
-


Re: Database handle destroyed.....

2004-05-07 Thread Frank Wiles
On Fri, 07 May 2004 09:49:13 -0700
Hulya Gurer [EMAIL PROTECTED] wrote:

 
 Actually everything works with Perl 5.8.0 mod_perl 1.99.08 gcc 2.95.3 
 configuration,
 this error showed up after we upgraded one of our server to perl
 5.8.3, mod_1.99.13, gcc.295.3
 
 H.
 
 
 At 07:33 AM 5/7/2004, Frank Wiles wrote:
 On Thu, 06 May 2004 19:00:46 -0700
 Stas Bekman [EMAIL PROTECTED] wrote:
 
   Hulya Gurer wrote:
   
Sorry Stas, here it's.
   
We are already using Apache::DBI-connect_on_init() and there
are not many accesses
to the database at this point that concern more than one
connection.
  
   As I suggested:
  
 Apache::DBI doc doesn't claim to be ported to 2.0, it only
suggests that it may work or may not. I suppose that someone
needs to port it.
  
   Anybody to port it? Shouldn't be too hard to do that. It'd be nice
   to equip it with a full Apache-Test based test suite, but that
   could be a next step.
 
Well the source leads me to believe they already know it doesn't
work with mp2.  To quote it TODO - Should check for mod_perl 2
and do the right thing there.
 
I'll give it a go over the weekend and see if I can get it ported.
 
I'll probably need it for my current project once it goes
production anyway.

  Yeah now that I read the change log it appears there have been several
  patches to add mp2 support.  If you're running the latest version
  0.94, I'm betting the problem is probably with an API change between
  1.99_08 and 1.99_13.  But that's just from taking a quick glance. 

 -
   Frank Wiles [EMAIL PROTECTED]
   http://frank.wiles.org
 -


-- 
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: mp2 static build on HPUX11i: tests

2004-05-07 Thread Stas Bekman
2) the rest of the tests fail on $ENV{REMOTE_ADDR} and $r-remote_address 


returning 0.0.0.0 instead of 127.0.0.1. Sounds like an ipv6 issue to me. 
but 

since all those running ipv6 didn't report that problem that sounds as 
either 

a bug in Apache on HPUX11i or some OS issues. Olivier, could you try a 
mod_cgi 

script that prints out  $ENV{REMOTE_ADDR}, when your client is running on 
the 

same machine and when it's running from another machine? Thanks.


I checked that variable through PHP. It gave me the same result : 0.0.0.0
Perfect. So it's not an issue with mod_perl.

What could I check to go further ?
I suppose it's your IPv6 setup. You probably have the localhost entry mapped 
to ::1 in /etc/hosts?

::1 localhost

I suppose we could test for '127.0.0.1' || '0.0.0.0'. Any difference if you 
replace it with:

127.0.0.1 localhost
--
__
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
--
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


[MP2] sharing between threads using mpm_worker.

2004-05-07 Thread Richard F. Rebel

Hello,

I am experimenting here and I am curious about something.

Is it possible to share a variable using threads::shared between perl
interpreter threads in mod_perl?  These being the interpreters started
when a parent starts.

Eg:

use threads::shared;

my $sharedVar = bleh;

sub handler : method {
...
}

Now, I know if I go ahead and create threads in the handler method or
even a pool of global worker threads, $sharedVar is shared between the
threads created.  But what of the other threads that are started and
sitting in the pool of interps that mod_perl creates upon startup?  How
can I share a variable between all of the interpreter threads?  What
about locking or use of semaphores or signals?

Maybe I am missing something, perhaps it's not possible.

I am hoping to use an in house class in mod_perl2 that maintains it's
own threads for performing tasks.  The problem is one task has to be
synchronized between all threads in a whole process.  Works fine under
perl alone, problems arise under mod_perl+worker_mpm tho.

Thanks,

-- 
Richard F. Rebel
[EMAIL PROTECTED]
t. 212.239.


signature.asc
Description: This is a digitally signed message part


Re: [MP2] sharing between threads using mpm_worker.

2004-05-07 Thread Stas Bekman
Richard F. Rebel wrote:
Hello,

I am experimenting here and I am curious about something.

Is it possible to share a variable using threads::shared between perl
interpreter threads in mod_perl?  These being the interpreters started
when a parent starts.
Eg:

use threads::shared;

my $sharedVar = bleh;

sub handler : method {
...
}
Now, I know if I go ahead and create threads in the handler method or
even a pool of global worker threads, $sharedVar is shared between the
threads created.  But what of the other threads that are started and
sitting in the pool of interps that mod_perl creates upon startup?  How
can I share a variable between all of the interpreter threads?  What
about locking or use of semaphores or signals?
Maybe I am missing something, perhaps it's not possible.

I am hoping to use an in house class in mod_perl2 that maintains it's
own threads for performing tasks.  The problem is one task has to be
synchronized between all threads in a whole process.  Works fine under
perl alone, problems arise under mod_perl+worker_mpm tho.
Everything should work identically, and you need to do locking all the same. 
The only thing to be aware of is that perl requires you to declare a shared 
variable before you spawn threads. Same goes for mod_perl - declare your 
shared variables at the server startup, before perl interpreters are created 
and you should be able to share those. I haven't tested that though. But in 
theory it should work. So make sure that you load that module that you quoted 
a part of above at the server startup and see if makes any difference. We 
should add a test for that.

--
__
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
--
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: [Patch mp2] Fix api/module test to pass on static builds

2004-05-07 Thread Geoffrey Young

Actually, I can't think of a good reason why checking for 'module.so' and not
'module.c' would make sense.


Hmm, may be someone will want to know that it was loaded as DSO.
 
 
 Yeah, I can't think really why, but that's what .so would be for.

really?

http://marc.theaimsgroup.com/?t=9882086623r=1w=2

;)

--Geoff

-- 
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: Transactions corruption and persistent connections

2004-05-07 Thread Hans Poo R.
Perrin

I have an InitHandler in a Files section (in order to promote perl i put this
extension to the files).

Files *.perl
 PerlInitHandler General::init_dbk
 SetHandler  perl-script
 PerlHandler Fosis
/Files

Fosis::handler is the main Dispatcher of the dynamic content. It can use the
database handler via a Global variable $dbh, initialized en the init_db
process showed above, this database variable is defined in the General module
and is exported by default into the namespace in every module that uses the
module.

sub init_db {
 
   
$dbh = DBI-connect($dsn, $user, $pass, $options) or die Imposible conectar
con la base de datos.  .  DBI-errstr;  
 

 
   
}

There is no more about the database connection in any side of the System.

I turned on $Apache::DBI on level 2 of debugging and i've included the output
of the error_log. It doesn't look so bad... at first glance it looks like some
connections are being reused. And the message: Issuing rollback() for
database handle ... isn't generated in all the requests.

# 1: report about new connect
# 2: full debug output
$Apache::DBI::DEBUG = 2;

Begin of output
--
17985 Apache::DBI push PerlCleanupHandler
17985 Apache::DBI need ping: yes
17985 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
17985 Apache::DBI PerlCleanupHandler
17985 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
18067 Apache::DBI PerlCleanupHandler
18067 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
17987 Apache::DBI push PerlCleanupHandler
17987 Apache::DBI need ping: yes
17987 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
17987 Apache::DBI need ping: no
17987 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
17987 Apache::DBI PerlCleanupHandler
17987 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
18071 Apache::DBI push PerlCleanupHandler
18071 Apache::DBI need ping: yes
18071 Apache::DBI new connect to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect().
18071 Apache::DBI PerlCleanupHandler
18071 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
18066 Apache::DBI push PerlCleanupHandler
18066 Apache::DBI need ping: yes
18066 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
18066 Apache::DBI PerlCleanupHandler
18066 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
18048 Apache::DBI push PerlCleanupHandler
18048 Apache::DBI need ping: yes
18048 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
18048 Apache::DBI PerlCleanupHandler
18048 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
17988 Apache::DBI PerlCleanupHandler
17988 Apache::DBI PerlCleanupHandler rollback for
dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid
17984 Apache::DBI push PerlCleanupHandler
17984 Apache::DBI need ping: yes
17984 Apache::DBI already connected to
'dbname=puente;host=localhost^\userid^\x^\AutoCommit=0^\PrintError=1^\RaiseError=1^\Username=userid'
17984 Apache::DBI PerlCleanupHandler
17984 Apache::DBI PerlCleanupHandler rollback for

Re: Howto use emacs and perldb to debug mod_perl?

2004-05-07 Thread Paul G. Weiss
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/home/myacct/httpd-debug.
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 CPATH

=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 CRun perldb (like this):, with a
default response after the colon.  Instead of the default, type in
C/home/myacct/httpd-debug dummy, i.e. the script you prepared above.
The Cdummy 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


Apache::SmallProf

2004-05-07 Thread Jens Gassmann
Hi,

i try to profile my mod_perl script. I setup Apache::SmallProf at my 
apache2 server.

*add to my httpd.conf:*

Perl
  use Apache::DB ();
  Apache::DB-init;
/Perl
Location /
PerlFixupHandler Apache::SmallProf
/Location
*and starts the apache2 -X *

[notice] Apache::DB initialized in child 25276

*now i try to open a site, but:*

[Fri May 07 23:33:10 2004] [error] [client 192.168.1.1] Can't locate 
object method server_root_relative via package Apache::RequestRec at 
/usr/lib/perl5/vendor_perl/5.8.3/i686-linux/Apache/SmallProf.pm line 
25.\n, referer: 
http://nak2003.local/site/1749638154688210/startseite/aktuelles/news-143.htm

Whats wrong? I could not find any additionaly documentation to 
Apache::DB - maybe someone could help me here,

Thanks and regards,

--
jens gassmann
Online Software Design - http://www.aisware.de/
--
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: Apache::SmallProf

2004-05-07 Thread Stas Bekman
Jens Gassmann wrote:
Hi,

i try to profile my mod_perl script. I setup Apache::SmallProf at my 
apache2 server.

*add to my httpd.conf:*

Perl
  use Apache::DB ();
  Apache::DB-init;
/Perl
Location /
PerlFixupHandler Apache::SmallProf
/Location
*and starts the apache2 -X *

[notice] Apache::DB initialized in child 25276

*now i try to open a site, but:*

[Fri May 07 23:33:10 2004] [error] [client 192.168.1.1] Can't locate 
object method server_root_relative via package Apache::RequestRec at 
/usr/lib/perl5/vendor_perl/5.8.3/i686-linux/Apache/SmallProf.pm line 
25.\n, referer: 
http://nak2003.local/site/1749638154688210/startseite/aktuelles/news-143.htm 

Whats wrong? I could not find any additionaly documentation to 
Apache::DB - maybe someone could help me here,

Thanks and regards,
It looks like Frank had some modules loaded elsewhere and while porting forgot 
to add the missing modules: Apache::RequestRec, Apache::RequestUtil and a few 
others.

Frank, take a look at:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded
--
__
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
--
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: Database handle destroyed.....

2004-05-07 Thread Stas Bekman
Hulya Gurer wrote:
Mark, thanks for the code.  I am not sure why but it didn't work for 
us.  It could be
the versions of everything we are on now.

Unfortunately I can not lower the version of mod_perl-1.99.13 to .08 , 
Hulya, why do you need to downgrade to .08? Have you actually tried to patch 
Apache::DBI with the patch Mark has posted? I'm not following you here.

__
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
--
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: Database handle destroyed.....

2004-05-07 Thread Stas Bekman
Hulya Gurer wrote:
Since everything was working on old versions I wanted to lower the 
mod_perl to 08,
but I can't anyway, so I am not lowering the mod_perl, but Mark's patch 
didn't work,
we tried it and still get the same thing.
Ah, now I understand. Thanks. Which version Mark is using?

At 04:03 PM 5/7/2004, Stas Bekman wrote:

Hulya Gurer wrote:

Mark, thanks for the code.  I am not sure why but it didn't work for 
us.  It could be
the versions of everything we are on now.
Unfortunately I can not lower the version of mod_perl-1.99.13 to .08 ,


Hulya, why do you need to downgrade to .08? Have you actually tried to 
patch Apache::DBI with the patch Mark has posted? I'm not following 
you here.
--
__
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
--
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


cvs commit: modperl-2.0/todo bugs_build

2004-05-07 Thread stas
stas2004/05/07 10:56:34

  Modified:todo bugs_build
  Log:
  HPUX11i doesn't build DSO
  
  Revision  ChangesPath
  1.5   +8 -0  modperl-2.0/todo/bugs_build
  
  Index: bugs_build
  ===
  RCS file: /home/cvs/modperl-2.0/todo/bugs_build,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -u -r1.4 -r1.5
  --- bugs_build29 Jan 2004 22:31:33 -  1.4
  +++ bugs_build7 May 2004 17:56:34 -   1.5
  @@ -35,6 +35,14 @@
   seemingly because of the problems with threads on
   FreeBSD (not sure what version).
   
  +HPUX11i DSO
  +PA-RISC2.0-thread-multi-LP64
  +hp-ux loire b.11.11 u 9000800 1756907651 unlimited-user license 
  +Cannot load .../modules/mod_perl.so into server: Error 0
  +http://marc.theaimsgroup.com/?t=10832531082r=1w=2
  +Bill Rowe gives some hints here
  +http://marc.theaimsgroup.com/?l=apache-modperlm=108334017416318w=2
  +Static works OK!
   
   * we should stop generating xs/apache_*, at least for a reason that
 it's incomplete and will be never complete as we don't keep up with
  
  
  


cvs commit: modperl-2.0 Changes

2004-05-07 Thread stas
stas2004/05/07 11:02:47

  Modified:ModPerl-Registry/t TEST.PL
   lib/ModPerl TestRun.pm
   .Changes
  Log:
  use the new Apache-Test attribute -minclient in the test suites. Now
  along with the default maxclients = minclients+1, we no longer should
  get 'server reached MaxClients setting' errors.
  
  Revision  ChangesPath
  1.15  +2 -2  modperl-2.0/ModPerl-Registry/t/TEST.PL
  
  Index: TEST.PL
  ===
  RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/TEST.PL,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -u -r1.14 -r1.15
  --- TEST.PL   6 Mar 2004 01:52:47 -   1.14
  +++ TEST.PL   7 May 2004 18:02:47 -   1.15
  @@ -16,7 +16,7 @@
   use base qw(Apache::TestRunPerl);
   
   # redirect tests require 2 servers
  -use constant MIN_MAXCLIENTS = 2;
  +use constant MIN_CLIENTS = 2;
   
   use File::Spec::Functions qw(catdir);
   use File::Basename qw(dirname);
  @@ -42,7 +42,7 @@
   $ENV{APACHE_TEST_STARTUP_TIMEOUT} ||
   DEFAULT_STARTUP_TIMEOUT;
   
  -$self-{conf_opts}-{maxclients} ||= MIN_MAXCLIENTS;
  +$self-{conf_opts}-{minclients} ||= MIN_CLIENTS;
   
   return $self-SUPER::new_test_config;
   }
  
  
  
  1.21  +2 -2  modperl-2.0/lib/ModPerl/TestRun.pm
  
  Index: TestRun.pm
  ===
  RCS file: /home/cvs/modperl-2.0/lib/ModPerl/TestRun.pm,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -u -r1.20 -r1.21
  --- TestRun.pm5 Mar 2004 02:42:32 -   1.20
  +++ TestRun.pm7 May 2004 18:02:47 -   1.21
  @@ -24,7 +24,7 @@
   # some mp2 tests require more than one server instance to be available
   # without which the server may hang, waiting for the single server
   # become available
  -use constant MIN_MAXCLIENTS = 2;
  +use constant MIN_CLIENTS = 2;
   
   sub new_test_config {
   my $self = shift;
  @@ -35,7 +35,7 @@
   $ENV{APACHE_TEST_STARTUP_TIMEOUT} ||
   Apache::Build-build_config-mpm_is_threaded() ? 300 : 120;
   
  -$self-{conf_opts}-{maxclients} ||= MIN_MAXCLIENTS;
  +$self-{conf_opts}-{minclients} ||= MIN_CLIENTS;
   
   ModPerl::TestConfig-new($self-{conf_opts});
   }
  
  
  
  1.367 +4 -0  modperl-2.0/Changes
  
  Index: Changes
  ===
  RCS file: /home/cvs/modperl-2.0/Changes,v
  retrieving revision 1.366
  retrieving revision 1.367
  diff -u -u -r1.366 -r1.367
  --- Changes   4 May 2004 06:42:00 -   1.366
  +++ Changes   7 May 2004 18:02:47 -   1.367
  @@ -12,6 +12,10 @@
   
   =item 1.99_14-dev
   
  +use the new Apache-Test attribute -minclient in the test suites. Now
  +along with the default maxclients = minclients+1, we no longer should
  +get 'server reached MaxClients setting' errors. [Stas]
  +
   new API for APR::Socket recv() and send() + updated tests [Stas]
   
   add infrastructure for new ModPerl::Const constants and the first
  
  
  


cvs commit: modperl-2.0/todo api_status

2004-05-07 Thread stas
stas2004/05/07 18:27:20

  Added:   todo api_status
  Log:
  API status
  
  Revision  ChangesPath
  1.1  modperl-2.0/todo/api_status
  
  Index: api_status
  ===
  This file provides the status of the supported API, via the
  API documentation files.
  
  col1 legend
  ---
  -: not started/unknown
  +: in process
  V: done (for 2.0 release)
  
  col2 legend
  ---
  -: not started/unknown
  P: post 2.0 (has API to be polished after 2.0 release)
  V: done completely
  
  - the file path is relative to the modperl-docs cvs repository
  #
  -- src/docs/2.0/api/Apache.pod
  -- src/docs/2.0/api/Apache/Access.pod
  -- src/docs/2.0/api/Apache/CmdParms.pod
  -- src/docs/2.0/api/Apache/Command.pod
  -- src/docs/2.0/api/Apache/Connection.pod
  -- src/docs/2.0/api/Apache/Const.pod
  -- src/docs/2.0/api/Apache/Directive.pod
  -- src/docs/2.0/api/Apache/Filter.pod
  -- src/docs/2.0/api/Apache/FilterRec.pod
  -- src/docs/2.0/api/Apache/HookRun.pod
  -- src/docs/2.0/api/Apache/Log.pod
  -- src/docs/2.0/api/Apache/Module.pod
  -- src/docs/2.0/api/Apache/PerlSections.pod
  -- src/docs/2.0/api/Apache/Process.pod
  -- src/docs/2.0/api/Apache/Reload.pod
  -- src/docs/2.0/api/Apache/RequestIO.pod
  -- src/docs/2.0/api/Apache/RequestRec.pod
  -- src/docs/2.0/api/Apache/RequestUtil.pod
  -- src/docs/2.0/api/Apache/Response.pod
  -- src/docs/2.0/api/Apache/Server.pod
  -- src/docs/2.0/api/Apache/ServerUtil.pod
  -- src/docs/2.0/api/Apache/Status.pod
  -- src/docs/2.0/api/Apache/SubProcess.pod
  -- src/docs/2.0/api/Apache/SubRequest.pod
  -- src/docs/2.0/api/Apache/URI.pod
  -- src/docs/2.0/api/Apache/Util.pod
  -- src/docs/2.0/api/Apache/compat.pod
  -- src/docs/2.0/api/Apache/porting.pod
  
  -- src/docs/2.0/api/ModPerl/BuildMM.pod
  VV src/docs/2.0/api/ModPerl/Global.pod
  -- src/docs/2.0/api/ModPerl/MM.pod
  -- src/docs/2.0/api/ModPerl/MethodLookup.pod
  -- src/docs/2.0/api/ModPerl/PerlRun.pod
  -- src/docs/2.0/api/ModPerl/Registry.pod
  -- src/docs/2.0/api/ModPerl/RegistryBB.pod
  -- src/docs/2.0/api/ModPerl/RegistryCooker.pod
  -- src/docs/2.0/api/ModPerl/RegistryLoader.pod
  -- src/docs/2.0/api/ModPerl/Util.pod
  
  -- src/docs/2.0/api/APR.pod
  -- src/docs/2.0/api/APR/Base64.pod
  -- src/docs/2.0/api/APR/Brigade.pod
  -- src/docs/2.0/api/APR/Bucket.pod
  -- src/docs/2.0/api/APR/Const.pod
  -- src/docs/2.0/api/APR/Date.pod
  -- src/docs/2.0/api/APR/Error.pod
  -- src/docs/2.0/api/APR/Finfo.pod
  -- src/docs/2.0/api/APR/NetLib.pod
  -- src/docs/2.0/api/APR/PerlIO.pod
  -- src/docs/2.0/api/APR/Pool.pod
  -- src/docs/2.0/api/APR/SockAddr.pod
  
  VP src/docs/2.0/api/APR/Socket.pod
  bind
  close
  connect
  listen
  recvfrom
  sendto
  
  -- src/docs/2.0/api/APR/Table.pod
  -- src/docs/2.0/api/APR/ThreadMutex.pod
  -- src/docs/2.0/api/APR/URI.pod
  -- src/docs/2.0/api/APR/Util.pod
  
  
  


cvs commit: modperl-2.0/xs/APR/Socket APR__Socket.h

2004-05-07 Thread stas
stas2004/05/07 18:28:25

  Modified:xs/APR/Socket APR__Socket.h
  Log:
  move to the exception objects
  
  Revision  ChangesPath
  1.9   +8 -5  modperl-2.0/xs/APR/Socket/APR__Socket.h
  
  Index: APR__Socket.h
  ===
  RCS file: /home/cvs/modperl-2.0/xs/APR/Socket/APR__Socket.h,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -u -r1.8 -r1.9
  --- APR__Socket.h 4 May 2004 06:14:44 -   1.8
  +++ APR__Socket.h 8 May 2004 01:28:25 -   1.9
  @@ -66,8 +66,8 @@
   /* this also magically assings to APR_Socket ;-) */
   mpxs_usage_va_1(APR__Socket, $socket-timeout_get());
   
  -MP_FAILURE_CROAK(apr_socket_timeout_get(APR__Socket, t));
  -
  +MP_RUN_CROAK(apr_socket_timeout_get(APR__Socket, t),
  + APR::Socket::timeout_get);
   return t;
   }
   
  @@ -75,7 +75,8 @@
   void mpxs_APR__Socket_timeout_set(pTHX_ apr_socket_t *socket,
apr_interval_time_t t)
   {
  -MP_FAILURE_CROAK(apr_socket_timeout_set(socket, t));
  +MP_RUN_CROAK(apr_socket_timeout_set(socket, t),
  + APR::Socket::timeout_set);
   }
   
   
  @@ -85,7 +86,8 @@
apr_int32_t opt)
   {
   apr_int32_t val;
  -MP_FAILURE_CROAK(apr_socket_opt_get(socket, opt, val));
  +MP_RUN_CROAK(apr_socket_opt_get(socket, opt, val),
  + APR::Socket::opt_get);
   return val;
   }
   
  @@ -93,5 +95,6 @@
   void mpxs_APR__Socket_opt_set(pTHX_ apr_socket_t *socket, apr_int32_t opt,
 apr_int32_t val)
   {
  -MP_FAILURE_CROAK(apr_socket_opt_set(socket, opt, val));
  +MP_RUN_CROAK(apr_socket_opt_set(socket, opt, val),
  + APR::Socket::opt_set);
   }