Re: SegFault report with backtrace

2001-11-05 Thread karnurme


> > Here is a simple Test.pm handler that causes segfaults in our server.
> By accident I discovered that the segfaults went away when I renamed
> the file!  At the time I was doing some work for a company in London,

Thanks for idea! I'm afraid that the segfault report may be affected by
the naming, but the original module that caused the error was not named as
Test.pm. What a coincidence if I picked the one problematic
naming; Kari, the Midas of Bugs...

Best wishes,
-- 

Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547




Re: Perl Handlers and namespaces.

2001-11-05 Thread Stas Bekman

Guillaume wrote:

> I ran into this problem today. I am trying to develope a small
> application server with a few handlers and Apache/1.3.22 .
> 
> So I have something that looks like this set up in the apache conf file:
> 
> 
>
>   Allow from all
>
>PerlRequire "startup.pl"
>SetHandler perl-script
>PerlHandler AppServer
> 
>AuthName "AppServer"
>AuthType Basic
>PerlAuthenHandler AppServer::Auth
>require valid-user
> 
>PerlAccessHandler AppServer::Access
> 
> 
> Now, you notice that these packages are all under the same namespace.
> This, somehow, causes an 'Undefined subroutine &AppServer::handler
> called.' each time the server recieves a request from a client. However,
> if i move the main handler into another
> namespace or simply rename it to foo.pm ( and adjust the apache conf
> file of course ) the error magically disappears. If one of the access
> handler or authentification handler is under the same namespace as the
> main handler, i always get the undefined subroutine error msg.
> 
> I'm not sure why or how apache handles this or if it's a bug or if i'm
> just too tired and missed something somewhere else. I would appreciate
> someone's insight on this. Is it a bug / limitation /... ?
> 
> Thanks for your time,
> Guillaume
> 


It's a known kludge/bug:

http://perl.apache.org/guide/porting.html#More_package_name_related_issues



-- 


_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/




Re: SegFault report with backtrace

2001-11-05 Thread Ged Haywood

Hi there,

On Mon, 5 Nov 2001 [EMAIL PROTECTED] wrote:

> Here is a simple Test.pm handler that causes segfaults in our server.

Last year I had a Test.pm that caused segfaults too, on Solaris boxes.

By accident I discovered that the segfaults went away when I renamed
the file!  At the time I was doing some work for a company in London,
on a very tight schedule, so I never got the chance to investigate
further.  I sent a stack backtrace to Eric but we never got to the
bottom of it.

73,
Ged.

 




_session_id-problem with Apache::Session::Store::Postgres

2001-11-05 Thread Christoph Lange

Hi,

sorry, this is not exactly a mod_perl question but I hope somehow in the
wake of this issue.

Apache::Session::Store::Postgres problem:
After the initial login to my page, I define and tie a  %session which
produces a _session_id that is totally different from what it stores in the
sessions-table. So the next time my page is started (given the _session_id
as a parameter) I get the error-message
"Apache/Session/Store/Postgres.pm: Object does not exist in the data store"

Does anybody know what might cause this strange behavior? I will add the
code I consider important. If you don't have any idea (or the time to think
about it) I would be grateful for some lines of code that show how you use
Apache::Session::Store::Postgres.

Thanks for your help, Chris


use Apache::Session::Postgres;
use Apache::Session::Store::Postgres;

sub session
{
my %session;
tie %session, 'Apache::Session::Postgres', undef, {DataSource =>
"dbi:Pg:$dbrz_name", UserName =>$dbrz_ben, Password => $dbrz_pw, Commit =>
1} || return ("f", "Es kann im Moment keine neue Sizung angelegt werden.",
"");
$session{"bildrec"} = [$_[1]];
$session{"rz_benutzername"} = $_[2];
 return ("s", "", \%session);
}
##




Re: mod_perl-1.26, threads and LWP.pm

2001-11-05 Thread Ken Y. Clark

On Mon, 5 Nov 2001, Toni Andjelkovic wrote:

