Apache::Request and utf8
Hello, Apache::Request ignores character sets. So if you use an utf8 encoded form values returned by Apache::Request->param are not flagged as valid perl UTF8 strings. You need to filter them through Encode::decode(). That's surely, euhm, suboptimal. Did anybody find a nice way to fix/work around this? (besides subclassing Apache::Request) Groeten, Harmen Garagebedrijf Het Vierkantje. -- The Moon is Waning Crescent (22% of Full)
Re: red hat mod_perl build problem
Tom Caldwell wrote:
I am having a problem install mod_perl on red hat 9 with apache 2.0.53
installed in dir /opt/apache2 (it runs).
I executed >perl Makefile.PL with options
MP_USE_DSO=1 and MP_AP_PREFIX=/opt/apache2
which ran successfully. Then I executed >make and got the following
results:
gcc -I/home/caldwell/perl/modperl/mod_perl-2.0.0-RC4/src/modules/perl
-I/home/caldwell/perl/modperl/mod_perl-2.0.0-RC4/xs
-I/opt/apache2/include -I/opt/apache2/include -I/opt/apache2/include
-fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm
-I/opt/perl5.8.6/lib/5.8.6/x86_64-linux/CORE -DMOD_PERL -DMP_COMPAT_1X
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE
-D_GNU_SOURCE -O2 \
-c modperl_sys.c && mv modperl_sys.o modperl_sys.lo
modperl_sys.c:65:2: #error "modperl_sys_dlclose not defined on
this platform"
make[1]: *** [modperl_sys.lo] Error 1
make[1]: Leaving directory
`/home/caldwell/perl/modperl/mod_perl-2.0.0-RC4/src/modules/perl'
make: *** [modperl_lib] Error 2
Tom, it comes from:
/*
* Perl does not provide this abstraction.
* APR does, but requires a pool. efforts to expose this area of apr
* failed. so we roll our own. *sigh*
*/
int modperl_sys_dlclose(void *handle)
{
#if defined(MP_SYS_DL_DLOPEN)
[...]
#elif defined(MP_SYS_DL_DYLD)
[...]
#elif defined(MP_SYS_DL_HPUX)
[...]
#elif defined(MP_SYS_DL_WIN32)
[...]
#elif defined(MP_SYS_DL_BEOS)
[...]
#elif defined(MP_SYS_DL_DLLLOAD)
[...]
#elif defined(MP_SYS_DL_AIX)
[...]
#else
#error "modperl_sys_dlclose not defined on this platform"
return 0;
#endif
This define comes from:
lib/ModPerl/Code.pm:(my $dlsrc = uc $Config{dlsrc}) =~ s/\.xs$//i;
lib/ModPerl/Code.pm:print $h_fh "\n#define MP_SYS_$dlsrc 1\n";
On my machine it's:
% perl -V:dlsrc
dlsrc='dl_dlopen.xs';
As you didn't follow my request to submit a proper bug report as explained
at http://perl.apache.org/bugs/, I can't tell you more until you do so :)
--
__
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
Re: APR::BucketType bucket types?
Dintelmann, Peter wrote: I am looking for a list of the bucket types for APR::BucketType objects and their meanings. So far I have encountered the types "FLUSH", "EOC" (end of connection?) and "mod_perl SV bucket". It seems that bucket type (names) are only available as strings. When looking for buckets of a particular type a comparison to an integer constant would be more efficient. Can we have some constants in APR::Const for this purpose and the bucket type name as a dual valued scalar? Peter, libapr identifies buckets only by their name. How do you suggest that we manage their numerical values? A new bucket type can be added any moment and we won't have an ID for it. APR::Const only provides a glue for the existing libapr's C-level constants. If you want a change of this kind, you will have to ensure that libapr provides that ID first and mp2 will follow. -- __ 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
Re: 2.0.0-RC4, FreeBSD-5.3, Apache2.pm not installed
James Lever wrote: Hi All, I'm trying to install mod_perl 2.0.0-RC4 under FreeBSD-5.3 but although Apache2.pm is present in the libs/ hierarchy, it is not being installed as part of 'make install'. 2.0.0-RC3 (from the ports collection) seemed to work fine, but I am trying to get HTTunnel-0.0.5 up and running which requires 1.999_21 Any help appreciated. James, as the next release won't have Apache2.pm anymore, it's probably a waste of time trying to resolve this issue. For now just copy in manually. If you want to figure it out anyway, check whether Apache2.pm ends up in blib/ after you did 'make'. -- __ 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
Re: red hat mod_perl build problem
Thanks for the reply, but I did some more digging and decided that
having 2 versions of perl installed (improperly) on my system was
probably the culprit. And since red hat provides a version of
apache2 and modperl 2 with perl 5.8.0, I decided to just go with
that, even though it is 1.5 years old (1.99.09)!
Now if I could only get the Oracle client to install I will be back
to developing more code!
Thanks,
Tom
--On Monday, April 04, 2005 12:34 PM -0400 Stas Bekman
<[EMAIL PROTECTED]> wrote:
Tom Caldwell wrote:
I am having a problem install mod_perl on red hat 9 with apache
2.0.53 installed in dir /opt/apache2 (it runs).
I executed >perl Makefile.PL with options
MP_USE_DSO=1 and MP_AP_PREFIX=/opt/apache2
which ran successfully. Then I executed >make and got the
following results:
gcc
-I/home/caldwell/perl/modperl/mod_perl-2.0.0-RC4/src/modules/per
l -I/home/caldwell/perl/modperl/mod_perl-2.0.0-RC4/xs
-I/opt/apache2/include -I/opt/apache2/include
-I/opt/apache2/include -fno-strict-aliasing -pipe
-I/usr/local/include -I/usr/include/gdbm
-I/opt/perl5.8.6/lib/5.8.6/x86_64-linux/CORE -DMOD_PERL
-DMP_COMPAT_1X -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -O2 \
-c modperl_sys.c && mv modperl_sys.o modperl_sys.lo
modperl_sys.c:65:2: #error "modperl_sys_dlclose not defined on
this platform"
make[1]: *** [modperl_sys.lo] Error 1
make[1]: Leaving directory
`/home/caldwell/perl/modperl/mod_perl-2.0.0-RC4/src/modules/perl'
make: *** [modperl_lib] Error 2
Tom, it comes from:
/*
* Perl does not provide this abstraction.
* APR does, but requires a pool. efforts to expose this area
of apr
* failed. so we roll our own. *sigh*
*/
int modperl_sys_dlclose(void *handle)
{
# if defined(MP_SYS_DL_DLOPEN)
[...]
# elif defined(MP_SYS_DL_DYLD)
[...]
# elif defined(MP_SYS_DL_HPUX)
[...]
# elif defined(MP_SYS_DL_WIN32)
[...]
# elif defined(MP_SYS_DL_BEOS)
[...]
# elif defined(MP_SYS_DL_DLLLOAD)
[...]
# elif defined(MP_SYS_DL_AIX)
[...]
# else
# error "modperl_sys_dlclose not defined on this platform"
return 0;
# endif
This define comes from:
lib/ModPerl/Code.pm:(my $dlsrc = uc $Config{dlsrc}) =~
s/\.xs$//i;
lib/ModPerl/Code.pm:print $h_fh "\n#define MP_SYS_$dlsrc 1\n";
On my machine it's:
% perl -V:dlsrc
dlsrc='dl_dlopen.xs';
As you didn't follow my request to submit a proper bug report as
explained at http://perl.apache.org/bugs/, I can't tell you more
until you do so :)
--
__
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
Tom Caldwell
Vanderbilt University Medical Center
Bug Report : problem with both_str_native_remove test and broken mod_perl.so
1. Problem Description: I cannot get a clean make test. the tests fail (but not consistently t/filter/both_str_native_remove.# Failed test 1 in t/filter/both_str_native_remove.t at line 22 # Failed test 2 in t/filter/both_str_native_remove.t at line 24 t/filter/both_str_native_remove.FAILED tests 1-2 Failed 2/8 tests, 75.00% okay However once I got t/filter/both_str_native_remove.ok then subsequently the following failed t/flush..# Failed test 1 in t/flush.t at line 22 t/flush..FAILED test 1 Failed 1/1 tests, 0.00% okay If I >make install and run apache with LoadModule mod_perl modules/mod_perl.so at line 279 of httpd.conf I get conf> ../bin/apachectl start Syntax error on line 279 of /Library/Apache2/conf/httpd.conf: Can't locate API module structure `mod_perl' in file /Library/Apache2/modules/mod_perl.so: undefined symbol TIA Fred [EMAIL PROTECTED] 2. Used Components and their Configuration: *** mod_perl version 1.999021 *** using /Users/seibel/software/mod_perl-2.0.0-RC4/lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /Library/Apache2/bin/apxs MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 *** /Library/Apache2/bin/httpd -V Server version: Apache/2.0.52 Server built: Sep 30 2004 18:20:43 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_MMAP -D APR_USE_SYSVSEM_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="/Library/Apache2" -D SUEXEC_BIN="/Library/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" *** (apr|apu)-config linking info -L/Library/Apache2/lib -lapr-0 -lresolv -lpthread -L/Library/Apache2/lib -laprutil-0 -lldap -llber -lexpat -liconv *** /Users/seibel/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=darwin, osvers=7.8.0, archname=darwin-2level uname='darwin pcp08543146pcs.sntafe01.nm.comcast.net 7.8.0 darwin kernel version 7.8.0: wed dec 22 14:26:17 pst 2004; root:xnuxnu-517.11.1.obj~1release_ppc power macintosh powerpc ' 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='gcc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include', optimize='-Os', cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1495)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lc perllibs=-ldl -lm -lc libc=, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under darwin Compiled at Apr 3 2005 14:17:33 %ENV: PERL5LIB="/sw/lib/perl5:/sw/lib/perl5/darwin" PERL_LWP_USE_HTTP_10="1" @INC: /sw/lib/perl5 /sw/lib/perl5/darwin /Users/seibel/bin/lib/perl5/5.8.6/darwin-2level /Users/seibel/bin/lib/perl5/5.8.6 /Users/seibel/bin/lib/perl5/site_perl/5.8.6/darwin-2level /Users/seibel/bin/lib/perl5/site_perl/5.8.6 /Users/seibel/bin/lib/perl5/site_perl /Users/seibel/perladdons/lib/perl5/vendor_perl/5.8.6/darwin-2level /Users/seibel/perladdons/lib/perl5/vendor_perl/5.8.6 /Users/seibel/perladdons/lib/perl5/vendor_perl . *** Packages of interest status: Apache::Request: - CGI: 3.05 LWP: 5.803 mod_perl : 1.999021 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] This report was generated by t/REPORT on Mon Apr 4 17:23:33 2005 GMT. -8<-- End Bug Report --8<-- Note: Complete the rest of the details and post this bug report to modperl perl.apache.org. To subscribe to the list send an empty email to [EMAIL PR
Re: Segmentation Fault
Just in case you haven't yet solved the problem, I wanted to let you know that I had a similar problem. It turns out that MySQL and mod_perl were linking to different versions of libdb (BerkeleyDB). The solution was to rebuild mod_php and mod_perl with the same version. Apache itself can also have yet another version linked. A good tool to help figure out this sort of thing is "ldd". Give it the full paths of the modules and httpd itself, then see if there are differing versions anywhere. -- Dan Wilga [EMAIL PROTECTED] Web Administrator http://www.mtholyoke.edu Mount Holyoke CollegeTel: 413-538-3027 South Hadley, MA 01075"Who left the cake out in the rain?"
Re: 2.0.0-RC4, FreeBSD-5.3, Apache2.pm not installed
Hi Stas (and et list), On 5 Apr 2005, at 2:50 AM, Stas Bekman wrote: James, as the next release won't have Apache2.pm anymore, it's probably a waste of time trying to resolve this issue. For now just copy in manually. If you want to figure it out anyway, check whether Apache2.pm ends up in blib/ after you did 'make'. Before I did that, I did a bit more hunting to notice that it isn't actually installing any of the other perl module components either, but rather only the mod_perl.so DSO and the C header files all of which are being installed in /usr/local/include/apache2/. It is however updating the folling files: /usr/local/lib/perl5/site_perl/5.8.6/mach/auto/mod_perl/.packlist /usr/local/lib/perl5/5.8.6/mach/perllocal.pod So, it seems, unless there's a configure option or a make install option I've just completely missed, something a little strange is going on. Any ideas? cheers, James
[MP2] Using Apache::AuthCookie with $r->prev when login is a redirect to https
I have Apache::AuthCookie 3.06 working fine with just http under this
setup:
httpd-2.0.53
mod_perl-2.0.0-RC4
However, when I redirect to https for the login page, $r->prev is now
empty, so I don't have these values for my form:
$r->prev->uri
$r->prev->args
$r->prev->subprocess_env("AuthCookieReason")
What is the best way to do this? I would prefer for the login page to
be in https, and not just submit to https. I'm using Apache::Session
as well, but I don't know if there is a way to make sure that stuff
gets into the session before I redirect to https.
Barry Hoggard
Re: 2.0.0-RC4, FreeBSD-5.3, Apache2.pm not installed
James Lever wrote: Hi Stas (and et list), On 5 Apr 2005, at 2:50 AM, Stas Bekman wrote: James, as the next release won't have Apache2.pm anymore, it's probably a waste of time trying to resolve this issue. For now just copy in manually. If you want to figure it out anyway, check whether Apache2.pm ends up in blib/ after you did 'make'. Before I did that, I did a bit more hunting to notice that it isn't actually installing any of the other perl module components either, but rather only the mod_perl.so DSO and the C header files all of which are being installed in /usr/local/include/apache2/. It is however updating the folling files: /usr/local/lib/perl5/site_perl/5.8.6/mach/auto/mod_perl/.packlist /usr/local/lib/perl5/5.8.6/mach/perllocal.pod So, it seems, unless there's a configure option or a make install option I've just completely missed, something a little strange is going on. Any ideas? 'make install' is governed by MakeMaker. For example if for some reason your files in blib/ are older than the previously installed files, 'make install' will skip those. So check the timestamps or see whether you can nuke the preinstalled files and then try again. I've certainly seen that at least once on my setup, and the above approach worked for me. -- __ 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
[mp1] Apache::AuthDBI segfaults under Fedora Core 1?
In moving some web sites from a server running Red Hat Linux release 7.3 (Valhalla) to one running Fedora Core release 1 (Yarrow), I'm finding that attempts to authenticate under mod_perl using Apache::AuthDBI, which were working normally on the RH 7.3 server, are producing segfaults on the FC1 server. I've searched the Web and the list archives to try to find other reports of a similar problem, but have come up empty so far. I'd appreciate any suggestions on what I might try to get Apache::AuthDBI working under FC1. Thanks. Software versions on the FC1 server: kernel: Linux 2.4.22-1.2199.nptlsmp Perl: 5.8.3 DBI: 1.37 Apache: 1.3.33 mod_perl: 1.29 Apache::AuthDBI: 0.93 httpd.conf contains the following: PerlModule Apache::AuthDBI .htaccess contains the following: AuthName "Member Services" AuthType Basic PerlAuthenHandler Apache::AuthDBI::authen PerlAuthzHandler Apache::AuthDBI::authz PerlSetVar Auth_DBI_data_source [dsn deleted] PerlSetVar Auth_DBI_username [username deleted] PerlSetVar Auth_DBI_password [password deleted] PerlSetVar Auth_DBI_encrypted off PerlSetVar Auth_DBI_pwd_table members_data PerlSetVar Auth_DBI_uid_field unamo PerlSetVar Auth_DBI_pwd_field pass require valid-user When I set $Apache::AuthDBI::DEBUG = 2, I get lots of output from Apache::AuthDBI::authen() in the virtual host's error log; it seems to indicate that the authen() handler is completing normally, with either a successful or a failed username/password lookup (depending on whether I give valid or invalid credentials). Here's some sample output from that virtualhost error log, for example: 4858 Apache::AuthDBI::authen passwd not found in cache 4858 Apache::AuthDBI::authen statement: SELECT pass FROM members_data WHERE unamo = '[username deleted]' 4858 Apache::AuthDBI::authen passwd = >[password deleted]< 4858 Apache::AuthDBI::authen user [username deleted]: password match for >[password deleted]< 4858 Apache::AuthDBI::authen return OK At that point, regardless of whether the login credentials were valid or not, the browser reports a "Bad Server Response" error, and the apache error log records: [Mon Apr 4 14:03:49 2005] [notice] child pid 4858 exit signal Segmentation fault (11) I tried recompiling mod_perl with PERL_DEBUG=1 and reproducing the problem under gdb to get a backtrace; here's the result of that: (gdb) run -X -f `pwd`/t/conf/httpd.conf.test -d `pwd`/t Starting program: /home/w1/src/apache_1.3.33/src/httpd -X -f `pwd`/t/conf/httpd.conf.test -d `pwd`/t [Thread debugging using libthread_db enabled] [New Thread -1084376928 (LWP 30800)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1084376928 (LWP 30800)] 0x00624082 in _int_free () from /lib/tls/libc.so.6 (gdb) bt #0 0x00624082 in _int_free () from /lib/tls/libc.so.6 #1 0x0062301b in free () from /lib/tls/libc.so.6 #2 0x004f37a5 in Perl_safesysfree (where=0x95bc640) at util.c:140 #3 0x0051ab6c in Perl_sv_clear (my_perl=0x92516a8, sv=0x95bc278) at sv.c:5210 #4 0x0051b0fb in Perl_sv_free (my_perl=0x92516a8, sv=0x95bc278) at sv.c:5355 #5 0x004fa032 in Perl_mg_free (my_perl=0x92516a8, sv=0x95bb7c8) at mg.c:388 #6 0x0051ad32 in Perl_sv_clear (my_perl=0x92516a8, sv=0x95bb7c8) at sv.c:5144 #7 0x0051b0fb in Perl_sv_free (my_perl=0x92516a8, sv=0x95bb7c8) at sv.c:5355 #8 0x0051a923 in Perl_sv_clear (my_perl=0x92516a8, sv=0x95bc260) at sv.c:5207 #9 0x0051b0fb in Perl_sv_free (my_perl=0x92516a8, sv=0x95bc260) at sv.c:5355 #10 0x004fa032 in Perl_mg_free (my_perl=0x92516a8, sv=0x95bb4a4) at mg.c:388 #11 0x0051ad32 in Perl_sv_clear (my_perl=0x92516a8, sv=0x95bb4a4) at sv.c:5144 #12 0x0051b0fb in Perl_sv_free (my_perl=0x92516a8, sv=0x95bb4a4) at sv.c:5355 #13 0x00520202 in Perl_sv_unref_flags (my_perl=0x92516a8, sv=0x944a330, flags=1) at sv.c:7937 #14 0x00518ea3 in Perl_sv_force_normal_flags (my_perl=0x92516a8, sv=0x944a330, flags=1) at sv.c:4271 #15 0x0053a0ac in Perl_leave_scope (my_perl=0x92516a8, base=16) at scope.c:912 #16 0x005381bc in Perl_pop_scope (my_perl=0x95bc638) at scope.c:138 #17 0x00540ea7 in Perl_pp_return (my_perl=0x92516a8) at pp_ctl.c:1882 #18 0x004f2ead in Perl_runops_debug (my_perl=0x92516a8) at dump.c:1438 #19 0x004a29b9 in S_call_body (my_perl=0x92516a8, myop=0xbfefc1e0, is_eval=0) at perl.c: #20 0x004a2685 in Perl_call_sv (my_perl=0x92516a8, sv=0x0, flags=4) at perl.c:2140 #21 0x0817416e in perl_call_handler (sv=0x9509944, r=0x9567f7c, args=0x0) at mod_perl.c:1668 #22 0x08173403 in perl_run_stacked_handlers (hook=0x9509944 "\030ÉD\t\001", r=0x9567f7c, handlers=0x95098fc) at mod_perl.c:1381 #23 0x08171faa in perl_authenticate (r=0x9567f7c) at mod_perl.c:1033 #24 0x081b61f5 in run_method () #25 0x081b632a in ap_check_user_id () #26 0x081cb82a in process_request_internal () #27 0x081cbaf2 in ap_process_request () #28 0x081c2b9b in child_main () #29 0x081c2d61 in make_child () #30 0x081c2ec7 in startup_children () #31 0x081c357e
Re: Bug Report : problem with both_str_native_remove test and broken mod_perl.so
Fred Seibel wrote: 1. Problem Description: I cannot get a clean make test. the tests fail (but not consistently t/filter/both_str_native_remove.# Failed test 1 in t/filter/both_str_native_remove.t at line 22 # Failed test 2 in t/filter/both_str_native_remove.t at line 24 t/filter/both_str_native_remove.FAILED tests 1-2 Failed 2/8 tests, 75.00% okay However once I got t/filter/both_str_native_remove.ok then subsequently the following failed t/flush..# Failed test 1 in t/flush.t at line 22 t/flush..FAILED test 1 Failed 1/1 tests, 0.00% okay Fred, please follow the instructions at: http://perl.apache.org/docs/2.0/user/help/help.html#_C_make_test___Failures If I >make install and run apache with LoadModule mod_perl modules/mod_perl.so at line 279 of httpd.conf I get conf> ../bin/apachectl start Syntax error on line 279 of /Library/Apache2/conf/httpd.conf: Can't locate API module structure `mod_perl' in file /Library/Apache2/modules/mod_perl.so: undefined symbol Are you sure it's the right file? And that you load it with the right httpd? As the test suite worked, it should work too. Make sure that you don't have more than one mod_perl.so or httpd on your system. -- __ 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
Re: [mp1] Apache::AuthDBI segfaults under Fedora Core 1?
John Callender wrote: In moving some web sites from a server running Red Hat Linux release 7.3 (Valhalla) to one running Fedora Core release 1 (Yarrow), I'm finding that attempts to authenticate under mod_perl using Apache::AuthDBI, which were working normally on the RH 7.3 server, are producing segfaults on the FC1 server. I've searched the Web and the list archives to try to find other reports of a similar problem, but have come up empty so far. I'd appreciate any suggestions on what I might try to get Apache::AuthDBI working under FC1. Thanks. Software versions on the FC1 server: kernel: Linux 2.4.22-1.2199.nptlsmp Perl: 5.8.3 DBI: 1.37 Apache: 1.3.33 mod_perl: 1.29 Apache::AuthDBI: 0.93 httpd.conf contains the following: PerlModule Apache::AuthDBI [...] #0 0x00624082 in _int_free () from /lib/tls/libc.so.6 #1 0x0062301b in free () from /lib/tls/libc.so.6 #2 0x004f37a5 in Perl_safesysfree (where=0x95bc640) at util.c:140 #3 0x0051ab6c in Perl_sv_clear (my_perl=0x92516a8, sv=0x95bc278) at sv.c:5210 #4 0x0051b0fb in Perl_sv_free (my_perl=0x92516a8, sv=0x95bc278) at sv.c:5355 #5 0x004fa032 in Perl_mg_free (my_perl=0x92516a8, sv=0x95bb7c8) at mg.c:388 #6 0x0051ad32 in Perl_sv_clear (my_perl=0x92516a8, sv=0x95bb7c8) at sv.c:5144 #7 0x0051b0fb in Perl_sv_free (my_perl=0x92516a8, sv=0x95bb7c8) at sv.c:5355 #8 0x0051a923 in Perl_sv_clear (my_perl=0x92516a8, sv=0x95bc260) at sv.c:5207 #9 0x0051b0fb in Perl_sv_free (my_perl=0x92516a8, sv=0x95bc260) at sv.c:5355 #10 0x004fa032 in Perl_mg_free (my_perl=0x92516a8, sv=0x95bb4a4) at mg.c:388 #11 0x0051ad32 in Perl_sv_clear (my_perl=0x92516a8, sv=0x95bb4a4) at sv.c:5144 #12 0x0051b0fb in Perl_sv_free (my_perl=0x92516a8, sv=0x95bb4a4) at sv.c:5355 #13 0x00520202 in Perl_sv_unref_flags (my_perl=0x92516a8, sv=0x944a330, flags=1) at sv.c:7937 #14 0x00518ea3 in Perl_sv_force_normal_flags (my_perl=0x92516a8, sv=0x944a330, flags=1) at sv.c:4271 #15 0x0053a0ac in Perl_leave_scope (my_perl=0x92516a8, base=16) at scope.c:912 #16 0x005381bc in Perl_pop_scope (my_perl=0x95bc638) at scope.c:138 #17 0x00540ea7 in Perl_pp_return (my_perl=0x92516a8) at pp_ctl.c:1882 #18 0x004f2ead in Perl_runops_debug (my_perl=0x92516a8) at dump.c:1438 #19 0x004a29b9 in S_call_body (my_perl=0x92516a8, myop=0xbfefc1e0, is_eval=0) at perl.c: #20 0x004a2685 in Perl_call_sv (my_perl=0x92516a8, sv=0x0, flags=4) at perl.c:2140 #21 0x0817416e in perl_call_handler (sv=0x9509944, r=0x9567f7c, args=0x0) [...] usethreads=define use5005threads=undef useithreads=define [...] /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi I'd suggest to cleanup your perl's lib tree first, nuking all paths with 5.8.2, 5.8.1 and 5.8.0 in it. May be you get some binary incompatible module loaded which causes the crush. Your perl is thread-enabled, do you by chance spawn perl threads anywhere? Did you try building perl with -Uusethreads? -- __ 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
Re: red hat mod_perl build problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I won't do that because when develping code on such an old code base like 1.99.09 many things have been corrected/changed beside security holes closed in apache 2, ... . And mod_perl is changing the next release will probably shift everything from Apache into the Apache2-Namespace, so don't be suprised when working on not yet released code (and there has never been a final release of mp2) it won't work in later releases. You should at least work on the latest available codebase or even better the svn/cvs-trunk of it. Things have been fixed, the docs match the real code you use, ... . Tom Tom Caldwell schrieb: | Thanks for the reply, but I did some more digging and decided that | having 2 versions of perl installed (improperly) on my system was | probably the culprit. And since red hat provides a version of apache2 | and modperl 2 with perl 5.8.0, I decided to just go with that, even | though it is 1.5 years old (1.99.09)! | | Now if I could only get the Oracle client to install I will be back to | developing more code! | | Thanks, | | Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCUjXEkVPeOFLgZFIRAk4MAKC6JJGTL7n7C6ls++xuUBJ7fDNIngCgjrza OrdgzBPm3oI8dzv/gOW9sEI= =nItK -END PGP SIGNATURE-
