Re: Segmentation fault
[In the future please don't reply to some thread when starting a new topic,
but post a new email. thank you!]
Bobber Cheng wrote:
Hi,
Apache(2.0.48) with perl_mod(1.99_10) got a Segmentation fault when i
access a perl script from apache. I use perl-5.8.2 built from source
without thread-support. perl_mod is complied by perl "Makefile.PL
MP_INST_APACHE2=1 MP_DEBUG=1 MP_AP_PREFIX=/usr/local/apache2".
[...]
0x4027b14a in memcpy () from /lib/libc.so.6
(gdb) backtrace
#0 0x4027b14a in memcpy () from /lib/libc.so.6
#1 0x40174728 in apr_file_read (thefile=0x8433e58, buf=0x0,
nbytes=0x81b33ec)
at readwrite.c:122
#2 0x403ab52e in modperl_slurp_filename (r=0x8433e58, tainted=0)
at modperl_util.c:710
#3 0x406c677b in XS_Apache__RequestRec_slurp_filename (cv=0x81b33ec)
Please try this patch:
Index: src/modules/perl/modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.56
diff -u -r1.56 modperl_util.c
--- src/modules/perl/modperl_util.c 3 Nov 2003 09:29:49 - 1.56
+++ src/modules/perl/modperl_util.c 12 Nov 2003 09:09:10 -
@@ -706,6 +706,12 @@
size = r->finfo.size;
sv = newSV(size);
+
+if (!size) {
+sv_setpvn(sv, "", 0);
+return newRV_noinc(sv);
+}
+
file = r->finfo.filehand;
if (!file) {
rc = apr_file_open(&file, r->filename, APR_READ|APR_BINARY,
You may need to use the latest cvs (or mod_perl 1.99_11) if the patch doesn't
apply cleanly, but I think it should be fine. You want to use 1.99_11 in any case.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] perl_clone takes 5 and more seconds to complete
Stas Bekman wrote: > > How about this (yet another) idea. Snapshot the OpCode tree before and after > running the sections (or PerlLoadModule). Then traverse both OpCode > trees and somehow rip off the differences and transplant them into the newly > perl_clone()'d interpreters. We prefer to sustain a delay at the startup, > versus run-time. Any surgeons out there? I'm not sure what you mean there (lack of knowledge of mod_perl internals), but the optrees aren't cloned, be it the main optree or the CV optrees. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] perl_clone takes 5 and more seconds to complete
Rafael Garcia-Suarez wrote: Stas Bekman wrote: How about this (yet another) idea. Snapshot the OpCode tree before and after running the sections (or PerlLoadModule). Then traverse both OpCode trees and somehow rip off the differences and transplant them into the newly perl_clone()'d interpreters. We prefer to sustain a delay at the startup, versus run-time. Any surgeons out there? I'm not sure what you mean there (lack of knowledge of mod_perl internals), but the optrees aren't cloned, be it the main optree or the CV optrees. I'm not talking about mod_perl internals, just talking about amputating a chunk of the Optree from one interpreter and replanting it into another interpreter (not perl_cloned one). I'm not sure whether this is possible at all. I really want some sort of Storable::freeze, so I can save a CV and all the related SVs and then resurrect them with ::thaw in another interpreter. To repeat, the problem we have is that we start perl early to do config parsing (.e.g code run in sections) and we really want to kill that perl when it finished dealing with config, but we need the perl data it generated to be resurrected in the perl that will process the requests. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] perl_clone takes 5 and more seconds to complete
Stas Bekman wrote: > > I'm not talking about mod_perl internals, just talking about amputating a > chunk of the Optree from one interpreter and replanting it into another > interpreter (not perl_cloned one). You need to explain to me what those interpreters are. IIUC from your remark below the first one is in the root httpd process to parse the config file ; the other ones are in the child httpd processes to process requests ? And you want to slim down the first one ? What are the CV root and CV start of those interpreters ? Why do you want to move CVs from the first one to the later ones ? Just removing them from the first one is not enough ? > I'm not sure whether this is possible at > all. I really want some sort of Storable::freeze, so I can save a CV and all > the related SVs and then resurrect them with ::thaw in another interpreter. The relative SVs ? did you mean the whole contents of stashes and lexical pads ? > To repeat, the problem we have is that we start perl early to do config > parsing (.e.g code run in sections) and we really want to kill that > perl when it finished dealing with config, but we need the perl data it > generated to be resurrected in the perl that will process the requests. The whole data+cv moving is theoretically possible but I'm not convinced there will be a significant performance gain. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] perl_clone takes 5 and more seconds to complete
Rafael Garcia-Suarez wrote: Stas Bekman wrote: I'm not talking about mod_perl internals, just talking about amputating a chunk of the Optree from one interpreter and replanting it into another interpreter (not perl_cloned one). You need to explain to me what those interpreters are. IIUC from your remark below the first one is in the root httpd process to parse the config file ; the other ones are in the child httpd processes to process requests ? And you want to slim down the first one ? What are the CV root and CV start of those interpreters ? Why do you want to move CVs from the first one to the later ones ? Just removing them from the first one is not enough ? here is an idea of what we're talking about. httpd.conf hits a section, so mod_perl needs to launch the interpreter. the section adds configuration directives httpd.conf and sets $Apache::Server::SaveConfig = 1, which means that the configuration is to be available via perl package variables at request time. so, when this interpreter is cloned so a pool of them can service requests, that data needs to go with it . under the current situation, this all happens just fine, since clones carry with them copies of everything (or so I read :) however, because the interpreter was started when was parsed, any modules that are use()d after the interpreter gets started (via startup.pl, PerlModule, or whatever) are _also_ added to the interpreter and copied. this is bad for a few reasons, namely that request-time processing may not need the packages (if they were used only for config parsing), and that the interpreter cloning required when the request pool is expanded takes an extremely long time. so, what would be ideal is to clone a _different_ interpreter than the one that parsed , thus giving us the ability to clone an interpreter with no loaded modules at all. this would greatly reduce the time it takes to clone interpreters for the request pool, thus increasing request-time performance. the problem with this, though, is that we don't really want a clean interpreter, we want an _almost_ clean one - one with only the data we know is important (like the globals set within the section). so, if we could copy the relevant data from the first interpreter and insert it into the one we're about to clone for the request, we'd have the best situation possible - minimal data in the parent interpreter. or something like that :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] perl_clone takes 5 and more seconds to complete
Geoffrey Young wrote: > > the problem with this, though, is that we don't really want a clean > interpreter, we want an _almost_ clean one - one with only the data we know > is important (like the globals set within the section). so, if we > could copy the relevant data from the first interpreter and insert it into > the one we're about to clone for the request, we'd have the best situation > possible - minimal data in the parent interpreter. Problem : how to separate the relevant data from the irrelevant one ? Does it live in a particular package ? I imagine it's possible to e.g. add an attribute on stashes that say "don't clone me". And implement a function "require_for_this_interpreter_only $module" in an XS module. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] perl_clone takes 5 and more seconds to complete
Rafael Garcia-Suarez wrote: Geoffrey Young wrote: the problem with this, though, is that we don't really want a clean interpreter, we want an _almost_ clean one - one with only the data we know is important (like the globals set within the section). so, if we could copy the relevant data from the first interpreter and insert it into the one we're about to clone for the request, we'd have the best situation possible - minimal data in the parent interpreter. Problem : how to separate the relevant data from the irrelevant one ? Does it live in a particular package ? for the stuff I was talking about, I believe so. however, for directive handlers it does not, so we'd probably need to tweak the interface a bit. but the idea, I guess, is that mod_perl would (eventually) know what data is required to be copied, so long as we had a way to do it. I imagine it's possible to e.g. add an attribute on stashes that say "don't clone me". And implement a function "require_for_this_interpreter_only $module" in an XS module. cool :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0 RELEASE
[EMAIL PROTECTED] wrote:
geoff 2003/11/12 08:24:28
Modified:.RELEASE
Log:
use relative links
add chmod routines
move old releases to old - don't remove entirely
add www.apache.org/dist/perl placeholder
Revision ChangesPath
1.8 +25 -10modperl-2.0/RELEASE
Index: RELEASE
===
RCS file: /home/cvs/modperl-2.0/RELEASE,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- RELEASE 10 Nov 2003 21:16:02 - 1.7
+++ RELEASE 12 Nov 2003 16:24:28 - 1.8
@@ -46,18 +46,29 @@
b. ssh to www.apache.org, unpack the package, update symlinks to the
tar ball and unpacked distro:
+
% ssh www.apache.org
% cd /www/perl.apache.org/dist/
-% ln -sf /www/perl.apache.org/dist/mod_perl-1.99_12.tar.gz \
- /www/perl.apache.org/dist/mod_perl-2.0-current.tar.gz
+% ln -sf mod_perl-1.99_12.tar.gz mod_perl-2.0-current.tar.gz
% tar -xzvf mod_perl-1.99_12.tar.gz
% rm /www/perl.apache.org/dist/mod_perl-2.0-current
-% ln -sf /www/perl.apache.org/dist/mod_perl-1.99_12 \
- /www/perl.apache.org/dist/mod_perl-2.0-current
+% ln -sf mod_perl-1.99_12 mod_perl-2.0-current
The full path in 'ln -sf' was there for a reason. I don't know why, but using
the relative path is not working on FreeBSD. So please restore it.
+ c. archive older releases (keep current + one prior release)
+
+% mv /www/perl.apache.org/dist/mod_perl-1.99_10.tar.gz \
+ /www/perl.apache.org/dist/old
+% mv /www/perl.apache.org/dist/mod_perl-1.99_10.tar.gz.asc \
+ /www/perl.apache.org/dist/old
+% rm -rf /www/perl.apache.org/dist/mod_perl-1.99_10
+
+ d. make sure that the files you just created are group rw so
+ all the dist admins can make changes:
- c. remove releases older by 2 subversions (keep the last one)
+% find /www/perl.apache.org/dist/ -user $USER -type f -exec chmod 0664 {} \;
+% find /www/perl.apache.org/dist/ -user $USER -type d -exec chmod 0775 {} \;
I guess that does the job, but then you have to adjust $USER... How about just
doing this on the files that you just added?
% chmod g+rw /www/perl.apache.org/dist/mod_perl-1.99_12.tar.gz*
% find /www/perl.apache.org/dist/mod_perl-1.99_12 \
-type f -exec chmod g+wr {} \;
% find /www/perl.apache.org/dist/mod_perl-1.99_12 \
-type d -exec chmod g+rwx {} \;
- d. update the version and release date
+ e. update the version and release date
modperl-docs/src/download/index_top.html and commit. It'll be
automatically updated within 6 hours. Alternatively you can do a
manual update by logging into www.apache.org and running:
@@ -89,9 +100,9 @@
% scp mod_perl-1.99_12.tar.gz.asc www.apache.org:/www/perl.apache.org/dist/
% ssh www.apache.org
-% chmod 0664 /www/perl.apache.org/dist/mod_perl-1.99_12.tar.gz.asc
-% ln -sf /www/perl.apache.org/dist/mod_perl-1.99_12.tar.gz.asc \
- /www/perl.apache.org/dist/mod_perl-2.0-current.tar.gz.asc
+% cd /www/perl.apache.org/dist/
+% chmod 0664 mod_perl-1.99_12.tar.gz.asc
+% ln -sf mod_perl-1.99_12.tar.gz.asc mod_perl-2.0-current.tar.gz.asc
same here: full path is needed
c. ask one of the other developers to double check the signature file
and tarball: download both files and verify the signature:
@@ -100,7 +111,11 @@
% pgpv mod_perl-1.99_12.tar.gz.asc
-8. Prepare for the next cycle
+8. Distribute to www.apache.org/dist/perl
+
+ a. TBD
drop that one, what we will do is just fixup the paths above
+9. Prepare for the next cycle
a. increment version in lib/mod_perl.pm
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0 RELEASE
-% ln -sf /www/perl.apache.org/dist/mod_perl-1.99_12.tar.gz \
- /www/perl.apache.org/dist/mod_perl-2.0-current.tar.gz
+% ln -sf mod_perl-1.99_12.tar.gz mod_perl-2.0-current.tar.gz
% tar -xzvf mod_perl-1.99_12.tar.gz
% rm /www/perl.apache.org/dist/mod_perl-2.0-current
-% ln -sf /www/perl.apache.org/dist/mod_perl-1.99_12 \
- /www/perl.apache.org/dist/mod_perl-2.0-current
+% ln -sf mod_perl-1.99_12 mod_perl-2.0-current
The full path in 'ln -sf' was there for a reason. I don't know why, but
using the relative path is not working on FreeBSD. So please restore it.
sorry. that was based on an email eric and I got the other day:
Henk P. Penning wrote:
> Hi,
>
> I noticed you put up some stuff in '/dist/perl/'.
>
> The following three symlinks are not going to work on mirrors.
> Could you change them to 'relative' links ?
>
> mod_perl-2.0-current
> -> /www/www.apache.org/dist/perl/mod_perl-1.99_11
> mod_perl-2.0-current.tar.gz
> -> /www/www.apache.org/dist/perl/mod_perl-1.99_11.tar.gz
> mod_perl-2.0-current.tar.gz.asc
> -> /www/www.apache.org/dist/perl/mod_perl-1.99_11.tar.gz.asc
>
I'm not sure who is right then, so you'll have to take it up with him.
+% find /www/perl.apache.org/dist/ -user $USER -type f -exec
chmod 0664 {} \; +% find /www/perl.apache.org/dist/ -user $USER
-type d -exec chmod 0775 {} \;
I guess that does the job, but then you have to adjust $USER... How
about just doing this on the files that you just added?
on minotaur $USER was automatically set to 'geoff' for me.
+8. Distribute to www.apache.org/dist/perl
+
+ a. TBD
drop that one, what we will do is just fixup the paths above
I thought I understood on pmc that how we ought to handle that directory
still has yet to be determined? if it is determined, then it warrants a
separate entry.
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0 RELEASE
Geoffrey Young wrote:
-% ln -sf /www/perl.apache.org/dist/mod_perl-1.99_12.tar.gz \
- /www/perl.apache.org/dist/mod_perl-2.0-current.tar.gz
+% ln -sf mod_perl-1.99_12.tar.gz mod_perl-2.0-current.tar.gz
% tar -xzvf mod_perl-1.99_12.tar.gz
% rm /www/perl.apache.org/dist/mod_perl-2.0-current
-% ln -sf /www/perl.apache.org/dist/mod_perl-1.99_12 \
- /www/perl.apache.org/dist/mod_perl-2.0-current
+% ln -sf mod_perl-1.99_12 mod_perl-2.0-current
The full path in 'ln -sf' was there for a reason. I don't know why,
but using the relative path is not working on FreeBSD. So please
restore it.
sorry. that was based on an email eric and I got the other day:
>
Henk P. Penning wrote:
> Hi,
>
> I noticed you put up some stuff in '/dist/perl/'.
>
> The following three symlinks are not going to work on mirrors.
> Could you change them to 'relative' links ?
>
> mod_perl-2.0-current
> -> /www/www.apache.org/dist/perl/mod_perl-1.99_11
> mod_perl-2.0-current.tar.gz
> -> /www/www.apache.org/dist/perl/mod_perl-1.99_11.tar.gz
> mod_perl-2.0-current.tar.gz.asc
> -> /www/www.apache.org/dist/perl/mod_perl-1.99_11.tar.gz.asc
>
I'm not sure who is right then, so you'll have to take it up with him.
Interesting. Do you have that email, so that I can followup on it?
+% find /www/perl.apache.org/dist/ -user $USER -type f -exec
chmod 0664 {} \; +% find /www/perl.apache.org/dist/ -user $USER
-type d -exec chmod 0775 {} \;
I guess that does the job, but then you have to adjust $USER... How
about just doing this on the files that you just added?
on minotaur $USER was automatically set to 'geoff' for me.
I guess that's OK then. It just sounds silly to try to change all files when
you exactly which files you've added ;) But it doesn't matter, your way is fine.
+8. Distribute to www.apache.org/dist/perl
+
+ a. TBD
drop that one, what we will do is just fixup the paths above
I thought I understood on pmc that how we ought to handle that directory
still has yet to be determined? if it is determined, then it warrants a
separate entry.
I've already posted a summary to the pmc about it. Nobody has followed up on
it. I'll repost it again. Please watch that list.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0 RELEASE
I'm not sure who is right then, so you'll have to take it up with him. Interesting. Do you have that email, so that I can followup on it? done. also, note that I followed his instruction and generated relative symlinks (in the form I wrote in the RELEASE doc) in both dist/ directories - so, the instructions I wrote were used top generate the current state of affairs. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mp2 - still cannot start server on solaris
I guess I just was not lucky enough. I upgraded my env to Apache 2.0.48, mod_perl 1.99_11, perl 5.8.2, gcc 3.3 on solaris 2.8. I'm still having the same problem. the server just cannot be started. I had successfully built an older version of mod_perl with gcc 2.95.2; however, I have no luck with gcc 3.3 at all. Any special gcc flags or a solaris patch that I need? Thanks for your help! -8<-- Start Bug Report 8<-- 1. Problem Description: Server cannot be started when $ make test make[2]: Leaving directory `/s5/twh/papache/httpd-2.0.48/mod_perl-1.99_11/xs/ModPerl' make[1]: Leaving directory `/s5/twh/papache/httpd-2.0.48/mod_perl-1.99_11/xs' /s5/twh/perl581/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -clean APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /s5/twh/perl581/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -bugreport -verbose=0 /s5/twh/apache2/bin/httpd -d /s5/twh/papache/httpd-2.0.48/mod_perl-1.99_11/t -f /s5/twh/papache/httpd-2.0.48/mod_perl-1.99_11/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.48 (prefork MPM) waiting 60 seconds for server to start: .. waiting 60 seconds for server to start: giving up after 61 secs !!! server failed to start! (t/logs/error_log wasn't created, start the server in the debug mode) !!! oh shucks, server dumped core !!! for stacktrace, run: gdb /s5/twh/apache2/bin/httpd -core /s5/twh/papache/httpd-2.0.48/mod_perl-1.99_11/t/core ++ | Please file a bug report: http://perl.apache.org/bugs/ | ++ make: *** [run_tests] Error 1 2. Used Components and their Configuration: *** mod_perl version 1.9911 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS => /s5/twh/apache2/bin/apxs MP_AP_PREFIX=> /s5/twh/apache2 MP_COMPAT_1X=> 1 MP_DEBUG=> 1 MP_GENERATE_XS => 1 MP_INST_APACHE2 => 1 MP_LIBNAME => mod_perl MP_TRACE=> 1 MP_USE_DSO => 1 MP_USE_STATIC => 1 *** /s5/twh/apache2/bin/httpd -V Server version: Apache/2.0.48 Server built: Nov 11 2003 13:19:59 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/s5/twh/apache2" -D SUEXEC_BIN="/s5/twh/apache2/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** /s5/twh/perl581/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris uname='sunos ln 5.8 generic_108528-18 sun4u sparc ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='/opt/exp/gnu/bin/gcc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/opt/exp/gnu/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/opt/exp/gnu/include' ccversion='', gccversion='3.3.1', gccosandvers='solaris2.8' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='/opt/exp/gnu/bin/gcc', ldflags =' ' libpth=/opt/exp/gnu/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldb -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-E' cccdlflags='-fPIC', lddlflags=' -Wl,-E -G' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING USE_LARGE_FILES Built under solaris Compiled at Nov 12 2003 13:02:49 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: /s5/twh/perl581/lib/5.8.2/sun4-solaris /s5/twh/perl581/lib/5.8.2 /s5/twh/perl581/lib/site_perl/5.8.2/sun4-solaris /s5/twh/perl581/lib/site_perl/5.8.2 /s5/twh/perl581/lib/site_perl/5.8.1/sun4-solaris /s5/twh/perl581/lib/site_perl/5.8.1 /s5/twh/perl581/lib/site_perl . 3.
[mp2] POST form limits; mod_perl + Mozilla Firebird
I have a large form (1000+ form elements) which uses method="POST". Only the first 429 elements/parameters are passed to my mod_perl application. The odd thing is, it only happens with Mozilla Firebird (Win32), and not MSIE. I originally thought this was a browser issue, but when I tried the same code under CGI, all elements were successfully passed from both Firebird and MSIE. Upgrading from Firebird 0.7.1 to the latest nightly (dated 2003-11-12) increased the number of passed form elements from approx. 269 to the current 429. Strangely, f the form used method="GET" then all form elements were passed regardless of browser type or version. I am going to try to reproduce the problem under the most recent build of mod_perl now. If this can be narrowed down to mod_perl specifically, I'll make a more formal bug report. I was wondering if anyone had seen anything like this before. Thanks, y - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] POST form limits; mod_perl + Mozilla Firebird
Please disregard, the latest build (mod_perl-1.99_11) fixed the problem. Cheers, y - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mp2 - still cannot start server on solaris
[EMAIL PROTECTED] wrote: I guess I just was not lucky enough. I upgraded my env to Apache 2.0.48, mod_perl 1.99_11, perl 5.8.2, gcc 3.3 on solaris 2.8. I'm still having the same problem. the server just cannot be started. I had successfully built an older version of mod_perl with gcc 2.95.2; however, I have no luck with gcc 3.3 at all. Any special gcc flags or a solaris patch that I need? [...] #0 0xfc6fff60 in ?? () (gdb) And now you need to run: bt to get the backtrace and post it here. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] perl_clone takes 5 and more seconds to complete
Geoffrey Young wrote: Rafael Garcia-Suarez wrote: Geoffrey Young wrote: the problem with this, though, is that we don't really want a clean interpreter, we want an _almost_ clean one - one with only the data we know is important (like the globals set within the section). so, if we could copy the relevant data from the first interpreter and insert it into the one we're about to clone for the request, we'd have the best situation possible - minimal data in the parent interpreter. Problem : how to separate the relevant data from the irrelevant one ? Does it live in a particular package ? for the stuff I was talking about, I believe so. however, for directive handlers it does not, so we'd probably need to tweak the interface a bit. And not for , because a random code can be run there in random packages. but the idea, I guess, is that mod_perl would (eventually) know what data is required to be copied, so long as we had a way to do it. That's why I was talking about diffing the Optree before and after the config phase. I imagine it's possible to e.g. add an attribute on stashes that say "don't clone me". And implement a function "require_for_this_interpreter_only $module" in an XS module. which goes back to the problem of being able to do it dynamically, i.e. sort of doing the diff I'm talking about above. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[mp2] HASH_SEED question
ActiveState just released version 807, which is based on the perl-5.8.1 sources with some 5.8.2 enhancements. The sources they use don't include the hash randomization stuff of 5.8.1/5.8.2 (so that builds using 807 will be binary compatible with pre-807 builds), and they define NO_HASH_SEED in the compile-time flags when building extensions. perl -v reports 5.8.1. My reading of src/modules/perl/(mod_perl|modperl_perl).c is that the MP_NEED_HASH_SEED_FIXUP doesn't need additional logic in this case, but I'm worried I might be missing something? Thanks. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