> Date: Mon, 5 Nov 2001 22:43:32 +0100
> From: Toni Andjelkovic <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: mod_perl-1.26, threads and LWP.pm
>
> i will need to request an external URL multiple
> (several hundred) times, where each request contains
> a different "arg". then i need to process each response:
>
> http://foo/bar?arg=84375
> http://foo/bar?arg=43896
> http://foo/bar?arg=98945
> ...
>
> the problem is that i need to do this from within a
> single Apache/mod_perl process.
>
> so i'd like to spin off about 10-20 threads and let
> them handle the task concurrently by using LWP, join
> on them, collect the response data and finally send a
> summary to the client.
>
> is this possible on mod_perl-1.26 (with 5.6.1, on either
> Linux, FreeBSD or Solaris)?
>
> what are the caveats?
>
> if possible, one thread blocking for socket IO should
> not block the entire Apache/mod_perl process. will perl
> take advantage of kernel threads if the host OS supports
> them?
>
> is there anything special regarding perl/mod_perl/Apache
> compilation (besides of -Dusethreads)?
>
> should i use 5005threads ("Thread.pm") or ithreads for
> this task?
>
> is LWP considered thread-safe?
>
> thanks,

I would like to unask your many interesting questions by asking if
it's absolutely necessary that the data being returned by your
processes has to be done through an HTTP request.  If you need some
large dataset that can be had by making all these requests, could you
not package up the logic into one module to do all the requisite
queryring (or whatever) and return you one large chunk of data?  If
the HTTP interface is absolutely necessary, I'd still question whether
you could make put all your logic into something like a SOAP
interface.

ky




mod_perl-1.26, threads and LWP.pm

2001-11-05 Thread Toni Andjelkovic

i will need to request an external URL multiple
(several hundred) times, where each request contains
a different "arg". then i need to process each response:

http://foo/bar?arg=84375
http://foo/bar?arg=43896
http://foo/bar?arg=98945
...

the problem is that i need to do this from within a
single Apache/mod_perl process.

so i'd like to spin off about 10-20 threads and let
them handle the task concurrently by using LWP, join
on them, collect the response data and finally send a
summary to the client.

is this possible on mod_perl-1.26 (with 5.6.1, on either
Linux, FreeBSD or Solaris)?

what are the caveats?

if possible, one thread blocking for socket IO should
not block the entire Apache/mod_perl process. will perl
take advantage of kernel threads if the host OS supports
them?

is there anything special regarding perl/mod_perl/Apache
compilation (besides of -Dusethreads)?

should i use 5005threads ("Thread.pm") or ithreads for
this task?

is LWP considered thread-safe?

thanks,
-- 
Toni Andjelkovic
<[EMAIL PROTECTED]>




Perl Handlers and namespaces.

2001-11-05 Thread Guillaume

I ran into this problem today. I am trying to develope a small
application server with a few handlers and Apache/1.3.22 .

So I have something that looks like this set up in the apache conf file:


   
  Allow from all
   
   PerlRequire "startup.pl"
   SetHandler perl-script
   PerlHandler AppServer

   AuthName "AppServer"
   AuthType Basic
   PerlAuthenHandler AppServer::Auth
   require valid-user

   PerlAccessHandler AppServer::Access


Now, you notice that these packages are all under the same namespace.
This, somehow, causes an 'Undefined subroutine &AppServer::handler
called.' each time the server recieves a request from a client. However,
if i move the main handler into another
namespace or simply rename it to foo.pm ( and adjust the apache conf
file of course ) the error magically disappears. If one of the access
handler or authentification handler is under the same namespace as the
main handler, i always get the undefined subroutine error msg.

I'm not sure why or how apache handles this or if it's a bug or if i'm
just too tired and missed something somewhere else. I would appreciate
someone's insight on this. Is it a bug / limitation /... ?

Thanks for your time,
Guillaume




ANNOUNCEMENT: HTML::Template::Expr 0.02

2001-11-05 Thread Sam Tregar

CHANGES

- Fixed bug where numeric functions all returned 1.
  (reported by Peter Leonard)

- Improved performance over 300% with a new grammar and expression
  evaluator.

- Enhanced grammar to support call(foo > 10) syntax.


DESCRIPTION

