Re: SegFault report with backtrace
> > 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.
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
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
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
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
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.
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
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
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
[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
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?
> -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?
> 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]>