[ANNOUNCE] mod_perl-1.99_08
The URL
http://perl.apache.org/dist/mod_perl-1.99_08.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_08.tar.gz
size: 653469 bytes
md5: e32ef1bf6493673a83362ae2f1f1a86b
Changes since 1.99_07:
Correct ModPerl::RegistryCooker to reset %INC, after compile for .pl
files which don't declare the package + add tests to check that [Stas]
Log the real error message when Foo::Bar::sub_name fails to resolve,
because of a problem in Foo::Bar, when Foo::Bar *was* found [Stas]
Add PerlPreConnectionHandler support in Apache::Test [Stas]
Enable PerlPreConnectionHandler [Stas]
Support the Host: request header in Apache::TestClient [Stas]
restore the ModPerl::RegistryLoader::new() method for backwards
compatibility [Stas]
port the support for NameWithVirtualHost in ModPerl::RegistryCooker
and ModPerl::RegistryLoader [Stas]
fix the handling of the return status in ModPerl::RegistryCooker, add
a test to verify that [Stas]
under non-threaded perl need to check whether mod_perl is running,
when modperl_vhost_is_running check is done. [Stas]
fix $r-read to read all the requested amount of data if possible,
adjust the test TestApache::read to verify that [Stas]
fix the method content() in Apache::compat to read a whole request
body. same for ModPerl::Test::read_post. add tests. [Stas]
Adjust the reverse filter test to work on win32 (remove trailing \r)
[Randy Kobes [EMAIL PROTECTED]]
Strongly suggest win32 users to upgrade to 5.8.0, if they run 5.6.x
[Randy Kobes [EMAIL PROTECTED]]
When installing the mod_perl shared object, first need to check
whether the directory 'modules' already exists, and create it if not.
[Randy Kobes [EMAIL PROTECTED]]
Add a capability to tune the test configuration sections ordering
in Apache::TestConfigPerl [Stas Bekman]
fix the complaining code about late PerlSwitches when PerlLoadModule
is used before it [Stas Bekman]
add various tests that exercise PerlLoadModule and vhosts
[Stas Bekman]
handle correctly PerlLoadModules (directives) with vhosts:
- handle gracefully cases when things are undef/NULL
- handle the case when scfg==NULL, by stealing the base_servers's config
[Stas Bekman]
make mod_perl work with vhosts when the server is started prior to
post_config():
- call modperl_init_globals as early as possible, because the main server
record is needed during the configuration parsing, for perlloadmodule
and vhosts
- also make sure that we are using a real base_server, when dealing
with modperl_init, and if not retrieve it from the global record
[Stas Bekman]
prevent segfaults, when scfg is NULL in Apache::Module-get_config();
[Stas Bekman]
ensure that a core file is a file indeed, before complaining [Philippe
M. Chiasson [EMAIL PROTECTED]]
add $r-as_string [Geoffrey Young]
add backcompat vars: $Apache::Server::CWD and
$Apache::Server::AddPerlVersion [Stas Bekman]
env var MOD_PERL_TRACE is working again [Stas Bekman]
add a new test TestDirective::perlloadmodule2, which performs a more
evolved merging. [Stas Bekman]
fix Apache::TestConfigPerl under mod_perl 1.0, need to require
mod_perl.pm before using $mod_perl::VERSION [Geoffrey Young
[EMAIL PROTECTED]]
add an Apache::SIG backcompat stub to Apache::compat [Stas Bekman]
fix the Apache::TestConfigPerl's run_apache_test_config() function
where test packages are scanned for the magic APACHE_TEST_CONFIGURE
and if found get require()'d. Apache2 needs to be run for mod_perl
2.0. [Stas Bekman]
move the custom mod_perl 2.0 configuration bits out of the
ModPerl::TestRun, where they don't belong, into a special config file
which is included at the very end of httpd.conf [Stas Bekman]
extend Apache::Test to allow extra configuration files to be included
at the very end of httpd.conf, when everything was loaded and
configured [Stas Bekman]
resolve a segfault in Apache::Module::get_config() for the edge case
when the package name is bogus. [Stas Bekman]
Apache::Reload: add support for watching and reloading modules only in
specified sub-dirs [Harry Danilevsky [EMAIL PROTECTED]]
enable APR.pm's linking for apr 0.9.2 and higher, which uses a new lib
naming scheme, such as libapr-0.so.0.9.2, only if apr-config and
apu-config scripts exist. [Stas Bekman]
define IoTYPE_RDONLY/IoTYPE_WRONLY for perl-5.6.0 so the project
compiles again under 5.6.0 [Stas Bekman]
allow output streaming filters to append data to the end of the stream
[Stas Bekman]
fixes to compile with ActivePerl 5.8 beta
[Randy Kobes [EMAIL PROTECTED]]
fix for directive handlers within vhosts using threaded MPMs
[Stephen Clouse [EMAIL PROTECTED]]
fix IfDefine MODPERL2 support
default AuthType to Basic if not set in $r-get_basic_auth_pw()
[Philippe M. Chiasson [EMAIL PROTECTED]]
workaround glibc/Perl-5.8.0 crypt() bug (seen with threaded MPMs)
fix delete $ENV{$key} bug
fix parse_args compat method to support non-ascii characters and tr/+/ /
[Walery Studennikov [EMAIL PROTECTED]]
fix
ANNOUNCE: mod_perl-1.99_07
The URL http://perl.apache.org/dist/mod_perl-1.99_07.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_07.tar.gz size: 610901 bytes md5: e1be9ce97a9fe52564d6b436dcacb375 Changes since 1.99_05: add support for pod directives (=pod,=back,=cut) and __END__ directive [Philippe M. Chiasson [EMAIL PROTECTED]] tweaks to support Test.pm 1.21 [Philippe M. Chiasson [EMAIL PROTECTED]] add $r-add_config method to add dynamic configuration at request time add Apache::DIR_MAGIC_TYPE constant add support for directive handlers fix source_scan to run with current httpd/apr add Apache::Server-add_config method to add dynamic configuration at server startup time add Apache::Directive-to_string method add support for pluggable Perl sections fix compilation probs with get_remote_host() that had a wrong prototype [Stas Bekman] Apache::SubProcess now has a manpage [Stas Bekman] fix the Apache::SubProcess tests to work with perlio-disabled Perl [Stas Bekman] fix the filehandle leak in APR::PerlIO (both perlio-disabled and perlio-enabled Perl) [Stas Bekman] remove dup() when converting filehandles from apr_file_t to FILE* under perlio-disabled Perl (APR::PerlIO) [Stas Bekman] fix compilation if apache/apr do not have thread support --- Enjoy, -Doug
Re: [mp-1.99_05] HPUX 11 w/gcc 3.2(b) -Ae missing ... predicateerror
On Tue, 27 Aug 2002, Phil Lobbes wrote:
Hi,
I noticed in 'lib/Apache/Build.pm' that the -Ae option was being added
even if the compiler was gcc. This options causes an error something
like the following:
... missing '(' after predicate ... error
In the code below (lib/Apache/Build.pm) I removed the '#' comment from
in front of:
return if $Config{cc} eq 'gcc'; #XXX?
to work around this problem and things compiled just fine.
thanks. i've made the change in cvs.
Re: [modperl-2.0] unresolved external on win32 when compiling
On Sat, 17 Aug 2002, pascal barbedor wrote: Hi when compiling modperl 1.99_05 (from today cvs) with MP_DEBUG=1 there is un unresolved external RequestIO.obj : unresolved external symbol _times RequestIO.dll fatal LNK error this has been fixed in cvs. just s/times/PerlProc_times/g in modperl_time.h
Re: [mp-1.99_05] segfault modperl_pcw.c:52 ap_pcw_walk_files_configdconf-sec_file is NULL
On Tue, 27 Aug 2002, Phil Lobbes wrote: Hi, I just recently joined the mail list and did a quick check but didn't seen any report of this problem: Versions: perl-5.6.1 (non-threaded) apache-2.0.40(mpm-prefork) mod_perl-1.99_05 OS: HPUX 11 Compiler: gcc version 3.2 20020708 (experimental) I don't know the code well enough to know what data/values are expected to be found in dconf, but here is a possible work around (most likely less than ideal solution) in the affected portion of C code (src/modules/perl/modperl_pcw.c): +if( (! dconf) || (! dconf-sec_file) ) +return; ap_conf_vector_t **dirs = (ap_conf_vector_t **)dconf-sec_file-elts; which one is NULL dconf or dconf-sec_file? if dconf-sec_file should never be NULL. i'm not sure if it is possible for dconf itself to be NULL. do you have some example configuration that causes the problem?
Re: Weird: Perl/Perl [mp2]
On Mon, 19 Aug 2002, Alessandro Forghieri wrote: Greetings. This happens on win32. If the following is inserted in httpd.conf: Perl /Perl I get, reasonbly enough: Syntax error on line 961 of D:/Apache2/conf/httpd.conf: Perl sections not yet implemented in modperl-2.0 Tough, but fair. But why should the following: IfDefine fubar Perl /Perl /IfDefine give me the totally unreasonable: Syntax error on line 960 of D:/think4/Apache2/conf/httpd.conf: Expected /Perl but saw /Perl not sure, but likely an apache issue. anyhow, in the cvs version of modperl-2.0, pluggable Perl sections have been implemented (see posting to the dev list). somebody just needs to implement a default handler to actually convert the Perl code to apache config.
Re: Performance issue
On Tue, 20 Aug 2002, Pierre Laplante wrote: Does any body has performance data regarding mod_perl 2.0 vs mod_perl 1.0? i have not done any benchmarking, nor have i seen number from anybody else. maybe josh chamas will add 2.0 to his benchmark matrix soon? What is the stability of mod_perl 2.0? Any body using it in production? covalent has customers using mod_perl-2.0 in production with the prefork MPM without any problems.
Re: Segmentation Fault with mod_php and mod_perl
On Wed, 28 Aug 2002, Alex Lee wrote:
Stas,
I am sorry, I got too excited when I saw the segmentation fault.
Here is the output of 'bt':
Program received signal SIGSEGV, Segmentation fault.
0x75a10 in php_xbithack_handler (r=0x927840) at mod_php4.c:778
778 if (!(r-finfo.st_mode S_IXUSR)) {
99.99% sure this is largefiles related, as somebody else mentioned.
you need to make sure php was compiled with the same flags as httpd.
that is, if you built php before mod_perl, you need to recompile php so it
uses the largefile flags. or.. rebuilt modperl/httpd with Makefile.PL
PERL_USELARGEFILES=0
ANNOUNCE: mod_perl-1.99_05
The URL http://perl.apache.org/dist/mod_perl-1.99_05.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_05.tar.gz size: 577620 bytes md5: ccf3b20a1e48b42750a66c8169cd0a36 Changes since 1.99_04: fix PerlOptions +ParseHeaders to only parse once per-request add external redirects Registry tests [Stas Bekman] get rid of the compat layer in ModPerl-Registry [Stas Bekman] ModPerl::RegistryLoader is now fully operational and tested [Stas Bekman] Registry method handlers are now working [Stas Bekman] core Registry packages all compile the scripts into ModPerl::RegistryROOT:: namespace and cache them in %ModPerl::RegistryCache. Both overridable by the sub-classes. [Stas Bekman] compat tests were split into groups by functionality, send_fd test moved to compat. [Stas Bekman] added $c-get_remote_host and a compat wrapper $r-get_remote_host + tests [Stas Bekman] adjust the build system to support mod_perl build from the source tree. [Stas Bekman] ModPerl::RegistryCooker syncs with mod_perl 1.0's registry: - prototypes defined checks in flush_namespace [Yair Lenga [EMAIL PROTECTED]] - set error-notes on error [Geoff Young [EMAIL PROTECTED]] - preserve status in Registry scripts [Geoff Young [EMAIL PROTECTED]] apr_table_t is now an opaque type, use apr_table_elts() to get the array record [Stas Bekman] add support for redirects with PerlOptions +ParseHeaders backport to 2.0.35 adjust to filter register api change added APR::ThreadMutex module --- Enjoy, -Doug
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
On Sun, 30 Jun 2002, Andreas J. Koenig wrote: Program received signal SIGSEGV, Segmentation fault. 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 3097malloc.c: No such file or directory. (gdb) bt #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 #1 0x400d7f5a in __libc_free (mem=0x82fd0a8) at malloc.c:3023 #2 0x8169142 in Perl_safesysfree (where=0x82fd0a8) at util.c:151 #3 0x8197ea2 in Perl_sv_clear (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5049 hmm, looks like double free of SvPVX. if you could in gdb: (gdb) up 3 (gdb) print *sv (gdb) print *(XPV*)sv-sv_any might give a hint.
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
On Mon, 24 Jun 2002, Andreas J. Koenig wrote:
This stack trace is all I have. I cannot reproduce this SEGV at will,
so it will be difficult to obtain additional information. All I can do
is let the webserver run in -X mode and wait. I have no hints (yet)
what kind of request triggers it.
...
#6 0x820baa2 in PerlIO_cleanup (my_perl=0x82fc9c8) at perlio.c:2124
#7 0x810d298 in perl_destruct (my_perl=0x82fc9c8) at perl.c:490
#8 0x8099039 in perl_shutdown (s=0x82f140c, p=0x88f9c24) at mod_perl.c:294
#9 0x809b373 in perl_child_exit (s=0x82f140c, p=0x88f9c24) at mod_perl.c:958
#10 0x809afce in perl_child_exit_cleanup (data=0x88f9db4) at mod_perl.c:926
looks like a leaked PerlIO* from Request.xs, as this is happening when the
child is killed by apache (e.g. MaxRequestsPerChild reached).
patch below may cure, seems like a better approach in any case.
it is ugly here because the FILE was opened by an apache api function
which will close it when the request pool is cleared, so we must dup.
--- Request/Request.xs~ Sun Jan 20 09:27:35 2002
+++ Request/Request.xs Sat Jun 29 16:37:37 2002
-491,8 +491,13
ApacheUpload_fh(upload)
Apache::Upload upload
+PREINIT:
+int fd;
+
CODE:
-if ( ( RETVAL = PerlIO_importFILE(ApacheUpload_fh(upload),0) ) == NULL )
+fd = PerlLIO_dup(fileno(ApacheUpload_fh(upload)));
+
+if (!(RETVAL = PerlIO_fdopen(fd, r)))
XSRETURN_UNDEF;
OUTPUT:
-501,18 +506,9
CLEANUP:
if (ST(0) != PL_sv_undef) {
IO *io = GvIOn((GV*)SvRV(ST(0)));
- int fd = PerlIO_fileno(IoIFP(io));
- PerlIO *fp;
- fd = PerlLIO_dup(fd);
- if (!(fp = PerlIO_fdopen(fd, r))) {
- PerlLIO_close(fd);
- croak(fdopen failed!);
- }
if (upload-req-parsed)
- PerlIO_seek(fp, 0, 0);
-
- IoIFP(io) = fp;
+PerlIO_seek(IoIFP(io), 0, 0);
}
long
Re: Stuck loading startup.pl in Apache2 on WinNT
On Sat, 15 Jun 2002, Douglas McCarthy wrote: I can't get Apache2 to start with mod_perl. I could on Linux, but am having trouble on NT. The launch gets stuck in startup.pl Apache finds startup.pl but complains that it can't locate Apache.pm in INC. Trouble is, it's there. you shouldn't be trying to load Apache.pm with 2.x if something is, you must have Apache::compat loaded first which makes 'use Apache ()' a noop.
ANNOUNCE: mod_perl-1.99_03
The URL
http://perl.apache.org/dist/mod_perl-1.99_03.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_03.tar.gz
size: 391039 bytes
md5: 36f7beae83234a20217096046e3d73ff
Changes since 1.99_02:
win32 fix for the global Apache-request object to make sure it uses
the thread local storage mechanism
add a reference count mechanism to interpreters for use in threaded MPMs,
so if APR::Pool cleanups have been registered the interpreter is not
putback into the interpreter pool until all cleanups have run.
unbuffer STDERR (by turning on autoflush by default)
add support for Perl*Handler +Apache::Foo
fix open_logs,post_config,child_init hooks to run in the proper order
adjust to apr_bucket_type_t changes in 2.0.37-dev
[Mladen Turk [EMAIL PROTECTED]]
add MODPERL2 config define, as if the server had been started with -DMODPERL2
compat additions and fixes: $r-lookup_{file,uri}, $r-is_main, Apache-define
added compat for Apache::log_error [Stas Bekman]
---
Enjoy,
-Doug
Re: mod_perl2.0 / TIPool
On Thu, 13 Jun 2002, Stathy G. Touloumis wrote: Is there an idea of when the TIPool API will be available for mod_perl 2.0? probably never now that threads::shared has been implemented in perl-5.8, which can be used to provide the same functionality (i think). threads::shared came to be after writing about the Perl interface to TIPool.
RE: Perl_Tstack_sp_ptr
On Tue, 11 Jun 2002, Paul G. Weiss wrote: OK, until I can decide whether to take a chance on FreeBSD-current or to convince my employers who were so enamored of FreeBSD that we should rebuild the server with Linux, I'm going prefork. worth skimming the [EMAIL PROTECTED] archives. if the issue has already been fixed in the freebsd kernel, you'd need to upgrade from 4.5 It still doesn't work precisely as it should though. I decided to go with the cvs builds of apache and mod_perl. I have to confess that the installation instructions seem strange (both for CVS and non-CVS). You have to build and install Apache in order to get the include files to build mod_perl. Then after doing a make for mod_perl you are supposed to go back to Apache and configure, make, make-install -- even though the mod_perl make touched nothing in the Apache tree! I assume after all of this you do make install on both Apache and mod_perl although the doc doesn't say so. the docs are broken then. all you have to do is: - install perl - install apache - build modperl with: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 make test make install I suppose I could have done --enable-threads in Apache with --with-mpm=prefork and it might have worked. Is that considered kosher? maybe. but if you are using prefork, no need to build perl with -Dusethreads
Re: SEGV in bleadperl@17165 under mod_perl
On Thu, 13 Jun 2002, Andreas J. Koenig wrote:
this might be worth a try. since the segv is something stdio, must be one
of std{out,err} getting corrupted somehow. ap_error_log2stderr does
this:
API_EXPORT(void) ap_error_log2stderr(server_rec *s) {
if ( s-error_log != NULL
fileno(s-error_log) != STDERR_FILENO)
dup2(fileno(s-error_log), STDERR_FILENO);
}
no other suspects at the moment. of course, something else in your mix
could be messing with std{out,err}. strace might reveal some clues.
--- src/modules/perl/mod_perl.c~Wed May 22 21:23:18 2002
+++ src/modules/perl/mod_perl.c Thu Jun 13 10:24:59 2002
-1454,7 +1454,7
#endif
/* hookup stderr to error_log */
-#ifndef PERL_TRACE
+#if 0
if(r-server-error_log)
error_log2stderr(r-server);
#endif
Re: SEGV in bleadperl@17165 under mod_perl
On Thu, 13 Jun 2002, Andreas J. Koenig wrote: Program received signal SIGSEGV, Segmentation fault. 0x400ed761 in _IO_fflush (fp=0x877f1e0) at iofflush.c:43 43 iofflush.c: No such file or directory. (gdb) bt #0 0x400ed761 in _IO_fflush (fp=0x877f1e0) at iofflush.c:43 also, if possible could you: (gdb) p *fp
Re: SEGV in bleadperl@17165 under mod_perl
seems to be an Apache::Request issue with perlio. i can get a similar
segv with the modperl test change below.
system() triggers a PERL_FLUSHALL_FOR_CHILD; with the Apache::Upload
filehandles still alive. there is some ugly code to import the FILE* from
ApacheUpload_fh to a PerlIO, which could be the culprit.
is there any way to flag a PerlIO to not be flushed during
PerlIO_flush(NULL) ?
--- t/net/perl/request-upload.pl~ Thu Dec 30 11:51:16 1999
+++ t/net/perl/request-upload.plThu Jun 13 14:31:37 2002
-28,7 +28,8
my $name = $upload-name;
my $type = $upload-type;
next unless $filename;
-
+local $ENV{PATH} = '/bin';
+system /bin/echo $filename /tmp/uploads;
print $name $filename ($type);
if ($fh and $name) {
no strict;
Re: SEGV in bleadperl@17165 under mod_perl
also note that the problem goes away if PERL_FLUSHALL_FOR_CHILD happens
after the Apache::Upload handles have gone out of scope. the change below
does not trigger and segvs, all tests pass. andreas, you could try to
make sure your Apache::Upload handles have gone out of scope (or are
undef-ed) before calling Mail::Mailer. also make sure you are using
the 1.0 version of libapreq, i think older versions leaked filehandles.
--- t/net/perl/request-upload.pl~ Thu Dec 30 11:51:16 1999
+++ t/net/perl/request-upload.plThu Jun 13 14:41:51 2002
-107,3 +107,5
print $filename bytes=$bytes,wanted=$wanted\n;
}
+local $ENV{PATH} = '/bin';
+system /bin/echo ok /tmp/uploads;
Re: SEGV in bleadperl@17165 under mod_perl
patch below also cures (when calling system() with Apache::Upload handles still alive). seems PerlIO_importFILE() should have a mode argument, in this case we only want to allow reading on the given FILE* --- Request/Request.xs~ Sun Jan 20 09:27:35 2002 +++ Request/Request.xs Thu Jun 13 15:07:28 2002 -38,6 +38,7 #undef __attribute__ #include mod_perl.h +#include perliol.h #ifdef WIN32 -494,6 +495,7 CODE: if ( ( RETVAL = PerlIO_importFILE(ApacheUpload_fh(upload),0) ) == NULL ) XSRETURN_UNDEF; +PerlIOBase((PerlIO*)RETVAL)-flags = ~PERLIO_F_CANWRITE; OUTPUT: RETVAL
Re: Apache Error Log
On Wed, 12 Jun 2002, Jaberwocky wrote: No, all I really want to do is print to STDERR you can use warn() instead which writes to stderr and always autoflushes. or turn on autoflush of STDERR yourself, from perlfunc.pod: $oldfh = select(STDERR); $| = 1; select($oldfh); or update modperl-2.0 from cvs which turns on autoflush of STDERR by default.
RE: Perl_Tstack_sp_ptr
On Tue, 11 Jun 2002, Paul G. Weiss wrote:
I had already thought of that. Strace shows that the
correct libperl.so is the one that is being loaded. Just
to make sure I deleted all others and did
ln -s /usr/lib/perl5/5.6.1/i386-freebsd-thread-multi/CORE /usr/lib
but strace tells me that it is still directly loading the correct
one, probably because of the
-Wl,-R/usr/lib/perl5/5.6.1/i386-freebsd-thread-multi/CORE
used in linking mod_perl.so.
ok.
That being said I tried the LoadFile directive as you suggested.
This indeed lets the system start, but now it can serve no
pages ( not even static ones ). This is true even when all
mod_perl configuration directive are removed from the conf
file (except the LoadFile and the LoadModule).
However, when I do httpd -X, it
works - I can even serve mod_perl content. But regular httpd
just hangs. The strace output of an httpd process shows this:
accept(5, {sin_family=AF_INET6, sin6_port=htons(1303), inet_pton(AF_INET6,
:::65.204.1.133, sin6_addr), sin6_flowinfo=0}, [28]) = 20
could this be a version of freebsd with broken threads support? i've
heard many cases of that. chances are if you rebuild perl without
-Dusethreads and apache with the prefork mpm, this problem won't be there.
Re: mod_perl 1.99-02 cgi_header_out
On Mon, 10 Jun 2002, John Bass wrote:
Hello,
Does anyone have a solution for the cgi_header_out function within
mod_perl 2.
I have found it is used by Apache:Session, and would like to use this
module.
i was going to ask, why on earth would Apache::Session use cgi_header_out,
but then i downloaded 1.54 and see that it does not. what version are you
using? you will need to have 'PerlModule Apache::compat' configured for
the header_{in,out} methods.
RE: Perl_Tstack_sp_ptr
On Tue, 11 Jun 2002, Paul G. Weiss wrote: I suspect that pre-fork would work too, but I'm desparately trying to get threads working. you should try a different os then. i'm sitting next to the guy who wrote worker mpm, he says the freebsd thread library does not work well enough for use with apache. which is why the apache configure is supposed to force disabling of threads on freebsd (which is what i saw), not sure how you were able to end up with APR_HAVE_THREADS 1. there is more in the [EMAIL PROTECTED] mail archive on this subject.
Re: SEGV in bleadperl@17165 under mod_perl
On Tue, 11 Jun 2002, Andreas J. Koenig wrote: PAUSE is suffering from a SEGV since I installed RC1. After I upgraded yesterday to snapshot 17165 I finally caught the following within gdb. I'd appreciate further instructions where to go from here. test case? #4 0x816fc96 in Perl_my_popen (my_perl=0x82ffcc8, cmd=0x8a073f1 -, mode=0xb828 w) at util.c:2080 looks like something along the lines of: open my $foo, '|-' or ...; ?
Re: PATCH modperl_bucket.c
On Tue, 4 Jun 2002, Mladen Turk wrote: Hi, Enables compilation witch current CVS. fix applied to cvs, thanks.
Re: eating memory ... // RE: Porting to OS X
On Wed, 5 Jun 2002, Alvar Freude wrote: probably it's the same as on FreeBSD: if you use a DSO mod_perl, for each restart (apachectl graceful or apachectl restart) it eats all the memory your mod_perl modules use. Try to build it statically; at least on FreeBSD it helps, and OSX is FreeBSD ... :-) But my newest test was with Apache 1.3.23 and mod_perl 1.26; perhaps it's fixed in 1.27?!? dso should be fine with 1.26 or 1.27, provided you are using Perl 5.6.1 or higher. 5.005_03 still has leakage.
ANNOUNCE: mod_perl-1.27
The URL
http://perl.apache.org/dist/mod_perl-1.27.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.27.tar.gz
size: 372525 bytes
md5: bd07f4f1065eb0d0a8d8004219357d8c
Changes since 1.26:
workaround Cwd bug in 5.8.0-RC1 that breaks apache configuration on solaris
fix get_set_PVp() to properly set NULL values when passing in undef
thanks to Lyle Brooks for the spot
[Stephen Clouse [EMAIL PROTECTED]]
Apache::Registry/PerlRun/RegistryNG errors are now saved
in $r-notes('error-notes')
[Jesse Erlbaum [EMAIL PROTECTED]]
fix Win32 build problems with spaces in shell arguments
[Randy Kobes [EMAIL PROTECTED]]
make sure DynaLoader is loaded before XSLoader to workaround possible
segv when using mod_perl as a dso with perl 5.6.1
autoset PERL_USELARGEFILES=0 if needed
fix taint issues with bleedperl
fix bug in modules/util test
[Tatsuhiko Miyagawa [EMAIL PROTECTED]]
Adjust the mailling list addresses
's|\@apache\.org|\@perl.apache.org|' [Stas Bekman [EMAIL PROTECTED]]
Apache::PerlRun will now localize $SIG{__{DIE,WARN}__}
thanks to Jon Coulter for the spot
PERL5LIB support now properly unshifts paths into @INC rather than push
[Tatsuhiko Miyagawa [EMAIL PROTECTED]]
do not clear symbol tables within a package in perl_clear_symtab()
used by directive handler extensions
[Stephen Clouse [EMAIL PROTECTED]]
properly deal with $r-status codes (e.g. redirect) in
Apache::RegistryNG [Geoff Young [EMAIL PROTECTED]]
allow $r-auth_name and $r-auth_type to be set on win32
[John Kelly [EMAIL PROTECTED]]
fix compilation for win32 w/ apache 1.3.22+
[Randy Kobes [EMAIL PROTECTED]]
fix multiple %LocationMatch in Perl sections bug
[Salvador Ortiz Garcia [EMAIL PROTECTED]]
rip -D_GNU_SOURCE out of Perl 5.7.3+'s ccflags, which modperl doesn't
need and apache won't compile with [Stas Bekman [EMAIL PROTECTED]]
make sure PerlSetEnv variables are visible after first access
to each child [Geoff Young [EMAIL PROTECTED]]
workaround Apache::Constants::AUTOLOAD problem with bleedperl
the first flag argument to perl cannot start with space, since perl tries
to open the -spi.bak as a file. fix that in the win32 case.
[Stas Bekman [EMAIL PROTECTED]]
starting from perl 5.7.3 for tied filehandles, tiedscalar magic is applied
to the IO slot of the GP rather than the GV itself. adjust the TIEHANDLE
macro to work properly under 5.7.3+. [Charles Jardine [EMAIL PROTECTED],
Stas Bekman [EMAIL PROTECTED]]
added perl_perl_merge_dir_config and array_header2avrv symbols to
mod_perl.def for win32 and mod_perl.exp for aix.
[Randy Kobes [EMAIL PROTECTED]]
INSTALL.apaci: added an explanation of how perl has to be built in
order to use DSO without problems (copied from the guide) based on
email from Doug. [Stas Bekman [EMAIL PROTECTED]]
warn if Perl is configured with -Duseshrplib and a libperl.so is found
in a place where it should not be, example: /lib /usr/lib or /usr/local/lib
fix potential segv in Apache::URI-rpath
[Vyacheslav Zamyatin [EMAIL PROTECTED]]
require URI::URL to work with newer libwww-perl
allow overriding of container directive handlers using the func parameter
[Geoffrey Young [EMAIL PROTECTED]]
enable directive handler support for TAKE13
[Geoffrey Young [EMAIL PROTECTED]]
---
Enjoy,
-Doug
ANNOUNCE: mod_perl-1.99_02
The URL
http://perl.apache.org/dist/mod_perl-1.99_02.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_02.tar.gz
size: 378436 bytes
md5: b08c12adc1a8ae4ce7a111f8d5fe0b43
Changes since 1.99_02:
pass the PATH and TZ environment variables at startup by default as 1.xx did
fix ModPerl::Util::exit segv with 5.6.0
no longer support 5.7.x perl development versions
added compat for Apache::Table-new
various fixes to compile/run on darwin
server-scope Perl{Set,Pass}Env config now propagated to %ENV at startup
use SvOK(sv) instead of sv == PL_sv_undef to detect undef values in xs
[Stephen Clouse [EMAIL PROTECTED]]
complete Apache::Util 1.x compat
added Apache::MPM_IS_THREADED constant
added compat function for Apache::Constants::SERVER_VERSION
added Apache::Constants::export stub for compat
added noop stubs for timeout functions removed from 2.0:
$r-{soft,hard,reset,kill}_timeout
turned on PerlOptions +GlobalRequest by default for perl-script handler
unless it is explicitly turned off with PerlOptions -GlobalRequest
added APR::OS::thread_current function
added support for 1.x $r-subprocess_env functionality
added support for $r-push_handlers(PerlHandler = ...)
added support for $r-proxyreq to detect proxy requests
$r-content_type($val) now calls ap_set_content_type underneath
add the err_header_out() wrapper to Apache::compat + corresponding tests
[Stas Bekman]
fix $r-dir_config lookup of values set in the server context
added Apache::REDIRECT shortcut constant
various fixes for method handlers
use Apache::ServerUtil in Apache::compat so Apache-server works in compat
mode [Dave Rolsky [EMAIL PROTECTED]]
add Apache::Util::unescape_uri alias to Apache::unescape_url in Apache::compat
change Apache::unescape_url to return the escaped url as 1.x does
disabled term coloring by default (enable with env var APACHE_TEST_COLOR=1)
fix for APR::IpSubnet-new to check return status apr_ipsubnet_create
enabled APR::SockAddr module
turn on binmode for filehandle used in $r-send_fd
get MP_{TRACE,DEBUG} Makefile.PL options working on win32
various fixes to build/run with bleedperl
various fixes for win32 to get make test passing
moved constuct_{url,server} methods to Apache::URI module
implement Apache::URI::parse in Apache::compat
give Perl*Handlers precedence over other handlers by using APR_HOOK_FIRST
rather than APR_HOOK_LAST
workaround bug in 5.6.1 when XSLoader loads DynaLoader, wiping out any
dl handles it had been keeping track of.
tidy up test to run standalone (without modperl test config)
[Stas Bekman]
override T_PTROBJ INPUT typemap to croak if object is not a blessed
reference, to prevent possible segv from e.g. Apache::Server-process
apr_lock.h is gone; disable APR::Lock for the moment
enabled the Apache::Process module
fix ModPerl::Util::exit to clear $@ before calling Perl_croak
cut down on some build noise
fix 'PerlOptions +GlobalRequest' when used within subrequests
get rid of some subroutine redefined warnings in ModPerl::MM that
show up with newer bleedperls.
a few fixes for Apache::compat [Dave Rolsky [EMAIL PROTECTED]]
---
Enjoy,
-Doug
Re: Patch to mod_perl 1.26: error-notes support
On Tue, 28 May 2002, Geoffrey Young wrote: Doug MacEachern wrote: thanks, i've applied a variation of your patch to cvs and will be in 1.27 if anybody wants to work up a similar patch for Apache::PerlRun, that'd be nice too. this seems to work ok as PerlRun and RegistryNG. looks good, +1. thanks.
Re: DBI modperl_2 Segmentation fault
On Fri, 24 May 2002, Udlei Nattis wrote: hi i updating modperl-2.0-cvs and problem persist now i change DynaLoader in DBI.pm to XSLoader but problem persist :( you shouldn't need to change DBI.pm the output of perl build/config.pl (normally should use t/REPORT) might help. and your DBI version.
Re: DBI modperl_2 Segmentation fault
sounds like the XSLoader vs. DynaLoader issue which only exists in 5.6.x. try updating modperl-2.0-cvs, there is a better workaround in there for the issue now.
Re: compatibility problem
On Fri, 24 May 2002, Jie Gao wrote: Segmentation fault happens when accessing /export/softwares/data, a subdirectory which does not have an .htaccess file itself, but a subdirectory of which has an .htaccess file containing: hmm. you might want to try building modperl with MP_DEBUG=1 and configure 'PerlTrace all' in httpd.conf which might give some clues to what the problem is.
Re: What causes memory leaks during graceful restarts?
On Wed, 22 May 2002, Dan Wilga wrote: Interesting. When I do that, I get the same problem I did when I tried to run with 1.25_01 and 1.26: Apache core dumps. I think I'll have to try compiling it again with the latest version of mod_perl, and perhaps not as a DSO. possible that your are hitting the XSLoader vs. DynaLoader problem, where the list of dlhandles can be wiped out. try adding 'use DynaLoader ();' to your startup.pl before any other module is loaded.
Re: #perl SSI directive not recognised
On Wed, 22 May 2002, Alan Burlison wrote:
Thanks Doug. I'm using the Apache/perl/mod_perl that will ship as part of
Solaris 9, so I was a little concerned that we'd screwed something up :-)
maybe solaris 9 should include 2.0 instead ;-)
From your description, I'm guessing that the root cause of this that that
two dlopen'ed shared objects need to be able to cross-call each other,
correct?
right.
This might not be of much use if you already have a fix for 2.0,
but I have a little trick which makes this work on Solaris, at least. You
stick the following in the call to WriteMakefile in Makefile.PL
dynamic_lib = { OTHERLDFLAGS =
'-h $(DLBASE).$(DLEXT) ' .
'-R\$$ORIGIN/.. $(INST_ARCHAUTODIR)/../OtherModule.so'
},
interesting trick. probably won't attempt it for modperl-1.27 tho, since
it likely won't work on some platforms and the #perl include feature isn't
very high demand.
Re: #perl SSI directive not recognised
On Wed, 22 May 2002, Alan Burlison wrote: I have another little problem I'm trying solve, which will be really neat if I can get it to work. You may or may not know that Solaris has a fair share scheduler, which means you can limit the total proportion of CPU that a particular user can use. nice. I want Apache to switch into a resource-managed Project at startup, but to do so I need to find out the value of the User parameter in httpd.conf, and I can't find a way to do this - is there one? Apache::Server::uid returns the uid of the configured User. you can access via: Apache-server-uid at startup time or $r-server-uid at request time
Re: What causes memory leaks during graceful restarts?
On Wed, 22 May 2002, Dan Wilga wrote:
Oh ho! That's it. Now when I gracefully restart, the memory loss is
only about 29 Kb -- a very reasonable number.
much better. with the modperl test suite, i only see a wee bit of leakage
on the first restart, then no leakage on restarts after that.
So if that's the reason for the core dump, is there a bug fix to the
offending module in the works?
it is fixed in 5.8.0-tobe with the patch below, which can also be applied
to 5.6.1
Index: ext/DynaLoader/DynaLoader_pm.PL
===
RCS file:
/usr/local/cvs_repository/perl-current-mirror/ext/DynaLoader/DynaLoader_pm.PL,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 DynaLoader_pm.PL
--- ext/DynaLoader/DynaLoader_pm.PL 2001/01/04 01:55:35 1.1.1.1
+++ ext/DynaLoader/DynaLoader_pm.PL 2001/06/19 05:10:22
-80,8 +80,10
dl_require_symbols = (); # names of symbols we need
dl_resolve_using = (); # names of files to link with
dl_library_path= (); # path to look for files
-@dl_librefs = (); # things we have loaded
-@dl_modules = (); # Modules we have loaded
+
+#XSLoader.pm may have added elements before we were required
+#@dl_librefs = (); # things we have loaded
+#@dl_modules = (); # Modules we have loaded
# This is a fix to support DLD's unfortunate desire to relink -lc
dl_resolve_using = dl_findfile('-lc') if $dlsrc eq dl_dld.xs;
Re: Cannot build mod_perl 2 on Win32: Linking problems
On Thu, 23 May 2002, Joe Yates wrote: Perl/v5.7.3 what does your perl -V say ? never tried the released version of 5.7.3 on win32, but i've been rsync-ing perl-current which compiles/links and passes all test. rsync.exe -auvz --delete rsync://ftp.linux.activestate.com/perl-current/ perl-current
Re: Patch to mod_perl 1.26: error-notes support
thanks, i've applied a variation of your patch to cvs and will be in 1.27
if anybody wants to work up a similar patch for Apache::PerlRun, that'd be
nice too.
On Fri, 12 Apr 2002, Jesse Erlbaum wrote:
Hello Doug All --
One of my programmers (Dave Kaufman) brought to my attention a small but
useful feature which is present in mod_cgi, but missing from
Apache::Registry. When running via mod_cgi, if execution of a CGI
application fails, an error message will be propagated to an environment
variable, ERROR_NOTES. This environment variable can be used by a custom
ErrorDocument to assist in quality assurance.
This variable is actually propagated, by http_request.c (confirmed in Apache
1.3.20), from an Apache note whose key is error-notes. A number of
Apache handlers use the error-notes attribute to pass along human-readable
exception data.
Following is a patch I wrote (against mod_perl 1.26, Apache::Registry
version 2.01) which causes Apache::Registry to participate in this scheme.
I hope you find it sufficiently useful to include in the next version of
mod_perl.
Warmest regards,
-Jesse-
START PATCH
diff -c -r1.1 Registry.pm
*** modules/i686-linux/Apache/Registry.pm 13 Mar 2002 18:06:34 -
1.1
--- modules/i686-linux/Apache/Registry.pm 22 Mar 2002 22:19:10 -
***
*** 129,134
--- 129,135
if ($@) {
$r-log_error($@);
$@{$uri} = $@;
+ $r-notes('error-notes', $@);
return SERVER_ERROR unless $Debug $Debug 2;
return Apache::Debug::dump($r, SERVER_ERROR);
}
***
*** 153,158
--- 154,160
if($errsv) {
$r-log_error($errsv);
+ $r-notes('error-notes', $errsv);
return SERVER_ERROR unless $Debug $Debug 2;
return Apache::Debug::dump($r, SERVER_ERROR);
}
END PATCH
Jesse Erlbaum, CTO
Vanguard Media
http://www.vm.com
212.242.5317 x115
[EMAIL PROTECTED]
Re: compatibility problem
On Thu, 23 May 2002, Jie Gao wrote: and make test says BAD_GATEWAY is not exported by Apache::Constants. are you actually using that constant? i only was using it as an example. Also perl-status doesn't seem to be functioning: Apache::Status doesn't work with 2.0 yet. I am also getting: [Thu May 23 14:11:45 2002] [notice] child pid 32213 exit signal Segmentation fault (11) when running my 1.3 module. I couldn't find any coredump, though. Anyone can help? modperl-1.xx/SUPPORT: % gdb ../apache_x.xx/src/httpd (gdb) run -X -f `pwd`/t/conf/httpd.conf -d `pwd`/t [now make request that causes core dump] (gdb) bt
Re: compatibility problem
On Wed, 22 May 2002, Doug MacEachern wrote: On Thu, 23 May 2002, Jie Gao wrote: and make test says BAD_GATEWAY is not exported by Apache::Constants. are you actually using that constant? i only was using it as an example. if you are, you need to change it to HTTP_BAD_GATEWAY. one caveat for 1.x compat, not all of the Apache::Constants are in EXPORT/EXPORT_OK in 1.x. reason is because Exporter.pm is such a memory hog, we tried to limit the number of exports. this particular HTTP_ constant is one that was left out of the default list. it is however available if you export it in 1.x. to do this you need to call: Apache::Constants-export(qw(HTTP_BAD_GATEWAY)); i just added a stub to Apache::compat to provide that method (which does nothing). all constants are available for import in 2.0 since we no longer use Exporter.pm
Re: compatibility problem
On Wed, 22 May 2002, Doug MacEachern wrote: Apache::Status doesn't work with 2.0 yet. actually, it kinda does after added SERVER_VERSION to Apache::compat. Enabled mod_perl Hooks does not work, nor does Compiled Registry Scripts, but everything else seems to.
Re: DSO on Solaris - child dies with seg fault
On Sun, 14 Apr 2002, Sreeji K Das wrote: Hi Stas, Thanx for the reply. However, I had already read the doc. and done everything mentioned there. I had recompiled perl with -Ubincompat5005 as mentioned. wondering if this is the XSLoader vs DynaLoader mentioned earlier today. there is a workaround builtin to 1.27-tobe: http://perl.apache.org/~dougm/mod_perl-1.26_01-dev.tar.gz you could also try 'use DynaLoader ();' before loading any other modules.
Re: compatibility problem
On Thu, 23 May 2002, Jie Gao wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 15349)]
0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134
134 if (!symbol-hash) {
(gdb) bt
#0 0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134
#1 0x403103ed in modperl_callback (handler=0x83dcd68, p=0x83d3438, r=0x83d3470,
s=0x80d1540, args=0x8131110)
at modperl_callback.c:19
this is with modperl-2.0 from cvs? if you have a simple test case to
reproduce, that would help. looks related to method handlers based on
your stacktrace.
Re: What causes memory leaks during graceful restarts?
what version of perl? what modperl Makefile.PL options? if you're using modperl as a dso, you'll need at least perl 5.6.1 and modperl-1.26 to prevent this leakage on restarts.
Re: What causes memory leaks during graceful restarts?
On Tue, 21 May 2002, Dan Wilga wrote: I am using Perl 5.6.1, modperl 1.25, and yes it's a DSO. It's compiled with: with 1.25, you can also set the PERL_DESTRUCT_LEVEL environment variable to 2, either before starting the server: export PERL_DESTRUCT_LEVEL=2 apachectl start or using PerlSetEnv in httpd.conf the fix in modperl-1.26 is simply to use that value by default.
RE: mod_perl2: nmake test crashes apache
On Tue, 21 May 2002, Alessandro Forghieri wrote: The execution order turns out to be: 1+2 and *then* 3. It looks like a thread is allocated to this (client,handler) pair, so Frame 1 and 3 are running in the same thread, separate from the thread that's running 2. there should never be multiple requests being served concurrently by the same thread. if this is happening, this is a major bug in the winnt mpm. the same thread may handle request #1, then #3 when it is done serving #1, but not both at the same time.
Re: #perl SSI directive not recognised
the #perl directive is disabled if modperl is built as dso, Makefile.PL prints a message about this. won't be an issue with 2.0 thanks to apr optional functions. but in 1.x, the modperl .so cannot resolve symbols from mod_include.so. at least, it can't on all platforms and can't if one were to disable LoadModule of mod_include.so
Re: problems on OS X
On Sun, 28 Apr 2002, Ken Williams wrote: Insecure dependency in eval while running with -T switch. Callback called exit. this has been fixed in modperl cvs, just remove the 'use ExtUtils::testlib;' line in t/docs/startup.pl
Re: Memory Leaks
On Mon, 20 May 2002, Perrin Harkins wrote: Apache::SizeLimit or Apache::GTopLimit is a better way to do it, since it results in fewer unnecessary restarts. However, it's still a good idea to restart periodically, because some of the shared memory seems to become unshared over time no matter what you do, and restarting fixes that. that reminds me, i wrote a c version of Apache::GTopLimit 2+ years ago (at somepoint in the 5 months i worked at backflip.com), but never released it. if somebody wants to maintain/release it, the package is here: http://perl.apache.org/~dougm/mod_gtop-0.02.tar.gz
Re: How to configure mod_perl to get Connection.so, Connection.bsand so on...
On Sat, 27 Apr 2002, sagar wrote: Hi I have installed apache-1.3.12, openssl-0.9.5a and apache-1.3.12+ssl- 1.40 and configured mod_perl-1.26 on freeBSD 4.1 with apache by giving the following: %perl Makefile.PL APACHE_SRC=../apache_1.3.12/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/apache ... But, the following directories with their relevant files ( .so, .bs files ) have not been created in the above path modperl links those modules static so there won't be any .so's, unless you build with DYNAMIC=1
Re: [modperl2] Note on the win32 docs
On Mon, 20 May 2002, Peter Rothermel wrote:
I've run into a problem with mod_perl configuration instructions
with for Registry scripts. I've built mod_perl and copied the
blib directly under my Apache2 (server root) directory.
sounds like a bug that has been fixed in cvs. try the cvs version or wait
for _02 or try the patch below.
Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 13 Nov 2001 04:34:31 -
1.5
+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 16 Apr 2002 17:14:16 -
+ 1.6
-42,10 +42,11
# httpd.conf with:
# PerlSetVar ModPerl::RegistryCooker::DEBUG 4
use Apache::ServerUtil ();
-use constant DEBUG =
-defined Apache-server-dir_config('ModPerl::RegistryCooker::DEBUG')
-? Apache-server-dir_config('ModPerl::RegistryCooker::DEBUG')
-: D_NONE;
+use constant DEBUG = 0;
+#XXX: below currently crashes the server on win32
+#defined Apache-server-dir_config('ModPerl::RegistryCooker::DEBUG')
+#? Apache-server-dir_config('ModPerl::RegistryCooker::DEBUG')
+#: D_NONE;
#
# object's array index's access constants
Re: Help with Method Handlers in mod_perl 1.99
On Fri, 3 May 2002, Peter Rothermel wrote: I tried the mehod attribute and now I get this error: Error message: Can't locate object method via package Apache::AuthDerivedHandler. method handlers were broken in _01, this has been fixed in cvs and will be in 1.99_02
RE: mod_perl2: nmake test crashes apache
On Tue, 14 May 2002, Alessandro Forghieri wrote: ii) It does however crash on my testbed app (which runs as standard CGI, FastCGI and moperl1). The crash itself appears to happen when a number of nearly-simultaneous requests arrive to the server and is fatal to modperl (but the static-serving part of apache appears to survive) do you have a simple test case to reproduce the problem? iib) I then set out to build a debug version. That ain't easy I finally this has been fixed in cvs, MP_DEBUG=1 should do the right things now.
Re: make test problem
On Mon, 20 May 2002, Jie Gao wrote: Just got one from cvs and 'make test' hangs on apr/util: ... apr/util likely the call to APR::generate_random_bytes, could be blocking on /dev/random or similar (strace would tell you). i've disabled the test in cvs for the moment, as i've seen problems with it in the past on other platforms (hpux).
Re: Seg fault on apache start
On Sat, 18 May 2002, Jaberwocky wrote: I'm having some problems with this. Apache seg faults on the call to parse... .. #1 0x80c5ad8 in XML_GetBuffer () did you build apache with --disable-rule=EXPAT ?
Re: [modperl2] Note on the win32 docs
On Mon, 20 May 2002, Peter Rothermel wrote: Thanks for the info. Latest from cvs works fine. Any idea how close _02 might be to release? hopefully in a day or three.
Re: mod_perl 2.0 - writing a proxy handler
On Tue, 14 May 2002, Douglas Younger wrote:
Hello,
Has anyone written a proxy handler in 2.0 similar to example 7-12 of the
O`Reilly book? I've tried converting it without much luck. I don't need the
add-blocker stuff, just a generic proxy handle that I can add some
additional lines to parse the output.
you'll need modperl from cvs (or wait for _02) for $r-proxyreq to
auto-detect a proxy request. with modperl-cvs and Apache::compat loaded,
i have run Apache::AdBlocker without any modperl api changes. however, i
did need the patch below because my GD install does have gif support.
--- lib/Apache/AdBlocker.pm~Fri Mar 3 21:08:35 2000
+++ lib/Apache/AdBlocker.pm Mon May 20 17:31:22 2002
-61,7 +61,7
my $content = \$response-content;
if($r-content_type =~ /^image/ and $r-uri =~ /\b($Ad)\b/i) {
block_ad($content);
- $r-content_type(image/gif);
+ $r-content_type(image/png);
}
$r-content_type('text/html') unless $$content;
-85,7 +85,7
$im-string(GD::gdLargeFont(),5,5,Blocked Ad,$red);
$im-rectangle(0,0,$x-1,$y-1,$black);
-$$data = $im-gif;
+$$data = $im-png;
}
1;
Re: compatibility problem
On Fri, 17 May 2002, Jie Gao wrote: use Apache::Constants qw(:common :response M_GET M_POST AUTH_REQUIRED REDIRECT); the :response group in 1.x consists of names which apache has deprecated in 1.3.x and removed in 2.0, for which there are HTTP_* names that replace the old names. so for example, if you had imported the :response group to use 'BAD_GATEWAY', you should instead explicity import HTTP_BAD_GATEWAY, which will work with both 1.x and 2.x. If I take out response, it croaks at REDIRECT. i've added REDIRECT to the list of shortcut names which apache had deprecated, but are common/handy enough to carry forward with modperl. the full list of shortcut names supported in modperl2 that are deprecated in apache (in favor of the long-winded HTTP_ names): NOT_FOUND(HTTP_NOT_FOUND) FORBIDDEN(HTTP_FORBIDDEN) AUTH_REQUIRED(HTTP_UNAUTHORIZED) SERVER_ERROR (HTTP_INTERNAL_SERVER_ERROR) REDIRECT (HTTP_MOVED_TEMPORARILY)
Re: make test problem
On Mon, 20 May 2002, Jie Gao wrote: I've found Apache 2.0.36 doesn't work with mod_perl-1.99_01 on redhat 7.1. you can use modperl from cvs with .36 or wait for modperl 1.99_02 (sometime this week). With apache 2.0.35, I'm getting: ... Cannot load /usr/local/apache2/modules/mod_rewrite.so into server: /usr/local/apache2/modules/mod_rewrite.so: undefined symbol: apr_group_name_get looks like mod_rewrite that was compiled with .36 is still in the .35 install tree.
RE: mod_perl2: nmake test crashes apache
On Mon, 13 May 2002, Alessandro Forghieri wrote:
There is a residual crash at dir_config.t (WinNT SP6 - MS Visual
Studio 6 SP3).
all tests pass for me with both 5.6.1 and bleedperl, httpd-2.0 from cvs on
xp with msdev 6.0. i also tried 5.6.1 with no debug symbols, still all
pass. would help to know which test causes the crash. you could try
turning on autoflush in the test (patch below), start the server with
't/TEST -start' and run it through a browser by opening:
http://localhost:8529/TestModperl::dir_config
Index: t/response/TestModperl/dir_config.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestModperl/dir_config.pm,v
retrieving revision 1.3
diff -u -r1.3 dir_config.pm
--- t/response/TestModperl/dir_config.pm11 Apr 2002 11:08:44 - 1.3
+++ t/response/TestModperl/dir_config.pm13 May 2002 16:27:03 -
-16,6 +16,8
sub handler {
my $r = shift;
+$| = 1;
+
plan $r, tests = 12;
#Apache::RequestRec::dir_config tests
Re: cannot build mod_perl-1.99_01 with httpd-2.0.36
On Sat, 11 May 2002, Tom Kralidis wrote: % perl Makefile.PL MP_AP_PREFIX=/usr/local/src/apache/httpd-2.0.36 MP_AP_PREFIX needs to be a directory where apache is installed, not the source tree. when apache is installed it puts all headers into the installed include/ directory.
Re: mod_perl2: nmake test crashes apache
On Mon, 13 May 2002, Alessandro Forghieri wrote: I think apache may be (sometimes?) picking up whatever mod_perl.so is under SERVER_ROOT/modules during the test run. this is fixed in cvs now. So, disregard my previous message, my failed line is now: as is this.
Re: cannot build mod_perl-1.99_01 with httpd-2.0.36
On Mon, 13 May 2002, Tom Kralidis wrote: modperl_apache_includes.h:46:22: apr_lock.h: No such file or directory oh right, 1.99_01 will not compile with 2.0.36, since apr_lock.h has been removed from apache. you can use modperl from cvs or wait for 1.99_02, which should be released soon-ish. ...I have no apr_lock.h in /www/includes. Do I need libapreq? If so, that install does not work either: no, the current release of libapreq does not compile with apache 2.0
RE: [modperl2] Note on the win32 docs
On Fri, 10 May 2002, Randy Kobes wrote: You're right - PerlSendHeader On should be there ... I'll modify the draft accordingly. Thanks. actually, the 2.0 config is: PerlOptions +ParseHeaders PerlSendHeader On is just alias of that for backwards compat.
Re: mod_perl2: nmake test crashes apache
the issue with all segfaults on win32 is related to the use of the internal perl variable PL_sv_no. not sure what the real problem is, but avoiding use of PL_sv_no has cured all segfaults on win32. the fixes have been checked into cvs. there are still a few tests that fail, but none that trigger a segfault.
Re: Compiling mod_perl 1.99 on Solaris 8
On Thu, 18 Apr 2002, Darragh Sherwin wrote: I did this with the enviromental varible CFLAGS=-DUSE_ITHREADS ... MP_CCOPTS=-DUSE_ITHREADS you can't do that. and that is the source of your problems. if you are going to use a threaded mpm, *perl* needs to be built with ithreads enabled. perl's generated config.h will then have #define USE_ITHREADS which modperl will get compiled with.
Re: Compiling mod_perl 1.99 on Solaris 8
On Thu, 18 Apr 2002, Stas Bekman wrote: Also why do you need to use MP_AP_PREFIX? Use MP_APXS= instead. You don't need Apache sources to build mod_perl as DSO. MP_AP_PREFIX is not the source tree, it is the install tree. all modperl needs is the include/ directory from the install tree, it does not need apxs. MP_AP_PREFIX works everywhere. MP_APXS does not work on windows.
Re: DSO on Solaris - child dies with seg fault
you might actually be hitting a problem i just found on solaris with 2.0 and perl 5.6.1. a problem that is fixed in 5.8.0-tobe, where certain DynaLoader and XSLoader combo prevents modperl from closing all of the dlhandles. try adding this to your startup.pl before use-ing any other modules: use DynaLoader ();
Re: Challenging things to do: SIGSEGV catcher and backtrace extractor
On Fri, 12 Apr 2002, Stas Bekman wrote: If you read the rest of the post I mention it (without telling the name :). The problem with this module is that it's useful only after you have the core file. which is not good, because (as I've already explained): it's important to mention Devel::CoreStack, as it is a good starting point. 1. Many users have problems getting the core file dumped then there'd be no way to automate generating a stacktrace anyhow. 2. There can be multiply segfaults with different causes which will overwrite each other, so we want to catch SEGVs as they happen. that's ok, we'll deal with one at time. Not talking about the fact that this module is not slick, e.g. you need manual interaction to help it get to the trace. (it shows the gdb's *more* pager for long output of loading symbols). don't have to use the module as-is, but there is plenty of logic in there that can be borrowed, rather than figuring out everything from scratch.
Re: apxs to build modperl2
On Thu, 11 Apr 2002, Randy Kobes wrote: perl Makefile.PL MP_AP_PREFIX=C:\Apache2 MP_GENERATE_XS=1 note that MP_GENERATE_XS=1 is the default, no need to specify it anymore. PerlSwitches -Mblib=C:\Apache2 or: PerlModule Apache2
Re: [ModPerl causing segfaults]
sounds like the largefiles issue, you should have seen this warning during the build: Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0 *) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) easiest fix is the 1st option.
Re: Challenging things to do: SIGSEGV catcher and backtrace extractor
On Fri, 12 Apr 2002, Stas Bekman wrote: You can get a backtrace if you run the process under debugger without dumping a core file. No special setup required. I was thinking to attach the debugger on SIGSEGV event. Is it too late? I see certain gnome apps failing and they ask you if you want to get the stack, without me doing anything at all. That's what I want for modperl. You say it's not possible? anything is possible of course. but then you have to run the tests with httpd running under gdb, not something that should be done by default. maybe you don't need gdb either, i dunno, if gnome has a trick up its sleeve, might be worth looking at.
Re: mod_perl 1.99 and Apache::compat
On Sun, 7 Apr 2002, Dave Rolsky wrote: On Sun, 7 Apr 2002, Dave Rolsky wrote: I also found a few tiny bugs in Apache::compat. - The read() call in send_fd_length needs to be CORE::read. - In the last elsif in size_string, the size variable is missing its dollar sign ($). Here's a patch: thanks, applied. figures the 1 file we didn't have 'use strict' in. that's in there now too, which caught another bug in send_fd_length.
[announce] mod_perl-1.99_01
The URL http://perl.apache.org/dist/mod_perl-1.99_01.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_01.tar.gz size: 368151 bytes md5: 8db81a4cc572544eb427f2beb1beceea This is the first public release of mod_perl version 2.0-tobe. Apache version 2.0.35 or higher is required. Perl version 5.6.0 or higher is required. mod_perl is currently considered beta when used with the prefork MPM. mod_perl is currently considered alpha when used with a threaded MPM. Only DSO build of mod_perl-2.0 is currently supported, static builds will be support in the future. mod_perl-2.0-tobe is not 100% feature complete with the 1.xx version. See the todo/ directory for what remains to be done. Comments, questions, bug-reports, etc., should be sent to the mod_perl users list: [EMAIL PROTECTED] Enjoy, -Doug
Re: cvs commit: modperl/t/net/perl util.pl
i had a bad feeling about this. we should not be implementing escape_html to begin with, the functionality should all be in apache. i'm going to back out the patch. anybody care to make a doc patch to explain the problems with escape_html before the patch went in? thanks.
Re: cvs commit: modperl-2.0/todo api.txt
On Fri, 28 Sep 2001, Philippe M . Chiasson wrote: Aie ! There is a slight problem with this patch, as was pointed out by Stas a while ago. Blame it on the annoying TZ lag introduced in e-mail when living in Singapore ;-) This patch works, but doesn't preserve ARRAY context, thus: ok. could probably just pass wantarray to table_get_set and do: return $wantarray ? ($table-get($key)) : scalar $table-get($key)
Re: Backticks as fast as XS
On Wed, 26 Sep 2001, Matt Sergeant wrote:
Robin Berjon thought I should post this as a heads-up to anyone thinking
what I thought: XS or pure perl code will always be faster than backticks
or system() calls.
Wrong.
matt your benchmark is severly flawed. for starters, your xs and
external program do not do the same thing. your xs has the overhead of
sv_catpv. and who knows what else. if you want proof that there
is overhead using backticks, compare the difference of calling an
xsub that does _nothing_ vs. a backticked program that does _nothing_.
test.c:
int main(int argc, char **argv, char **env)
{
return 1;
}
TickTest.xs:
#include EXTERN.h
#include perl.h
#include XSUB.h
MODULE = TickTest PACKAGE = TickTest
void
foo()
CODE:
test.pl:
use blib;
use TickTest ();
use Benchmark;
timethese(100_000, {
backtick = sub { `./test` },
xs = sub { TickTest::foo() },
});
results:
Benchmark: timing 10 iterations of backtick, xs...
backtick: 292 wallclock secs (18.68 usr 43.93 sys + 142.43 cusr 84.00 csys = 289.04
CPU) @ 1597.19/s (n=10)
xs: -1 wallclock secs ( 0.25 usr + 0.00 sys = 0.25 CPU) @ 40.00/s
(n=10)
(warning: too few iterations for a reliable count)
RE: Backticks as fast as XS
On Wed, 26 Sep 2001, Matt Sergeant wrote:
As does backticks, surely? If you can tell me a way to make the code faster,
damn I'll do it as we have a *lot* of emails to process :-)
maybe, i don't know in what way your code uses sv_catpv.
and who knows what else.
Nothing else. I detailed this in the thread.
yeahbut, i have not seen the code.
That's not really what I was trying to say. Add some actual code to your
test, and some printf's (and sv code to the XS) and the differences diminish
fairly rapidly.
right, that's the flaw, you're benchmarking fprintf vs sv_catpv
I was trying to say don't make the _assumption_ that XS or pure Perl code
will be faster.
and what i'm trying to say is that if both the xs code and external
program are doing the same thing, xs will be heaps faster than backticking
a program. your xsub and external program are not doing the same thing.
i'm guessing part of the difference in your code is due to fprintf having
a pre-allocated buffer, whereas the SV's SvPVX has not been pre-allocated
and gets realloc-ed each time you call sv_catpv. have a look at the code
below, fprintf is faster than sv_catpvn, but if the SvPVX is preallocated,
sv_catpvn becomes faster than fprintf:
timethese(1_000, {
fprintf = sub { TickTest::fprintf() },
svcat = sub { TickTest::svcat() },
svcat_pre = sub { TickTest::svcat_pre() },
});
Benchmark: timing 1000 iterations of fprintf, svcat, svcat_pre...
fprintf: 9 wallclock secs ( 8.72 usr + 0.00 sys = 8.72 CPU) @ 114.68/s (n=1000)
svcat: 13 wallclock secs (12.82 usr + 0.00 sys = 12.82 CPU) @ 78.00/s (n=1000)
svcat_pre: 2 wallclock secs ( 2.75 usr + 0.00 sys = 2.75 CPU) @ 363.64/s (n=1000)
#include EXTERN.h
#include perl.h
#include XSUB.h
static FILE *devnull;
MODULE = TickTest PACKAGE = TickTest
BOOT:
devnull = fopen(/dev/null, w);
void
fprintf()
CODE:
{
int i;
char buffer[8292];
for (i=0; isizeof(buffer); i++) {
fprintf(devnull, a);
}
}
void
svcat()
CODE:
{
int i;
char buffer[8292];
SV *sv = newSV(0);
for (i=0; isizeof(buffer); i++) {
sv_catpvn(sv, a, 1);
}
SvREFCNT_dec(sv);
}
void
svcat_pre()
CODE:
{
int i;
char buffer[8292];
SV *sv = newSV(sizeof(buffer)+1);
for (i=0; isizeof(buffer); i++) {
sv_catpvn(sv, a, 1);
}
SvREFCNT_dec(sv);
}
Re: Using PerlTypeHandler and PerlHandler for the same Location
On Wed, 8 Aug 2001, Jay Buffington wrote:
Hi,
In my httpd.conf file I have:
Location /foo/
SetHandler perl-script
PerlTypeHandler foo
PerlHandler bar
/Location
and then in the foo and bar files I have:
--file foo.pm-
package foo;
sub handler {
my $r = shift;
$r-log_error(I'm in foo.);
}
1;
--file bar.pm-
package bar;
sub handler {
my $r = shift;
$r-log_error(I'm in bar.);
}
1;
I would expect this experiment would print out I'm in foo. followed by I'm in
bar. to my apache error log. It only prints I'm in foo. If I remove the
PerlTypeHandler line from the httpd.conf I get only I'm in bar. If I leave the
TypeHandler but omit the PerlHandler, and add
$r-push_handlers(PerlHandler=\bar::handler); to foo.pm I still only get I'm in
foo.
I'm using Perl 5.6 and mod_perl 1.25 with apache 1.3.19
Why does this not work as I expected?
because your PerlTypeHandler has returned the value 0 (aka OK), the type
handler phase is 'run first' (stop at first to return anything other than
DECLINED), which means mod_mime's type handler is never run so
r-handler never gets configured. you either need to return DECLINED in
your PerlTypeHandler or set $r-handler('perl-script') yourself.
Re: Segmentation faults, some strace logs
On Wed, 8 Aug 2001, Andrei A. Voropaev wrote: Looks like the problem is caused by 'abort'. I did not do much digging yet but looks like abort calls 'croak'. Unrelational to segv we expirienced strange Bizzare copy of ARRAY in aassign in Carp/Heavy.pm line 79 messages at random instead of display of nice stack trace. Could it be some perl5.6.0 bug? yes, and one that is fixed in 5.6.1
Re: Blank Page Returned by Mod_perl
On Wed, 8 Aug 2001, Bob Foster wrote: Hi, I'm using mod_backhand frontend and mod_perl backend (on 127.0.0.1). Many complex scripts are working fine but I'm getting behavior I don't understand with this simple script: #!/usr/local/bin/perl print Content-type: text/html\n\n; print This is a test\n\n; exit; 1. If the script is NOT handed off to the backend, the browser shows: This is a test 2. If the script is handed off to the backend, the browser shows a blank page. 3. If I go directly to the backend, the browser shows: Content-type: text/html This is a test I'd like to get the same output on 2 as occurs on 1. Why is this happening? Can anyone help? sounds like you are missing this in httpd.conf: PerlSendHeader On
Re: modperl 2.0
On Fri, 10 Aug 2001, Dave Rolsky wrote: Well, mod_perl 2.0 will require (or does currently require) Perl to be built with ithreads support and this wasn't introduced until 5.6.0 so I wouldn't hold my breath. Actually, I suspect Doug will be recommending that people use 5.8.0 since there's been a lot of fixes going into the ithreads code since 5.6.1. modperl-2.0 only requires ithreads if you want to use a threaded mpm. using prefork mpm (1.3 process model) does not require ithreads.
Re: problems building apache + mod_perl + mod_ssl on FreeBSD 4.3
On 12 Aug 2001, Wayne Pascoe wrote: cc -funsigned-char -DMOD_SSL=208104 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -I/usr/local/include -DEAPI -DNO_DL_NEEDED -fno-strict-aliasing -I/usr/local/include `./apaci` -L/usr/lib-o httpd buildmark.o modules.o modules/standard/libstandard.a modules/ssl/libssl.a modules/perl/libperl.a main/libmain.a ./os/unix/libos.a ap/libap.a-lcrypt -lssl -lcrypto -Wl,-E -L/usr/local/lib /usr/local/lib/perl5/5.6.1/i386-freebsd/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/5.6.1/i386-freebsd/CORE -lperl -lm -lc -lcrypt -liconv -lutil /usr/local/lib/perl5/5.6.1/i386-freebsd/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `SaveError': DynaLoader.o(.text+0x159): undefined reference to `Perl_vmess' *** Error code 1 sounds like -lperl is being picked up from somewhere else (like /usr/lib), rather than /usr/local/lib/perl5/5.6.1/i386-freebsd/CORE look for a libperl.so in /usr/lib, if you find one, get rid of it. libperl.so should always in the perl version/arch install path.
Re: bugfix in Apache::URI
On Tue, 14 Aug 2001, Vyacheslav Zamyatin wrote: Hello all, Here is a small patch that prevents crash in the following example. $referer = 'http://some.host.com'; $uri = Apache;:URI-parse($req,$referer); $page = $uri-rpath; If parsed uri don't have path at all, it'll dump core in the last line. thanks, applied to cvs.
Re: Children dying
On Tue, 14 Aug 2001, Aleksandr Vladimirskiy wrote: Hi all, I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: [Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) It looks like the child serves a request and immidiately dies. Does anyone have any ideas on how to figure out why this keeps happenning? sounds like the largefiles problem, which mod_perl's Makefile.PL should have warned you about: Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0 *) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) first option is the easiest way to fix.
Re: problems building apache + mod_perl + mod_ssl on FreeBSD 4.3
On Sun, 9 Sep 2001, The Doctor wrote:
THAT is the problem, and thanks to you Doug, the same problemed appeared in
BSD/OS and the above FIXES the problem!!!
great news. this has come up a bunch in the past, but nothing was done
about it. i've added the following sanity check to Makefile.PL...
Index: Makefile.PL
===
RCS file: /home/cvs/modperl/Makefile.PL,v
retrieving revision 1.195
diff -u -r1.195 Makefile.PL
--- Makefile.PL 2001/07/17 15:54:05 1.195
+++ Makefile.PL 2001/09/09 21:55:06
@@ -2410,6 +2410,7 @@
malloc_check();
uselargefiles_check();
dynaloader_check();
+shrplib_check();
if ($USE_APXS and $Config{libs} =~ /($thrlib)/) {
my $lib = $1;
@@ -2560,4 +2561,32 @@
/* Added by Wayne Scott
EOF
+}
+
+sub shrplib_check {
+return unless $Config{'useshrplib'} and
+ $Config{'useshrplib'} eq 'define';
+
+my $libperl = $Config{'libperl'} || 'libperl.so';
+
+for my $dir (qw(/lib /usr/lib /usr/local/lib)) {
+next unless -e $dir/$libperl;
+
+my $coredir = $Config{'archlibexp'}/CORE;
+my $corelib = $coredir/$libperl;
+
+phat_warn(EOF);
+$dir/$libperl might override
+$corelib
+
+This may cause build or runtime errors with mod_perl.
+Consider removing $dir/$libperl, it should not be there.
+
+If your vendor has installed $libperl there, complain to them and install
+Perl from source if needed.
+
+$libperl should only exist in Perl version/arch directories, for example:
+$coredir
+EOF
+}
}
Re: $r-handler() Issue
On Sat, 18 Aug 2001, David Wheeler wrote:
Hey All,
I've got a PerlTransHandler where I want to disable, under certain
circumstances (that is, whenever the content type isn't 'text/html') the
content handler. However, this code doesn't do the trick:
$r-handler('default-handler');
And neither does this:
$r-handler(perl-script);
$r-set_handlers('PerlHandler' = [ \OK ])
Or even this:
$r-handler(perl-script);
$r-set_handlers('PerlHandler' = [ \DECLINED ])
None of these snippets affects the content phase in any way; the
PerlHandler I install in httpd.conf gets executed every time, no matter
what. Can anyone tell me how I can disable my PerlHandler for the current
request?
you either need to have a PerlTypeHandler that sets $r-handler and
returns OK (to prevent mod_mime from settting it) or set $r-handler with
a PerlFixupHandler.
RE: Children dying
On Thu, 16 Aug 2001, Stas Bekman wrote: The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? because solaris is a special case. as is any platform where perl defaults to using its own malloc. the problem is perl's malloc pollutes the main httpd program with 'free' and 'malloc' symbols. when apache restarts (happens at startup too), any references in the main program to 'free' and 'malloc' now point to la-la land, things go boom. with 5.6.0+ this pollution can be prevented with -Ubincompat5005. or -Uusemymalloc for any version of perl, but there's a chance that might hurt performance depending on platform, so -Ubincompat5005 is likely a better choice. the modperl Makefile.PL has warned about this problem for ages, but i think the warning is often missed/ignored.
Re: DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Stas Bekman wrote: Currently what I've is: * How do I build on Solaris with DSO? = Build perl and mod_perl using the system malloc that should be any platform where perl defaults to using its own malloc, that is, if: % perl -V:usemymalloc reports: usemymalloc='y' which is fine if: % perl -V:bincompat5005 reports: bincompat5005='undef'; but the default for 5.6.x is: bincompat5005='define'; which can be turned off with: % Configure -Ubincompat5005 ... * My server leaks memory on restart with DSO = don't use DSO shouldn't happen with 5.6.1, at least it doesn't with my testing.
Re: DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Alex Povolotsky wrote: This is perl, v5.6.1 built for sun4-solaris # perl -V:usemymalloc usemymalloc='n'; that's fine. Seems like I'm suffering from dying children problem... My main apache dies sometimes, bringing neraly everything (well, except server-status) down. how did you build modperl? if USE_APXS=1 you may have missed this other warning: Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0 *) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) the first option is the easiest cure.
Re: segfault w/ Apache 1.3.20, mod_perl 1.26
On Sun, 22 Jul 2001, Richard L. Goerwitz III wrote: I apologize if this problem has already been identified and solved. After upgrading from mod_perl 1.25 to mod_perl 1.26 I fired up an Apache server instance that uses a config file with an extensive set of Perl/Perl sections. I'm using the Perl that came with my Linux (RedHat 7.0) machine, namely 5.6.0. i can't reproduce with 5.6.1. can you post a Perl section the produces the segv?
Re: Can't load mod_perl in Solaris 8
On Fri, 13 Jul 2001, Jie Gao wrote: On Thu, 12 Jul 2001, Doug MacEachern wrote: pitty perl -V does not report usebincompat5005, if you are trying to build modperl as a dso, Makefile.PL should have warned you: Your current configuration will most likely trigger core dumps, suggestions: *) Do not configure mod_perl as a DSO *) Upgrade your Perl version to 5.6.0 or higher (w/ -Ubincompat5005) *) Configure Perl with -Uusemymalloc (not recommended for performance) This is different from what I have been hearing for the past few years: Solaris' malloc is better than perl's. fyi.. Message-ID: [EMAIL PROTECTED] Date: Wed, 18 Jul 2001 11:40:07 +0100 From: Alan Burlison [EMAIL PROTECTED] To: Doug MacEachern [EMAIL PROTECTED] CC: [EMAIL PROTECTED], Alan Burlison [EMAIL PROTECTED] Subject: Re: solaris malloc Doug MacEachern wrote: seeing mixed reviews with regards to performance, README.solaris says: =head2 Malloc Issues with Perl on Solaris. Starting from Perl 5.7.1 Perl uses the Solaris malloc, since the perl malloc breaks when dealing with more than 2GB of memory, and the Solaris malloc also seems to be faster. but this message from alan says: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-01/msg00465.html A bit more can be squeezed out if you use the perl malloc putting aside the 2GB limit issue, curious if there are any numbers out there on solaris malloc vs. perl malloc? An interesting question. The answer as to which is faster is 'it depends'. The answer will depend on: o Which Solaris version are you using (malloc has been changed more or less with every release) o Is perl built MT or not and if so how many CPUs is it using. o What is the allocation profile. And I'm sure I could think of a few other variables as well. Perl *should* be better with its own malloc, as it has been written with knowledge of the likely allocation behaviour of perl. As an aside, a paper was presented at this year's Usenix describing the implementation of the Solaris kernel slab allocator, which is an arena-based object-caching allocator. It stores partially constructed objects, so that a malloc/free/malloc of the same object doesn't have to totally de/reinitialise the object every time. A userland port of this allocator is also described, along with some performance comparisons of other malloc implementations. The abstract is at http://www.usenix.org/event/usenix01/bonwick.html, but you need Usenix membership to download the paper. If anyone is interested, I'll try and get permission to send them a copy. The existing arena allocation in perl5 is quite similar in intent to the slab allocator, so the paper might be useful background reading for the perl6 allocator. Alan Burlison
Re: Errors when trying to use AuthAny.pm
The error log message is: [Wed Jul 11 09:04:59 2001] [error] (2)No such file or directory: access to /tools/ failed for nr2-216-196-142-76.fuse.net, reason: User not known to the underlying authentication module question is where does this error message come from? its not from apache or mod_perl or AuthAny.pm. you must have some sort of custom auth module installed.
Re: can't start apache-1.3.20 with mod_perl and Mason
On Fri, 13 Jul 2001, Louis-David Mitterrand wrote: * On Wed, Jul 11, 2001 at 08:09:20AM -0700, Doug MacEachern wrote: On Wed, 11 Jul 2001, Louis-David Mitterrand wrote: Will I have to build a debugging-enabled libperl to get relevant information? Or is this enough to understand the problem? libperld would help, all i can tell is that something in %SIG is being caught, which normally shouldn't happen at startup. are you assigning anything to %SIG ? you could also try this to get the perl filename:line where the segv happens: (gdb) source mod_perl-x.xx/.gdbinit (gdb) curinfo Thanks again Doug for taking the time to help. Here is the output from curinfo: Program received signal SIGSEGV, Segmentation fault. 0x402b14b6 in Perl_sighandler () from /usr/lib/libperl.so.5.6 (gdb) source .gdbinit (gdb) curinfo Attempt to extract a component of a value that is not a structure pointer. (gdb) Does that help a little? nope. if you could a libperld and build mod_perl with PERL_DEBUG=1 that might help (see SUPPORT doc for howto)
Re: Prob w/make test - server doesn't warm up
On Sun, 15 Jul 2001, Joan Wang wrote: I am getting the same exact problem on RedHat7.0. I was wondering if there is a solution to this access permission problem? sounds like it, when 'make make test' are done as root, things break. The strace.out looks like this: accept(16, which means the server has indeed started and is awaiting connections, sounds like the permissions problem.
Re: can't start apache-1.3.20 with mod_perl and Mason
On Mon, 16 Jul 2001, Louis-David Mitterrand wrote: * On Wed, Jul 11, 2001 at 08:09:20AM -0700, Doug MacEachern wrote: libperld would help, all i can tell is that something in %SIG is being caught, which normally shouldn't happen at startup. are you assigning anything to %SIG ? you could also try this to get the perl filename:line where the segv happens: (gdb) source mod_perl-x.xx/.gdbinit (gdb) curinfo OK, I rebuilt a debugging libperl and here is the gdb output: hmm, this is a totally different stack trace. have you tried modperl-1.26? or try adding this to httpd.conf: PerlSetEnv PERL_DESTRUCT_LEVEL 2
Re: swapping of mod_perl parent process / mlockall()
On Mon, 16 Jul 2001, Adi Fairbank wrote: Actually, I don't want child processes to inherit the page locks across a fork. I just wanted to experiment with performance issues when only the parent process is locked in memory. (I have a theory that when the parent process swaps to disk, the swapped pages become unshared for the rest of the server's life) I was hoping you could give me a hint as to where in the source code I could call mlockall(), e.g. file mod_perl.c, line NNN.. you should just be able to create a module with a .xs something like: #include EXTERN.h #include perl.h #include XSUB.h #include sys/mman.h MODULE = Mlock PACKAGE = Mlock int mlockall() CODE: RETVAL = (mlockall(MCL_CURRENT) == 0); OUTPUT: RETVAL and call Mlock::mlockall(); in a startup script.
Re: Overwriting the Basic Password
On Wed, 18 Jul 2001, Arthur M. Kang wrote: Is there a reverse to the($res,$password)=$r-get_basic_auth_pw function? Is there anyone to globally set or reset the values that come out of $r-get_basic_auth_pw? Can I set a new password to come out? You can do it with the user ($c-user)... $r-header_in(Authorization = 'Basic ' . MIME::Base64::encode(join ':', $username, $password));
Re: libapreq build error
On Tue, 24 Jul 2001, brian moseley wrote: hiya. trying to build the latest cpan version of libapreq with perl 5.6.1 + use5005threads, apache 1.3.20, mod-perl 1.25. got this error: Request.xs: In function `upload_hook': Request.xs:230: `thr' undeclared (first use in this function) try adding a dTHX; in upload_hook, and anywhere else that complains about `thr'