This module provides an extension to HTML::Template which allows
expressions in the template syntax.  This is purely an addition - all
the normal HTML::Template options, syntax and behaviors will still
work.

Expression support includes comparisons, math operations, string
operations and a mechanism to allow you add your own functions at
runtime.


AVAILABILITY

This module is available on SourceForge.  Download it at:

  http://prdownloads.sourceforge.net/html-template/HTML-Template-Expr-0.02.tar.gz

The module is also available on CPAN.  You can get it using CPAN.pm or
go to:

  http://www.cpan.org/authors/id/S/SA/SAMTREGAR/


CONTACT INFO

You can join the HTML::Template mailing-list by sending a blank
message to [EMAIL PROTECTED]




SegFault report with backtrace

2001-11-05 Thread karnurme


Hello!

Here is a simple Test.pm handler that causes segfaults in our server.

The Test.pm uses XS for creating configuration settings. The purpose is to
set 'Testing' flag on or off in .htaccess files. I tried to make the
module as simple as possible.

The specifications are in the attachments files. sf_install.txt contains
the information about the mod_perl compilation and the test
module. sf_case1.txt contains the backtrace in Mandrake 8.1 with perl
5.6.1 while the sf_case2.txt contains the backtrace from Debian 2.2 with
perl 5.005_3.

To sum up the attachments, the error_log gives warnings like:
[debug] mod_perl.c(1322): [warning] PerlFixupHandler stack is not an ARRAY!
and the backtrace gives information like:
... type=0x81264d4 "SERVER_CREATE") at perl_config.c:896

The segfault problems seems to haunt me whenever I try to create new
configuration directives. In fact the different and unsolved segfaults
have made me test many combinations with different versions of linux, 
perl, apache and mod_perl during the last year. Maybe better luck with
solaris? Too bad that propably the fault lies with me.

Of course, I'm more than happy to test/give more info about the segfault
problem! Best wishes,
-- 

Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
University of Turku, Finland



CASE 2
==
Debian 2.2 (stable)
Linux aura 2.2.19pre17-compact #1 Mon Apr 2 01:35:19 PDT 2001 i586 unknown

perl -V:

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
osname=linux, osvers=2.2.15pre14, archname=i386-linux
uname='linux them 2.2.15pre14 #2 smp mon mar 13 14:29:00 est 2000 i686 unknown '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
cc='cc', optimize='-O2 ', gccversion=2.95.2 2313 (Debian GNU/Linux)
cppflags='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include'
ccflags ='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include'
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 -ldbm -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 Apr 30 2000 12:08:38
  %ENV:
PERLPREFIX="/usr/local/wm5/perl"
  @INC:
/usr/lib/perl5/5.005/i386-linux
/usr/lib/perl5/5.005
/usr/local/lib/site_perl/i386-linux
/usr/local/lib/site_perl
/usr/lib/perl5
.

BACKTRACE
=
[karnurme@sapphire apache]$ gdb /usr/local/wm5/apache/bin/httpd
(gdb) run -X -f /usr/local/wm5/apache/conf/httpd.conf -d /usr/local/wm5/apache
Starting program: /usr/local/wm5/apache/bin/httpd -X -f 
/usr/local/wm5/apache/conf/httpd.conf -d /usr/local/wm5/apache
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols 
found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols 
found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols 
found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x807dad2 in perl_get_module_ptr ()
(gdb) bt
#0  0x807dad2 in perl_get_module_ptr ()
#1  0x807ddb5 in perl_get_module_ptr ()
#2  0x807e132 in perl_cmd_perl_TAKE123 ()
#3  0x807da09 in perl_cmd_perl_FLAG ()
#4  0x8097e84 in ap_clear_module_list ()
#5  0x8098151 in ap_handle_command ()
#6  0x80981ed in ap_srm_command_loop ()
#7  0x8098a92 in ap_parse_htaccess ()
#8  0x80aa022 in ap_send_error_response ()
#9  0x80ab457 in ap_some_auth_required ()
#10 0x80ab916 in ap_process_request ()
#11 0x80a2880 in ap_child_terminate ()
#12 0x80a2a41 in ap_child_terminate ()
#13 0x80a2bbc in ap_child_terminate ()
#14 0x80a322c in ap_child_terminate ()
#15 0x80a3a5c in main ()
#16 0x400d4a42 in __libc_start_main () from /lib/libc.so.6
(gdb)

