Re: mod_perl 1.30 seg faults

2010-10-30 Thread Brian Hirt
Thanks,

I don't know how I missed that.  I swear I checked that i was running the 
latest version,   /facepalm

--brian


On Oct 29, 2010, at 10:42 PM, Salvador Ortiz Garcia wrote:

> Hi Brian,
> 
> That bug was fixed in mod_perl 1.31.
> 
> Sure you can upgrade to last 1.x mod_perl.
> 
> Regards.
> 
> Salvador Ortiz.
> 
> On 10/29/2010 02:50 PM, Brian Hirt wrote:
>> I'm running a modperl installation with 1.30 and apache 1.3.42.
>> 
>> I recently upgrade from Ubuntu 9.04 to Ubuntu 10.04 and now every time a mod 
>> perl process shuts, it dumps core.   None of the application code changed.   
>> Maybe modperl isn't playing nicely with perl 5.10.1 (the old machine had 
>> 5.10.0)?  Luckily it's not causing a problem since the core dump doesn't 
>> happen during a regular request.  However it was fun watching the machine 
>> try to write 20gb of core dumps every few minutes
>> 
>> Does anyone have any idea why this is happening or what I can do?   I know 
>> 1.30 is old and apache 1.3.42 is end of life.Yes we will be upgrading to 
>> a newer version in the future, but I'm trying to find an interim solution 
>> over the next few months.
>> 
>> Any help is much appreciated.
>> 
>> Thanks!
>> Brian
>> 
>> Program terminated with signal 11, Segmentation fault.
>> #0  0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10
>> (gdb) bt
>> #0  0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10
>> #1  0x080842b0 in perl_shutdown (s=0xa09705c, p=0xd839a44) at mod_perl.c:284
>> #2  0x0808470a in perl_child_exit_cleanup (data=0xd839bd4) at mod_perl.c:940
>> #3  0x080c47dd in run_cleanups (c=0xd839bdc) at alloc.c:1703
>> #4  0x080c31e6 in ap_clear_pool (a=0xd839a44) at alloc.c:499
>> #5  0x080c325a in ap_destroy_pool (a=0xd839a44) at alloc.c:529
>> #6  0x080d12cd in clean_child_exit (code=0) at http_main.c:543
>> #7  0x080d340d in just_die (sig=15) at http_main.c:3258
>> #8
>> #9  0x4001d422 in __kernel_vsyscall ()
>> #10 0x402c68ab in semop () from /lib/tls/i686/cmov/libc.so.6
>> #11 0x080d14f7 in accept_mutex_on_sysvsem () at http_main.c:895
>> #12 0x080d4ac7 in child_main (child_num_arg=0) at http_main.c:4589
>> #13 0x080d51d4 in make_child (s=0xa09705c, slot=0, now=1287622896) at 
>> http_main.c:5055
>> #14 0x080d526a in startup_children (number_to_start=5) at http_main.c:5083
>> #15 0x080d5a54 in standalone_main (argc=1, argv=0xbf8ab984) at 
>> http_main.c:5430
>> #16 0x080d632a in main (argc=1, argv=0xbf8ab984) at http_main.c:5773
>> (gdb)
>> 
>>   
> 



Re: session module

2010-10-30 Thread Perrin Harkins
On Fri, Oct 29, 2010 at 4:23 PM, Lon Koenig  wrote:
> Are these susceptible to the cleartext cookie silliness exposed by FireSheep?

Well, Apache::Session doesn't handle cookies at all, so it's entirely
up to you how you want to deal with it, and CGI::Session doesn't
dictate whether or not your site uses SSL, so that is also up to you.

There is no way to prevent people from potentially seeing cookies (or
anything else) passed over a non-SSL network.  Sites that are
seriously concerned about this should use SSL.  Even sites that don't
use SSL should use cookies with some form of MAC and a reasonable
session timeout.

- Perrin


Re: [mp2] Test failures with new Perls (patch included)

2010-10-30 Thread Fred Moyer
On Fri, Oct 29, 2010 at 11:21 AM, Doug Schrag  wrote:
> Fred:
>
> All tests pass on 2.0-trunk, but 1.b. [sysdump()] and 1.c. below still
> apply.

Patches applied r1029211.  All tests still pass for me.  Can you
update your subversion checkout and test again?

> So when is the next stable release expected?? ;-)

It looks like we will be moving forward with the release very soon -
http://www.gossamer-threads.com/lists/modperl/dev/102192