karnurme@aura:~/wm5$ less apache/logs/error_log
[Mon Nov  5 17:02:45 2001] [notice] Apache/1.3.20 (Unix) mod_perl/1.26 configured -- 
resuming normal operations
[Mon Nov  5 17:03:22 2001] [notice] child pid 12686 exit signal Segmentation fault 
(11), possible coredump in /usr/local/wm5/apache

BACKTRACE WITH NEW LIBPERL
==
cd apache_1.3.20/src/modules/perl
rm *.[oa]
make LIBPERL=libperld.a
cp libperl.a /usr/lib/perl5/5.005/i386-linux/
cd mod_perl-1.26/
make install

(gdb) run -X -f `pwd`/t/conf/httpd.c

Re: Shutdown

2001-11-05 Thread Patrick

[I'm keeping the ml in Cc: to be sure you catch it if problems, and
because other may offer same services]

On Fri, Nov 02, 2001 at 09:48:52AM -, Matt Sergeant took time to write:
> This is sad indeed. Once everything is up and running again I'll write a
> complete document of the nightmares that getting it back up again has been
> and post it to the mod_perl and axkit lists.
> 
> Meanwhile you can get there at http://217.158.50.178/ - the mailing list
> links are back to axkit.org, so you need to edit the links with the IP
> address again.
> 
> Sorry for the downtime, it's *really* not my fault. Blame NetSol, and Demon,
> and BT, and ClaraNet (get the idea yet?).

This is understandable. However I'm sure that some people may like to
host mirrors for you.
I already offered you in private email to be a secondary NS for your
domain names so that network outages have less consequences. It still
stands.

Also, if feasible, I can offer to be a web mirror (behind a 2Mb leased
line), with a local account available through ssh if you need.

Let me know privately if that interets you.
Of course it is for free, I just love mod_perl (and did not yet try
Axkit, but this sounds cool hence my offer).

Regards,
Patrick.



problems with mod_perl-1.26 and perl 5.00503

2001-11-05 Thread Silvio Wanka


Hi,

our apache web server must run on a HP-UX system, so we are not able
to switch to perl 5.6 (core dump by any %SIG access in mod_perl context).

So we use perl 5.00503 and mod_perl-1.25. Now we wont update to mod_perl-1.26
but where are some real problems:

1.  test 4 (file upload) fails in modules/cgi.t because CGI.pm uses
read("main::STDIN", ...) and main::STDIN is not defined in
mod_perl 1.26 context

2.  test 2 of internal/auth.t and the internal/dirmagic.t test
fails because the

use Apache::Constants ':common'
and
use Apache::Constants qw(DECLINED DIR_MAGIC_TYPE);

does not import the Apache constants in package name space of
My::DirIndex and Apache::AuthenTest. One solution is the attached
patch an other to use Apache::Constants::OK and so on in the handler
subroutines.

3.  CGI.pm can not proper detect that it is running in mod_perl context.
It uses the following code (it is the newest version and the warn()
calls are added by me):