>
> ---from t/logs/error_log
> [Fri Oct 29 13:47:33 2010] [error] [client 127.0.0.1] Use of uninitialized
> value in lc at /usr/local/src/apache/mod_perl-2.0/blib/lib/Apache2/Status.pm
> line 181.\n
>
> So when is the next stable release expected?? ;-)
>
> DLS
>
> -Original Message-
> From: Fred Moyer [mailto:f...@redhotpenguin.com]
> Sent: Fri 10/29/2010 1:30 PM
> To: Doug Schrag
> Cc: modperl@perl.apache.org
> Subject: Re: [mp2] Test failures with new Perls (patch included)
>
> Can you pull the latest svn trunk and test against that version?
> 2.0.4 is about two years old and has several fixes applied to it.
>
> http://perl.apache.org/download/source.html
>
> On Fri, Oct 29, 2010 at 10:19 AM, Doug Schrag  wrote:
>> -8<-- Start Bug Report 8<--
>> 1. Problem Description:
>>
>> [mp2] Test failures with new Perls (patch included)
>>
>> Ref Message: Build fail on Ubuntu Sep 29, 2010
>>
>> My issue is on a fresh install of CentOS 5.5
>>
>> a. Authentication tests fail with LWP 5.815 and later
>>    Only test failures, induced by change to LWP
>>    * New versions of LWP preserve credentials across fetches with the same
>>  user agent. Attempts to test failure after successful authentication
>>  don't succeed (authentication succeeds when it should fail)
>>    * Apache::TestRequest provides a way to reset the user agent
>>    * Patched t/hooks/authen_basic.t and t/hooks/authz.t to reset the agent
>>  appropriately
>>
>> b. Apache2::Status crashes server during B::Concise test
>>    * Actual problem when Apache2::Status::noh_b_terse calls
>> has($r,"terse")
>>    * Test via status_config() emits a warning when "StatusTerse" config
>>  option is undefined
>>    * Warnings are FATAL, so server crashes
>>    * Patched Apache2/Status.pm so status_config() and sysdump() won't emit
>>  warnings [2.0.5-dev looks already patched for status_config() only]
>>
>> c. B::Concise test won't perform unless StatusTerse is set to ON
>>    * Patched t/conf/extra.conf.in as follows:
>>
>>     
>>     PerlSetVar StatusTerse On
>>     
>>
>>    * eval of B::Concise::compile in Apache2::Status::noh_b_terse now
>> succeeds
>>    * t/logs/error_log then shows warning noise for the 'slow' test
>> (non-fatal)
>>    * Don't know if this is backward-compatible or entirely correct
>>
>> 2. Used Components and their Configuration:
>>
>> *** mod_perl version 2.04
>>
>> *** using /usr/local/src/apache/mod_perl-2.0.4/lib/Apache2/BuildConfig.pm
>>
>> *** Makefile.PL options:
>>   MP_APR_LIB => aprext
>>   MP_AP_PREFIX   => /usr/local/apache2
>>   MP_COMPAT_1X   => 1
>>   MP_GENERATE_XS => 1
>>   MP_LIBNAME => mod_perl
>>   MP_USE_DSO => 1
>>
>>
>> *** /usr/local/apache2/bin/httpd -V
>> Server version: Apache/2.2.17 (Unix)
>> Server built:   Oct 25 2010 16:25:37
>> Server's Module Magic Number: 20051115:25
>> Server loaded:  APR 1.4.2, APR-Util 1.3.10
>> Compiled using: APR 1.4.2, APR-Util 1.3.10
>> Architecture:   32-bit
>> Server MPM: Prefork
>>   threaded: no
>>     forked: yes (variable process count)
>> Server compiled with
>>  -D APACHE_MPM_DIR="server/mpm/prefork"
>>  -D APR_HAS_SENDFILE
>>  -D APR_HAS_MMAP
>>  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>>  -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 DYNAMIC_MODULE_LIMIT=128
>>  -D HTTPD_ROOT="/usr/local/apache2"
>>  -D SUEXEC_BIN="/usr/local/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"
>>
>> *** /usr/bin/ldd /usr/local/apache2/bin/httpd
>>     linux-gate.so.1 =>  (0x00ff)
>>     libm.so.6 => /lib/libm.so.6 (0x008c1000)
>>     libaprutil-1.so.0 => /usr/local/apache2/lib/libaprutil-1.so.0
>> (0x00f6f000)
>>     libexpat.so.0 => /usr/local/apache2/lib/libexpat.so.0 (0x00d04000)
>>     libapr-1.so.0 => /usr/local/apache2/lib/libapr-1.so.0 (0x00e0f000)
>>     libuuid.so.1 => /lib/libuuid.so.1 (0x03176000)
>>     librt.so.1 => /lib/librt.so.1 (0x0091c000)
>>     libcrypt.so.1 => /lib/libcrypt.so.1 (0x033c3000)
>>     libpthread.so.0 => /lib/libpthread.so.0 (0x008ec000)
>>     libdl.so.2 => /lib/libdl.so.2 (0x008ba000)
>>     libc.so.6 => /lib