# Turn on special checking for Doug MacEachern's modperl
warn "GATEWAY_INTERFACE: $ENV{'GATEWAY_INTERFACE'}\n";
if (exists $ENV{'GATEWAY_INTERFACE'}
&&
($MOD_PERL = $ENV{'GATEWAY_INTERFACE'} =~ /^CGI-Perl\//))
{
$| = 1;
require Apache;
warn "MOD_PERL: $MOD_PERL\n";
}

and 'make test' shows the following:

cp t/conf/mod_perl_srm.conf t/conf/srm.conf
/var/tmp/apache_1.3.22/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...GATEWAY_INTERFACE: CGI-Perl/1.1
MOD_PERL: 1
done
/opt/perl5/005003/hppa1.1-hp-hpux10.20/bin/perl t/TEST 0
modules/actions.ok
modules/cgi.Use of uninitialized value at ../blib/lib/CGI.pm line 153.
GATEWAY_INTERFACE:
FAILED test 4
Failed 1/5 tests, 80.00% okay
modules/constants...ok
modules/cookie..ok
modules/fileok
modules/httpdconf...ok
modules/include.ok
modules/log.ok
modules/module..skipping test on this platform
modules/perlrun.ok
modules/psections...ok
modules/request.Use of uninitialized value
at ../blib/lib/CGI.pm line 153.
GATEWAY_INTERFACE:
ok
modules/src.ok
modules/ssi.skipping test on this platform
modules/stage...skipping test on this platform
modules/status..ok
modules/symbol..ok
modules/uri.ok
modules/utilok
internal/apiok
internal/auth...ok
internal/croak..ok
internal/dirmagic...ok
internal/error..ok
internal/headersUse of uninitialized value
at ../blib/lib/CGI.pm line 153.
GATEWAY_INTERFACE:
ok
internal/hooks..ok
internal/http-get...ok
internal/http-post..ok
internal/proxy..ok
internal/redirect...Use of uninitialized value
at ../blib/lib/CGI.pm line 153.
GATEWAY_INTERFACE:
ok
internal/rwrite.ok
internal/stackedok
internal/table..ok
internal/taint..ok
Failed Test  Status Wstat Total Fail  Failed  List of failed
--
modules/cgi.t 51  20.00%  4
3 tests skipped.
httpd terminated
httpd terminated
gmake: *** [run_tests] Error 9

that means that during compile time of the test CGI scripts
GATEWAY_INTERFACE is not set. During runtime the environment
variable is set. I have also added an

warn "$ENV{'GATEWAY_INTERFACE'}, $MOD_PERL\n";

to MultipartBuffer->new, because I wont change the CGI.pm code

$IN = "main::STDIN" unless $IN;
to
$IN = $MOD_PERL ? \*STDIN : "main::STDIN"
unless $IN;

and the output in t/logs/error_log is:

CGI-Perl/1.1,

4.  the main name space is empty, so  Apache::Status does not proper
work for 'ISA Tree', 'Inheritance Tree' and 'Symbol Table Dump'.
the trees are always empty, because Devel::Symdump->inh_tree and
Devel::Symdump->isa_tree uses

grep /\bISA$/, Devel::Symdump->rnew->arrays;

and Devel::Symdump->rnew without any argument uses the 'main'
name space which is empty. This shows the output of 'Symbol
Table Dump', in mod_perl-1.25 it shows:

Embedded Perl version 5.00503 for Apache/1.3.22
(Unix) mod_perl/1.25 process 13395, 
running since Wed Oct 31 12:17:04 2001

 packages
  Access, Apache, ApacheReadConfig, AutoLoader,

RE: Are global variables truly global?

2001-11-05 Thread Matt Sergeant

> -Original Message-
> From: Chui G. Tey [mailto:[EMAIL PROTECTED]]
> 
> package Apache::MyPkg;
> 
> my $COM_instance;
> 
> sub handler {
> 
>if (!$COM_instance) {
>$COM_instance = Win32::OLE->new("ProgID.Class");
>}
> 
> }
> 
> Will the different child processes created by Apache share the same
> variable? Or will each child create an additional instance? 

It looks like you're using Win32, so you only get one process anyway - no
children, no forking. All the other suggestions apply if you intend to be
cross platform once you switch from COM to Perl objects though.

Matt.

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.



Re: Are global variables truly global?

2001-11-05 Thread Dominique Quatravaux

> I have some state data that I need to persist between requests. At the
> moment these are COM objects, but they'll be ported to Perl Classes. It
> is quite important that only one of these instances exist per web
> server. These instances are too large to write and read to file on every
> request. So I have defined the variable as a package level variable.

  Package level variables are shared upon fork(), in the sense that
the memory segment(s) they use is made available to all child
processes. BUT the memory itself isn't shared, and any subsequent
write to the variable in one of the children will not reflect in the
others. So unless your state data is a constant, this is not what you want.

-- 
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>

Dominique Quatravaux <[EMAIL PROTECTED]>