You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/10/04 01:21:12 UTC

segfault in worker mpm

modperl-2.0 'make test' running under worker mpm (linux) always fails in 
t/filter/both_str_req_add.t and dumps core:

#0  0xffffe410 in ?? ()
(gdb) bt
#0  0xffffe410 in ?? ()
#1  0xbfffeff8 in ?? ()
#2  0x00000001 in ?? ()
#3  0xbfffeff7 in ?? ()
#4  0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0
#5  0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53
#6  0x080de523 in child_main (child_num_arg=0) at worker.c:1199
#7  0x080de6b1 in make_child (s=0x8144238, slot=0) at worker.c:1282
#8  0x080de747 in startup_children (number_to_start=1) at worker.c:1301
#9  0x080deebf in ap_mpm_run (_pconf=0x813d0a8, plog=0x81851c8, s=0x8144238)
     at worker.c:1616
#10 0x080e6700 in main (argc=9, argv=0xbffff1c4) at main.c:619

It looks like some threads problem. I have been smoking for almost 24 
hours, and it seems to happen totally randomly but always failing in 
t/filter/both_str_req_add.t. It deterministically fails when running a 
full modperl-2.0's 'make test', or least it did every time I've tried it.

One of the results SMOKE gave me was a nice:

t/compat/apache_file.t t/filter/both_str_req_add.t

but I was never able to reproduce it with these two tests when running 
them outside the smoking tool. Since then the other shortest sequence was 
of 65 tests:

t/api/show.t t/api/slurp_filename.t t/api/status.t t/api/sub_request.t 
t/api/uri.t t/apr-ext/base64.t t/apr-ext/bucket.t t/apr-ext/date.t 
t/apr-ext/finfo.t t/apr-ext/perlio.t t/apr-ext/pool.t t/apr-ext/string.t 
t/apr-ext/table.t t/apr-ext/threadmutex.t t/apr-ext/uri.t t/apr-ext/util.t 
t/apr-ext/uuid.t t/apr/base64.t t/apr/brigade.t t/apr/bucket.t 
t/apr/constants.t t/apr/date.t t/apr/finfo.t t/apr/flatten.t 
t/apr/ipsubnet.t t/apr/os.t t/apr/perlio.t t/apr/pool.t t/apr/sockaddr.t 
t/apr/socket.t t/apr/string.t t/apr/table.t t/apr/threadmutex.t 
t/apr/uri.t t/apr/util.t t/apr/uuid.t t/compat/apache.t 
t/compat/apache_file.t t/compat/apache_module.t t/compat/apache_table.t 
t/compat/apache_uri.t t/compat/apache_util.t t/compat/conn_authen.t 
t/compat/conn_rec.t t/compat/request.t t/compat/request_body.t 
t/compat/send_fd.t t/directive/cmdparms.t t/directive/env.t 
t/directive/perl.t t/directive/perldo.t t/directive/perlloadmodule.t 
t/directive/perlloadmodule2.t t/directive/perlloadmodule3.t 
t/directive/perlloadmodule4.t t/directive/perlloadmodule5.t 
t/directive/perlloadmodule6.t t/directive/perlmodule.t 
t/directive/perlrequire.t t/directive/pod.t t/directive/setupenv.t 
t/error/api.t t/error/bug.t t/error/runtime.t t/error/subreq.t 
t/filter/both_str_req_add.t

and it's still smoking trying to reduce it...

Any hints how to figure out the cause of the failure?

Used Components and their Configuration:

*** mod_perl version 1.9917

*** using /home/stas/apache.org/mp2-pool/lib/Apache/BuildConfig.pm

*** Makefile.PL options:
   MP_APR_LIB      => aprext
   MP_APXS         => /home/stas/httpd/worker/bin/apxs
   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_GTOP     =>


*** /home/stas/httpd/worker/bin/httpd -V
Server version: Apache/2.0.53-dev
Server built:   Sep 23 2004 23:13:14
Server's Module Magic Number: 20020903:9
Architecture:   32-bit
Server compiled with....
  -D APACHE_MPM_DIR="server/mpm/worker"
  -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 HTTPD_ROOT="/home/stas/httpd/worker"
  -D SUEXEC_BIN="/home/stas/httpd/worker/bin/suexec"
  -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
  -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/home/stas/httpd/worker/lib -lapr-0 -lrt -lm -lcrypt -lnsl  -lpthread -ldl
  -L/home/stas/httpd/worker/lib -laprutil-0 -lgdbm -ldb-4.0 -lexpat



*** /home/stas/perl/5.8.5-ithread/bin/perl5.8.5 -V
Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
   Platform:
     osname=linux, osvers=2.6.3-9mdk, archname=i686-linux-thread-multi
     uname='linux rabbit.stason.org 2.6.3-9mdk #1 fri apr 23 16:41:09 edt 
2004 i686 unknown unknown gnulinux '
     config_args='-des -Dprefix=/home/stas/perl/5.8.5-ithread -Dusethreads 
-Doptimize=-g -Duseshrplib -Dusedevel -Accflags=-DDEBUG_LEAKING_SCALARS'
     hint=recommended, useposix=true, d_sigaction=define
     usethreads=define use5005threads=undef useithreads=define 
usemultiplicity=define
     useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
     use64bitint=undef use64bitall=undef uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS 
-DDEBUG_LEAKING_SCALARS -DDEBUGGING -fno-strict-aliasing -pipe 
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-I/usr/include/gdbm',
     optimize='-g',
     cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS 
-DDEBUG_LEAKING_SCALARS -DDEBUGGING -fno-strict-aliasing -pipe 
-I/usr/local/include -I/usr/include/gdbm'
     ccversion='', gccversion='3.4.1 (Mandrakelinux (Cooker) 3.4.1-1mdk)', 
gccosandvers=''
     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
     alignbytes=4, prototype=define
   Linker and Libraries:
     ld='cc', ldflags =' -L/usr/local/lib'
     libpth=/usr/local/lib /lib /usr/lib
     libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
     perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
     libc=/lib/libc-2.3.3.so, so=so, useshrplib=true, libperl=libperl.so
     gnulibc_version='2.3.3'
   Dynamic Linking:
     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E 
-Wl,-rpath,/home/stas/perl/5.8.5-ithread/lib/5.8.5/i686-linux-thread-multi/CORE'
     cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
   Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS 
USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
   Built under linux
   Compiled at Jul 21 2004 15:06:23
   %ENV:
     PERLDOC_PAGER="less -R"
     PERL_LWP_USE_HTTP_10="1"
   @INC:
     /home/stas/perl/5.8.5-ithread/lib/5.8.5/i686-linux-thread-multi
     /home/stas/perl/5.8.5-ithread/lib/5.8.5
     /home/stas/perl/5.8.5-ithread/lib/site_perl/5.8.5/i686-linux-thread-multi
     /home/stas/perl/5.8.5-ithread/lib/site_perl/5.8.5
     /home/stas/perl/5.8.5-ithread/lib/site_perl
     .

*** Packages of interest status:

Apache::Request: -
CGI            : 3.05
LWP            : 5.800
mod_perl       : 1.2901, 1.9917





-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Cliff Woolley wrote:
> 
>> On Sun, 3 Oct 2004, Stas Bekman wrote:
>>
>>
>>> modperl-2.0 'make test' running under worker mpm (linux) always fails in
>>> t/filter/both_str_req_add.t and dumps core:
>>>
>>> #0  0xffffe410 in ?? ()
>>> (gdb) bt
>>> #0  0xffffe410 in ?? ()
>>> #1  0xbfffeff8 in ?? ()
>>> #2  0x00000001 in ?? ()
>>> #3  0xbfffeff7 in ?? ()
>>> #4  0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0
>>> #5  0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53
>>
>>
>>
>> My only guess of things to check out right off hand: Is the pipe that's
>> being read from still a valid fd?  (Maybe it somehow got closed elsewhere
>> by some other thread accidentally?  Such things have happened before...)
> 
> 
> I don't work with any pipes explicitly. This test just runs a few input 
> and output filters, all using bucket brigades API. The problem is that I 
> can't reproduce it as well,

s/as well/at will/

> other than running some 100 tests before 
> this happens, so I'm not sure how to debug that. So I was hoping that 
> someone has encountered this problem before and knew how to deal with that.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Cliff Woolley wrote:
> 
>> On Sun, 3 Oct 2004, Stas Bekman wrote:
>>
>>
>>> modperl-2.0 'make test' running under worker mpm (linux) always fails in
>>> t/filter/both_str_req_add.t and dumps core:
>>>
>>> #0  0xffffe410 in ?? ()
>>> (gdb) bt
>>> #0  0xffffe410 in ?? ()
>>> #1  0xbfffeff8 in ?? ()
>>> #2  0x00000001 in ?? ()
>>> #3  0xbfffeff7 in ?? ()
>>> #4  0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0
>>> #5  0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53
>>
>>
>>
>> My only guess of things to check out right off hand: Is the pipe that's
>> being read from still a valid fd?  (Maybe it somehow got closed elsewhere
>> by some other thread accidentally?  Such things have happened before...)
> 
> 
> I don't work with any pipes explicitly. This test just runs a few input 
> and output filters, all using bucket brigades API. The problem is that I 
> can't reproduce it as well,

s/as well/at will/

> other than running some 100 tests before 
> this happens, so I'm not sure how to debug that. So I was hoping that 
> someone has encountered this problem before and knew how to deal with that.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Cliff Woolley wrote:
> On Sun, 3 Oct 2004, Stas Bekman wrote:
> 
> 
>>modperl-2.0 'make test' running under worker mpm (linux) always fails in
>>t/filter/both_str_req_add.t and dumps core:
>>
>>#0  0xffffe410 in ?? ()
>>(gdb) bt
>>#0  0xffffe410 in ?? ()
>>#1  0xbfffeff8 in ?? ()
>>#2  0x00000001 in ?? ()
>>#3  0xbfffeff7 in ?? ()
>>#4  0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0
>>#5  0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53
> 
> 
> My only guess of things to check out right off hand: Is the pipe that's
> being read from still a valid fd?  (Maybe it somehow got closed elsewhere
> by some other thread accidentally?  Such things have happened before...)

I don't work with any pipes explicitly. This test just runs a few input 
and output filters, all using bucket brigades API. The problem is that I 
can't reproduce it as well, other than running some 100 tests before this 
happens, so I'm not sure how to debug that. So I was hoping that someone 
has encountered this problem before and knew how to deal with that.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Cliff Woolley wrote:
> On Sun, 3 Oct 2004, Stas Bekman wrote:
> 
> 
>>modperl-2.0 'make test' running under worker mpm (linux) always fails in
>>t/filter/both_str_req_add.t and dumps core:
>>
>>#0  0xffffe410 in ?? ()
>>(gdb) bt
>>#0  0xffffe410 in ?? ()
>>#1  0xbfffeff8 in ?? ()
>>#2  0x00000001 in ?? ()
>>#3  0xbfffeff7 in ?? ()
>>#4  0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0
>>#5  0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53
> 
> 
> My only guess of things to check out right off hand: Is the pipe that's
> being read from still a valid fd?  (Maybe it somehow got closed elsewhere
> by some other thread accidentally?  Such things have happened before...)

I don't work with any pipes explicitly. This test just runs a few input 
and output filters, all using bucket brigades API. The problem is that I 
can't reproduce it as well, other than running some 100 tests before this 
happens, so I'm not sure how to debug that. So I was hoping that someone 
has encountered this problem before and knew how to deal with that.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 3 Oct 2004, Stas Bekman wrote:

> modperl-2.0 'make test' running under worker mpm (linux) always fails in
> t/filter/both_str_req_add.t and dumps core:
>
> #0  0xffffe410 in ?? ()
> (gdb) bt
> #0  0xffffe410 in ?? ()
> #1  0xbfffeff8 in ?? ()
> #2  0x00000001 in ?? ()
> #3  0xbfffeff7 in ?? ()
> #4  0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0
> #5  0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53

My only guess of things to check out right off hand: Is the pipe that's
being read from still a valid fd?  (Maybe it somehow got closed elsewhere
by some other thread accidentally?  Such things have happened before...)

--Cliff

Re: segfault in worker mpm

Posted by Joe Orton <jo...@redhat.com>.
On Mon, Oct 04, 2004 at 10:03:51AM +0100, Joe Orton wrote:
> On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote:
> > modperl-2.0 'make test' running under worker mpm (linux) always fails in 
> > t/filter/both_str_req_add.t and dumps core:
> 
> That started failing for me on October 2nd with mod_perl HEAD against
> tip-of-2.0 on amd64 with the attached backtrace.

(with prefork, this is)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:

>> It's probably the same, it tries to load B::Deparse. I've recently 
>> added a few tests which were exercising that feature (there was a bug 
>> earlier in it). See t/hooks/TestHooks/inlined_handlers.pm if you 
>> remove that test, the problem disappears?

> It definetely seems like a bug caused somewhere deep within perl when we
> try to load B::Deparse, I've experienced the same segfault than all of you.
> But, I tried with this small patch (trying to make sure we are not loading
> B::Deparse when it's already there and loading it with no flags), and I
> still get a core, but a slightly differnt trace.

I think it is important to find out what change has triggered that problem.

The only related changes I can think of are:
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_callback.c?r1=1.79&r2=1.80&diff_format=h
 
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_callback.c?r1=1.75&r2=1.76&diff_format=h

The other possibility is that the problem was there all the time, but it 
was triggered only now by some new test, for example:
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/hooks/TestHooks/inlined_handlers.pm



-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Joe Orton wrote:
> 
>>On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote:
>>
>>
>>>modperl-2.0 'make test' running under worker mpm (linux) always fails in 
>>>t/filter/both_str_req_add.t and dumps core:
> [...]
> 
> I get the same trace as you then with worker. That's so much easier!!! 
> Before that I had no clue where to even start looking. Thanks Joe!
> 
> [...]
> 
>>#12 0x0000002a972d3550 in Perl_load_module (my_perl=0x2325090, flags=2536470192, 
>>    name=0x40000, ver=0x55) at op.c:3514
>>#13 0x0000002a97153d72 in modperl_coderef2text (my_perl=0x2325090, p=0x25a3578, 
>>    cv=0xc6d120) at modperl_util.c:715
> 
> 
> It's probably the same, it tries to load B::Deparse. I've recently added a 
> few tests which were exercising that feature (there was a bug earlier in 
> it). See t/hooks/TestHooks/inlined_handlers.pm if you remove that test, 
> the problem disappears?

It definetely seems like a bug caused somewhere deep within perl when we
try to load B::Deparse, I've experienced the same segfault than all of you.
But, I tried with this small patch (trying to make sure we are not loading
B::Deparse when it's already there and loading it with no flags), and I
still get a core, but a slightly differnt trace.

Index: src/modules/perl/modperl_util.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.83
diff -u -I$Id -r1.83 modperl_util.c
--- src/modules/perl/modperl_util.c     16 Sep 2004 16:36:29 -0000      1.83
+++ src/modules/perl/modperl_util.c     5 Oct 2004 19:21:24 -0000
@@ -712,10 +712,11 @@
       * notice that B::Deparse is not CPAN-updatable.
       * 0.61 is available starting from 5.8.0
       */
-    Perl_load_module(aTHX_ PERL_LOADMOD_NOIMPORT,
-                     newSVpvn("B::Deparse", 10),
-                     newSVnv(SvOBJECT((SV*)cv) ? 0.61 : 0.60));
-
+    if (!modperl_perl_module_loaded(aTHX_ "B::Deparse")) {
+        Perl_load_module(aTHX_ 0,
+                         newSVpvn("B::Deparse", 10),
+                         Nullsv);
+    }
      ENTER;
      SAVETMPS;

#0  0x005d07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00614266 in kill () from /lib/tls/libc.so.6
#2  0x080781b5 in sig_coredump (sig=11) at mpm_common.c:955
#3  <signal handler called>
#4  0x0028a28f in Perl_ck_svconst (my_perl=0xab53178, o=0xba2cdc8) at op.c:6310
#5  0x0027ea0d in Perl_newSVOP (my_perl=0xab53178, type=5, flags=0, sv=0xffffffff) at op.c:2849
#6  0x0027f69e in Perl_vload_module (my_perl=0xab53178, flags=0, name=0xb9e3b34, ver=0x0, args=0xf59613e0) at op.c:3085
#7  0x0027f52c in Perl_load_module (my_perl=0xab53178, flags=0, name=0xb9e3b34, ver=0x0) at op.c:3046
#8  0x001fe10c in modperl_coderef2text (my_perl=0xab53178, p=0xb92ca38, cv=0x9f50a80) at modperl_util.c:716
#9  0x001fa5a3 in modperl_handler_new_anon (my_perl=0xab53178, p=0xb92ca38, cv=0x9f50a80) at modperl_handler.c:76
#10 0x001fb2e2 in modperl_handler_new_from_sv (my_perl=0xab53178, p=0xb92ca38, sv=0x9f50a80) at modperl_handler.c:409
#11 0x00202e07 in modperl_filter_runtime_add (my_perl=0xab53178, r=0xb92ca70, c=0xb8b4a70, name=0x56a2b7 "MODPERL_REQUEST_OUTPUT",
     mode=MP_OUTPUT_FILTER_MODE, addfunc=0x8078d45 <ap_add_output_filter>, callback=0xb9f0d7c, type=0x56a2aa "OutputFilter")
     at modperl_filter.c:1157
#12 0x005663b8 in mpxs_Apache__RequestRec_add_output_filter (my_perl=0xab53178, r=0xb92ca70, callback=0xb9f0d7c)
     at Apache__Filter.h:244
#13 0x005689db in XS_Apache__RequestRec_add_output_filter (my_perl=0xab53178, cv=0xa4f1380) at Filter.xs:186


Then I also get _this_ core (reliably) from running t/hooks/push_handlers:

#0  0x005d07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00614266 in kill () from /lib/tls/libc.so.6
#2  0x080781b5 in sig_coredump (sig=11) at mpm_common.c:955
#3  <signal handler called>
#4  0x0027c297 in Perl_ck_svconst (my_perl=0xa170a60, o=0x9d00308) at op.c:6310
#5  0x00270a0d in Perl_newSVOP (my_perl=0xa170a60, type=5, flags=0, sv=0x64e1b1) at op.c:2849
#6  0x0027169e in Perl_vload_module (my_perl=0xa170a60, flags=0, name=0xa5659c8, ver=0x0, args=0xf59a33b0) at op.c:3085
#7  0x0027152c in Perl_load_module (my_perl=0xa170a60, flags=0, name=0xa5659c8, ver=0x0) at op.c:3046
#8  0x00aa110c in modperl_coderef2text (my_perl=0xa170a60, p=0xb249150, cv=0xb252638) at modperl_util.c:716
#9  0x00a9d5a3 in modperl_handler_new_anon (my_perl=0xa170a60, p=0xb249150, cv=0xb252638) at modperl_handler.c:76
#10 0x00a9e2e2 in modperl_handler_new_from_sv (my_perl=0xa170a60, p=0xb249150, sv=0xb252638) at modperl_handler.c:409
#11 0x00a9e38f in modperl_handler_push_handlers (my_perl=0xa170a60, p=0xb249150, handlers=0xb24e218, sv=0xa5659bc)
     at modperl_handler.c:425
#12 0x00a9e74d in modperl_handler_perl_add_handlers (my_perl=0xa170a60, r=0xb249188, c=0x0, s=0x9423e48, p=0xb249150,
     name=0x9872be0 "PerlResponseHandler", sv=0xa5659bc, action=MP_HANDLER_ACTION_PUSH) at modperl_handler.c:525
#13 0x00540cbf in mpxs_Apache__RequestRec_push_handlers (my_perl=0xa170a60, r=0xb249188, name=0x9872be0 "PerlResponseHandler",
     sv=0xa5659bc) at Apache__RequestUtil.h:21

-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote:
> 
>>modperl-2.0 'make test' running under worker mpm (linux) always fails in 
>>t/filter/both_str_req_add.t and dumps core:
> 
> 
> That started failing for me on October 2nd with mod_perl HEAD against
> tip-of-2.0 on amd64 with the attached backtrace.
> 
> 
>>#0  0xffffe410 in ?? ()
>>(gdb) bt
>>#0  0xffffe410 in ?? ()
>>#1  0xbfffeff8 in ?? ()
>>#2  0x00000001 in ?? ()
>>#3  0xbfffeff7 in ?? ()
>>#4  0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0
> 
> 
> That's likely not the thread that segfaulted, you want "thread apply all
> bt"...

Aha! Thanks for sharing that tip. I've assumed bt was showing the right bt :)

I get the same trace as you then with worker. That's so much easier!!! 
Before that I had no clue where to even start looking. Thanks Joe!

[...]
> #12 0x0000002a972d3550 in Perl_load_module (my_perl=0x2325090, flags=2536470192, 
>     name=0x40000, ver=0x55) at op.c:3514
> #13 0x0000002a97153d72 in modperl_coderef2text (my_perl=0x2325090, p=0x25a3578, 
>     cv=0xc6d120) at modperl_util.c:715

It's probably the same, it tries to load B::Deparse. I've recently added a 
few tests which were exercising that feature (there was a bug earlier in 
it). See t/hooks/TestHooks/inlined_handlers.pm if you remove that test, 
the problem disappears?

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Joe Orton <jo...@redhat.com>.
On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote:
> modperl-2.0 'make test' running under worker mpm (linux) always fails in 
> t/filter/both_str_req_add.t and dumps core:

That started failing for me on October 2nd with mod_perl HEAD against
tip-of-2.0 on amd64 with the attached backtrace.

> #0  0xffffe410 in ?? ()
> (gdb) bt
> #0  0xffffe410 in ?? ()
> #1  0xbfffeff8 in ?? ()
> #2  0x00000001 in ?? ()
> #3  0xbfffeff7 in ?? ()
> #4  0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0

That's likely not the thread that segfaulted, you want "thread apply all
bt"...

joe

Re: [Patch mp2] segfault in worker mpm

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> I'll give it a whirl tonight.  in truth, though, I forget exactly the
>> conditions that were causing it - I'm seeing a segfault now with
>> 2.0.47 (and
>> not 2.0.52) worker in the filter tests that is not reproducable when they
>> are run on their own.
> 
> 
> What filter test were failing ?
> 

attached is my test output - everything is fine until the point that the
output starts, and the last test in the output hangs indefintely (like for 6
hours until I killed it this morning).  unfortunately I didn't keep the
coredump today so I can't backtrace it.  and, as I mentioned, running t/TEST
t/filter passes just fine, so I don't know (and have little other info to
provide, other than this has been happening for at least a week, maybe up to
three).

I'll try to get more info tonight or tomorrow.

--Geoff

Re: [Patch mp2] segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.

Geoffrey Young wrote:
>>Before I go ahead and check that in, I'd like to at least get a bit more
>>feedback from the other folks that had been seeing this segfault, and
>>confirmation that this patch _does_ get rid of it.
> 
> 
> I'll give it a whirl tonight.  in truth, though, I forget exactly the
> conditions that were causing it - I'm seeing a segfault now with 2.0.47 (and
> not 2.0.52) worker in the filter tests that is not reproducable when they
> are run on their own.

What filter test were failing ?

> --Geoff
> 

-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: [Patch mp2] segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.

Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> 
> 
>>So, I guess I should just go ahead with my band-aid fix and we can worry
>>about the _real_ problem later then?
> 
> 
> +1

Band-aid applied!

-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: [Patch mp2] segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:

> So, I guess I should just go ahead with my band-aid fix and we can worry
> about the _real_ problem later then?

+1

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Patch mp2] segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.

Geoffrey Young wrote:
> 
> Geoffrey Young wrote:
> 
>>>Before I go ahead and check that in, I'd like to at least get a bit more
>>>feedback from the other folks that had been seeing this segfault, and
>>>confirmation that this patch _does_ get rid of it.
>>
>>
>>I'll give it a whirl tonight.
> 
> 
> whee!  all tests pass.

Good, I still see failures in ithreads.t on and off, but that's old
news

> nice work.

Bah, there is something seriously strange going on with Perl_load_module()
when provided with a version number. I tried to track it down extensively,
but I couldn't pin it down. Alomst certainly a Perl bug lurking somwehre
in there.

So, I guess I should just go ahead with my band-aid fix and we can worry
about the _real_ problem later then?

> --Geoff
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
> 
> 

-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: [Patch mp2] segfault in worker mpm

Posted by Geoffrey Young <ge...@modperlcookbook.org>.

Geoffrey Young wrote:
>>Before I go ahead and check that in, I'd like to at least get a bit more
>>feedback from the other folks that had been seeing this segfault, and
>>confirmation that this patch _does_ get rid of it.
> 
> 
> I'll give it a whirl tonight.

whee!  all tests pass.

nice work.

--Geoff

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Patch mp2] segfault in worker mpm

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Before I go ahead and check that in, I'd like to at least get a bit more
> feedback from the other folks that had been seeing this segfault, and
> confirmation that this patch _does_ get rid of it.

I'll give it a whirl tonight.  in truth, though, I forget exactly the
conditions that were causing it - I'm seeing a segfault now with 2.0.47 (and
not 2.0.52) worker in the filter tests that is not reproducable when they
are run on their own.

--Geoff

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Patch mp2] segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.

Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> 
>>I spent quite a lot of time trying to figure out the root cause of this 
>>problem
>>without much success. There is some strange interaction with 
>>Perl_load_module()
>>that's causing this segfault.
>>
>>I've rewritten that part to use eval_sv() instead and the segfault 
>>vanished for
>>me. As much as I'd like to nail down what the problem is with 
>>Perl_load_module(),
>>for now, I'd be comfortable with this temporary solution if it does 
>>solve the
>>problems for more people than just me.
> 
> 
> +1 to workaround and get _17 out. 

Before I go ahead and check that in, I'd like to at least get a bit more
feedback from the other folks that had been seeing this segfault, and
confirmation that this patch _does_ get rid of it.

> In parallel we will try to design a 
> better solution, not involving B::Deparse.

Absolutely

> We discussed things a bit on 
> irc, but need to put a "spec" out
> 

-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: [Patch mp2] segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> I spent quite a lot of time trying to figure out the root cause of this 
> problem
> without much success. There is some strange interaction with 
> Perl_load_module()
> that's causing this segfault.
> 
> I've rewritten that part to use eval_sv() instead and the segfault 
> vanished for
> me. As much as I'd like to nail down what the problem is with 
> Perl_load_module(),
> for now, I'd be comfortable with this temporary solution if it does 
> solve the
> problems for more people than just me.

+1 to workaround and get _17 out. In parallel we will try to design a 
better solution, not involving B::Deparse. We discussed things a bit on 
irc, but need to put a "spec" out


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


[Patch mp2] segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
I spent quite a lot of time trying to figure out the root cause of this problem
without much success. There is some strange interaction with Perl_load_module()
that's causing this segfault.

I've rewritten that part to use eval_sv() instead and the segfault vanished for
me. As much as I'd like to nail down what the problem is with Perl_load_module(),
for now, I'd be comfortable with this temporary solution if it does solve the
problems for more people than just me.

-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
With anon-subs we need cover three cases of anon-subs:

   $r->push_handlers(PerlTransHandler => sub { .... });
   $r->push_handlers(PerlTransHandler => eval 'sub { .... }');
   PerlTransHandler 'sub { ... }' # httpd.conf

Store the CODE refs in a special hash %ModPerl::__Subs::subs and store
the key names in the mod_perl struct. It should transparently work
with threads and resolves the problem with anon-subs.

If we have a situation where an interpreter that wants to run an
anon-sub can't find the key entry (if the interpreter has compiled it
and registered with mod_perl), we just croak explaining that in this
special case (and most people won't ever get here) one needs to
preload such modules at the server startup.

The only tricky parts is how to name the keys. We can't just increment
some counter like Symbol.pm does, since it's quite possible that two
interpreters will register different callbacks with the same key and
there will be a big trouble.

One solution is to generate the keys on the C side using an internal
counter. The only minus is that we will need to handle locking of that
resource which should be global to the process.

Another solution is to somehow include __FILE__:__LINE__ to uniquely
identify the anon-subs, but that will probably be hard to do.

Ideas?

meanwhile I'm trying to see whether this idea of %ModPerl::__Subs::subs 
will work.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
OK, finally I've found which changes have triggered the segfault. There 
were actually two triggers

1) On Sept 23: the move of 3 tests to vhosts [1]

2) On Sept 26: the change of the Taint mode [2]

both patches are reversed (i.e. these are the patches against the current 
cvs that make the segfault go away).

[1]

Index: t/hooks/trans.t
===================================================================
RCS file: /home/cvs/modperl-2.0/t/hooks/trans.t,v
retrieving revision 1.5
diff -u -r1.5 trans.t
--- t/hooks/trans.t	23 Sep 2004 01:44:10 -0000	1.5
+++ t/hooks/trans.t	9 Oct 2004 18:23:34 -0000
@@ -8,20 +8,15 @@
  use Apache2 ();
  use Apache::Const ':common';

-my $module = 'TestHooks::trans';
-Apache::TestRequest::module($module);
-my $path     = Apache::TestRequest::module2path($module);
-my $config   = Apache::Test::config();
-my $hostport = Apache::TestRequest::hostport($config);
-t_debug("connecting to $hostport");
-
  plan tests => 3;

  t_client_log_error_is_expected();
-ok t_cmp GET_RC("http://$hostport/nope"), NOT_FOUND;
+ok GET_RC('/nope') == NOT_FOUND;
+
+my $module = '/TestHooks/trans.pm';

-my $body = GET_BODY "http://$hostport/TestHooks/trans.pm";
+my $body = GET_BODY $module;

-ok $body =~ /package $module/;
+ok $body =~ /package TestHooks::trans/;

-ok GET_OK "http://$hostport/phooey";
+ok GET_OK '/phooey';
Index: t/hooks/TestHooks/init.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/init.pm,v
retrieving revision 1.6
diff -u -r1.6 init.pm
--- t/hooks/TestHooks/init.pm	23 Sep 2004 01:44:10 -0000	1.6
+++ t/hooks/TestHooks/init.pm	9 Oct 2004 18:23:34 -0000
@@ -54,15 +54,11 @@

  1;
  __DATA__
-<NoAutoConfig>
-  <VirtualHost TestHooks::init>
+PerlInitHandler TestHooks::init::second
+<Base>
      PerlModule      TestHooks::init
      PerlInitHandler TestHooks::init::first
-    <Location /TestHooks__init>
-        PerlInitHandler TestHooks::init::second
-        PerlResponseHandler TestHooks::init
-        PerlResponseHandler TestHooks::init::response
-        SetHandler modperl
-    </Location>
-  </VirtualHost>
-</NoAutoConfig>
+</Base>
+PerlResponseHandler TestHooks::init
+PerlResponseHandler TestHooks::init::response
+SetHandler modperl
Index: t/hooks/TestHooks/trans.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/trans.pm,v
retrieving revision 1.6
diff -u -r1.6 trans.pm
--- t/hooks/TestHooks/trans.pm	23 Sep 2004 01:44:11 -0000	1.6
+++ t/hooks/TestHooks/trans.pm	9 Oct 2004 18:23:34 -0000
@@ -37,12 +37,5 @@

  1;
  __DATA__
-<NoAutoConfig>
-  <VirtualHost TestHooks::trans>
-    PerlTransHandler TestHooks::trans
-    <Location /TestHooks__trans>
-        PerlResponseHandler Apache::TestHandler::ok1
-        SetHandler modperl
-    </Location>
-  </VirtualHost>
-</NoAutoConfig>
+PerlResponseHandler Apache::TestHandler::ok1
+SetHandler modperl
Index: t/modules/proxy.t
===================================================================
RCS file: /home/cvs/modperl-2.0/t/modules/proxy.t,v
retrieving revision 1.5
diff -u -r1.5 proxy.t
--- t/modules/proxy.t	23 Sep 2004 01:44:11 -0000	1.5
+++ t/modules/proxy.t	9 Oct 2004 18:23:34 -0000
@@ -3,19 +3,14 @@

  use Apache::Test;
  use Apache::TestUtil;
-use Apache::TestRequest;

-my $module = 'TestModules::proxy';
+use Apache::TestRequest;

-Apache::TestRequest::module($module);
-my $path     = Apache::TestRequest::module2path($module);
-my $config   = Apache::Test::config();
-my $hostport = Apache::TestRequest::hostport($config);
-t_debug("connecting to $hostport");
+my $location = "/TestModules__proxy";

  plan tests => 1, (need_module('proxy') &&
                    need_access);

  my $expected = "ok";
-my $received = GET_BODY_ASSERT "http://$hostport/$path";;
+my $received = GET_BODY_ASSERT $location;
  ok t_cmp($received, $expected, "internally proxified request");
Index: t/response/TestModules/proxy.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/response/TestModules/proxy.pm,v
retrieving revision 1.6
diff -u -r1.6 proxy.pm
--- t/response/TestModules/proxy.pm	23 Sep 2004 01:44:11 -0000	1.6
+++ t/response/TestModules/proxy.pm	9 Oct 2004 18:23:34 -0000
@@ -43,7 +43,6 @@
  1;
  __END__
  <NoAutoConfig>
-  <VirtualHost TestModules::proxy>
      <IfModule mod_proxy.c>
          <Proxy http://@servername@:@port@/*>
              <IfModule @ACCESS_MODULE@>
@@ -60,6 +59,5 @@
              PerlResponseHandler TestModules::proxy::response
          </Location>
      </IfModule>
-  </VirtualHost>
  </NoAutoConfig>

Index: t/response/TestUser/rewrite.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/response/TestUser/rewrite.pm,v
retrieving revision 1.3
diff -u -r1.3 rewrite.pm
--- t/response/TestUser/rewrite.pm	23 Sep 2004 01:44:11 -0000	1.3
+++ t/response/TestUser/rewrite.pm	9 Oct 2004 18:23:34 -0000
@@ -62,7 +62,6 @@
  1;
  __END__
  <NoAutoConfig>
-  <VirtualHost TestUser::rewrite>
      PerlModule              TestUser::rewrite
      PerlTransHandler        TestUser::rewrite::trans
      PerlMapToStorageHandler TestUser::rewrite::map2storage
@@ -70,6 +69,5 @@
          SetHandler modperl
          PerlResponseHandler TestUser::rewrite::response
      </Location>
-  </VirtualHost>
  </NoAutoConfig>



[2]

Index: src/modules/perl/modperl_callback.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_callback.c,v
retrieving revision 1.80
diff -u -r1.80 modperl_callback.c
--- src/modules/perl/modperl_callback.c	30 Sep 2004 03:30:29 -0000	1.80
+++ src/modules/perl/modperl_callback.c	9 Oct 2004 18:23:34 -0000
@@ -22,23 +22,8 @@
      I32 flags = G_EVAL|G_SCALAR;
      dSP;
      int count, status = OK;
-    int tainted_orig = PL_tainted;

-    /* handler callbacks shouldn't affect each other's taintedness
-     * state, so start every callback with a clear record and restore
-     * at the end. one of the main problems we are trying to solve is
-     * that when modperl_croak called (which calls perl's
-     * croak(Nullch) to throw an error object) it leaves the
-     * interprter in the tainted state (which supposedly will be fixed
-     * in 5.8.6) which later affects other callbacks that call eval,
-     * etc, which triggers perl crash with:
-     * Insecure dependency in eval while running setgid.
-     * Callback called exit.
-     */
-    TAINT_NOT;
-
      if ((status = modperl_handler_resolve(aTHX_ &handler, p, s)) != OK) {
-        PL_tainted = tainted_orig;
          return status;
      }

@@ -123,13 +108,28 @@
          else {
              SV *status_sv = POPs;

-            if (status_sv == &PL_sv_undef) {
+            if (SvIOK(status_sv)) {
+                /* normal IV return (e.g., Apache::OK) */
+                status = SvIVX(status_sv);
+            }
+            else if (status_sv == &PL_sv_undef) {
                  /* ModPerl::Util::exit() and Perl_croak internally
                   * arrange to return PL_sv_undef with G_EVAL|G_SCALAR */
                  status = OK;
              }
-            else {
+            else if (SvPOK(status_sv)) {
+                /* PV return that ought to be treated as IV ("0") */
                  status = SvIVx(status_sv);
+                MP_TRACE_h(MP_FUNC,
+                           "coercing handler %s's return value '%s' into %d",
+                           handler->name, SvPV_nolen(status_sv), status);
+            }
+            else {
+                /* any other return types are considered as errors */
+                status = HTTP_INTERNAL_SERVER_ERROR;
+                ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
+                             "handler %s didn't return a valid return 
value!",
+                             handler->name);
              }
          }

@@ -148,9 +148,7 @@
              apr_table_set(r->notes, "error-notes", SvPV_nolen(ERRSV));
          }
      }
-
-    PL_tainted = tainted_orig;
-
+
      return status;
  }


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Stas Bekman wrote:
> 
>> Philippe M. Chiasson wrote:
>>
>>>
>>>
>>> Stas Bekman wrote:
>>>
>>>> I did some binary search and found that:
>>>>
>>>> mp2-20040922 - no core
>>>> mp2-20040923 - core
>>>>
>>>> So we need to diff these two checkouts...
>>>
>>>
>>>
>>>
>>> For a start, I've got these changes exposed in between those 2 dates:
>>>
>>> http://www.apache.org/~gozer/mp2/2004-09-22+23/
>>
>>
>>
>> That's a handy output. I'll try applying each separately to see which 
>> one was the trigger.
> 
> 
> For some reason, your output doesn't match mine. for me the difference 
> between 22nd and 23 starts from 3428 [1] and goes into the next day, 
> which is not included in your output:
> 
> [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch
> 
> but I think I'm getting there....

It seems that this patch applied as reversed to the checkout from 23 Sept 
resolves the segfault in t/filter/both_str_req_add.t. As you can see all 
the changes are in creating new Vhosts entries.

However this doesn't resolve the current cvs problem, as I think there 
were more entries added after Sept 23th, that cause the latest one.

diff -ru --exclude=CVS t/hooks/TestHooks/init.pm t/hooks/TestHooks/init.pm
--- t/hooks/TestHooks/init.pm	2003-08-11 16:34:22.000000000 -0400
+++ t/hooks/TestHooks/init.pm	2004-09-22 21:44:10.000000000 -0400
@@ -54,11 +54,15 @@

  1;
  __DATA__
-PerlInitHandler TestHooks::init::second
-<Base>
+<NoAutoConfig>
+  <VirtualHost TestHooks::init>
      PerlModule      TestHooks::init
      PerlInitHandler TestHooks::init::first
-</Base>
-PerlResponseHandler TestHooks::init
-PerlResponseHandler TestHooks::init::response
-SetHandler modperl
+    <Location /TestHooks__init>
+        PerlInitHandler TestHooks::init::second
+        PerlResponseHandler TestHooks::init
+        PerlResponseHandler TestHooks::init::response
+        SetHandler modperl
+    </Location>
+  </VirtualHost>
+</NoAutoConfig>
diff -ru --exclude=CVS t/response/TestUser/rewrite.pm 
t/response/TestUser/rewrite.pm
--- t/response/TestUser/rewrite.pm	2004-07-09 17:52:49.000000000 -0400
+++ t/response/TestUser/rewrite.pm	2004-09-22 21:44:11.000000000 -0400
@@ -62,6 +62,7 @@
  1;
  __END__
  <NoAutoConfig>
+  <VirtualHost TestUser::rewrite>
      PerlModule              TestUser::rewrite
      PerlTransHandler        TestUser::rewrite::trans
      PerlMapToStorageHandler TestUser::rewrite::map2storage
@@ -69,5 +70,6 @@
          SetHandler modperl
          PerlResponseHandler TestUser::rewrite::response
      </Location>
+  </VirtualHost>
  </NoAutoConfig>

diff -ru --exclude=CVS t/modules/proxy.t t/modules/proxy.t
--- t/modules/proxy.t	2004-08-03 12:16:22.000000000 -0400
+++ t/modules/proxy.t	2004-09-22 21:44:11.000000000 -0400
@@ -3,14 +3,19 @@

  use Apache::Test;
  use Apache::TestUtil;
-
  use Apache::TestRequest;

-my $location = "/TestModules__proxy";
+my $module = 'TestModules::proxy';
+
+Apache::TestRequest::module($module);
+my $path     = Apache::TestRequest::module2path($module);
+my $config   = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");

  plan tests => 1, (need_module('proxy') &&
                    need_access);

  my $expected = "ok";
-my $received = GET_BODY_ASSERT $location;
+my $received = GET_BODY_ASSERT "http://$hostport/$path";;
  ok t_cmp($received, $expected, "internally proxified request");
diff -ru --exclude=CVS t/response/TestModules/proxy.pm 
t/response/TestModules/proxy.pm
--- t/response/TestModules/proxy.pm	2004-07-09 04:01:21.000000000 -0400
+++ t/response/TestModules/proxy.pm	2004-09-22 21:44:11.000000000 -0400
@@ -43,6 +43,7 @@
  1;
  __END__
  <NoAutoConfig>
+  <VirtualHost TestModules::proxy>
      <IfModule mod_proxy.c>
          <Proxy http://@servername@:@port@/*>
              <IfModule @ACCESS_MODULE@>
@@ -59,5 +60,6 @@
              PerlResponseHandler TestModules::proxy::response
          </Location>
      </IfModule>
+  </VirtualHost>
  </NoAutoConfig>

diff -ru --exclude=CVS t/hooks/TestHooks/trans.pm t/hooks/TestHooks/trans.pm
--- t/hooks/TestHooks/trans.pm	2003-04-18 02:18:58.000000000 -0400
+++ t/hooks/TestHooks/trans.pm	2004-09-22 21:44:11.000000000 -0400
@@ -37,5 +37,12 @@

  1;
  __DATA__
-PerlResponseHandler Apache::TestHandler::ok1
-SetHandler modperl
+<NoAutoConfig>
+  <VirtualHost TestHooks::trans>
+    PerlTransHandler TestHooks::trans
+    <Location /TestHooks__trans>
+        PerlResponseHandler Apache::TestHandler::ok1
+        SetHandler modperl
+    </Location>
+  </VirtualHost>
+</NoAutoConfig>

diff -ru --exclude=CVS t/hooks/trans.t t/hooks/trans.t
--- t/hooks/trans.t	2003-03-31 23:39:30.000000000 -0500
+++ t/hooks/trans.t	2004-09-22 21:44:10.000000000 -0400
@@ -8,15 +8,20 @@
  use Apache2 ();
  use Apache::Const ':common';

+my $module = 'TestHooks::trans';
+Apache::TestRequest::module($module);
+my $path     = Apache::TestRequest::module2path($module);
+my $config   = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
+
  plan tests => 3;

  t_client_log_error_is_expected();
-ok GET_RC('/nope') == NOT_FOUND;
-
-my $module = '/TestHooks/trans.pm';
+ok t_cmp GET_RC("http://$hostport/nope"), NOT_FOUND;

-my $body = GET_BODY $module;
+my $body = GET_BODY "http://$hostport/TestHooks/trans.pm";

-ok $body =~ /package TestHooks::trans/;
+ok $body =~ /package $module/;

-ok GET_OK '/phooey';
+ok GET_OK "http://$hostport/phooey";



-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Stas Bekman wrote:
> 
>> Philippe M. Chiasson wrote:
>>
>>>
>>>
>>> Stas Bekman wrote:
>>>
>>>> I did some binary search and found that:
>>>>
>>>> mp2-20040922 - no core
>>>> mp2-20040923 - core
>>>>
>>>> So we need to diff these two checkouts...
>>>
>>>
>>>
>>>
>>> For a start, I've got these changes exposed in between those 2 dates:
>>>
>>> http://www.apache.org/~gozer/mp2/2004-09-22+23/
>>
>>
>>
>> That's a handy output. I'll try applying each separately to see which 
>> one was the trigger.
> 
> 
> For some reason, your output doesn't match mine. for me the difference 
> between 22nd and 23 starts from 3428 [1] and goes into the next day, 
> which is not included in your output:
> 
> [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch
> 
> but I think I'm getting there....

It seems that this patch applied as reversed to the checkout from 23 Sept 
resolves the segfault in t/filter/both_str_req_add.t. As you can see all 
the changes are in creating new Vhosts entries.

However this doesn't resolve the current cvs problem, as I think there 
were more entries added after Sept 23th, that cause the latest one.

diff -ru --exclude=CVS t/hooks/TestHooks/init.pm t/hooks/TestHooks/init.pm
--- t/hooks/TestHooks/init.pm	2003-08-11 16:34:22.000000000 -0400
+++ t/hooks/TestHooks/init.pm	2004-09-22 21:44:10.000000000 -0400
@@ -54,11 +54,15 @@

  1;
  __DATA__
-PerlInitHandler TestHooks::init::second
-<Base>
+<NoAutoConfig>
+  <VirtualHost TestHooks::init>
      PerlModule      TestHooks::init
      PerlInitHandler TestHooks::init::first
-</Base>
-PerlResponseHandler TestHooks::init
-PerlResponseHandler TestHooks::init::response
-SetHandler modperl
+    <Location /TestHooks__init>
+        PerlInitHandler TestHooks::init::second
+        PerlResponseHandler TestHooks::init
+        PerlResponseHandler TestHooks::init::response
+        SetHandler modperl
+    </Location>
+  </VirtualHost>
+</NoAutoConfig>
diff -ru --exclude=CVS t/response/TestUser/rewrite.pm 
t/response/TestUser/rewrite.pm
--- t/response/TestUser/rewrite.pm	2004-07-09 17:52:49.000000000 -0400
+++ t/response/TestUser/rewrite.pm	2004-09-22 21:44:11.000000000 -0400
@@ -62,6 +62,7 @@
  1;
  __END__
  <NoAutoConfig>
+  <VirtualHost TestUser::rewrite>
      PerlModule              TestUser::rewrite
      PerlTransHandler        TestUser::rewrite::trans
      PerlMapToStorageHandler TestUser::rewrite::map2storage
@@ -69,5 +70,6 @@
          SetHandler modperl
          PerlResponseHandler TestUser::rewrite::response
      </Location>
+  </VirtualHost>
  </NoAutoConfig>

diff -ru --exclude=CVS t/modules/proxy.t t/modules/proxy.t
--- t/modules/proxy.t	2004-08-03 12:16:22.000000000 -0400
+++ t/modules/proxy.t	2004-09-22 21:44:11.000000000 -0400
@@ -3,14 +3,19 @@

  use Apache::Test;
  use Apache::TestUtil;
-
  use Apache::TestRequest;

-my $location = "/TestModules__proxy";
+my $module = 'TestModules::proxy';
+
+Apache::TestRequest::module($module);
+my $path     = Apache::TestRequest::module2path($module);
+my $config   = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");

  plan tests => 1, (need_module('proxy') &&
                    need_access);

  my $expected = "ok";
-my $received = GET_BODY_ASSERT $location;
+my $received = GET_BODY_ASSERT "http://$hostport/$path";;
  ok t_cmp($received, $expected, "internally proxified request");
diff -ru --exclude=CVS t/response/TestModules/proxy.pm 
t/response/TestModules/proxy.pm
--- t/response/TestModules/proxy.pm	2004-07-09 04:01:21.000000000 -0400
+++ t/response/TestModules/proxy.pm	2004-09-22 21:44:11.000000000 -0400
@@ -43,6 +43,7 @@
  1;
  __END__
  <NoAutoConfig>
+  <VirtualHost TestModules::proxy>
      <IfModule mod_proxy.c>
          <Proxy http://@servername@:@port@/*>
              <IfModule @ACCESS_MODULE@>
@@ -59,5 +60,6 @@
              PerlResponseHandler TestModules::proxy::response
          </Location>
      </IfModule>
+  </VirtualHost>
  </NoAutoConfig>

diff -ru --exclude=CVS t/hooks/TestHooks/trans.pm t/hooks/TestHooks/trans.pm
--- t/hooks/TestHooks/trans.pm	2003-04-18 02:18:58.000000000 -0400
+++ t/hooks/TestHooks/trans.pm	2004-09-22 21:44:11.000000000 -0400
@@ -37,5 +37,12 @@

  1;
  __DATA__
-PerlResponseHandler Apache::TestHandler::ok1
-SetHandler modperl
+<NoAutoConfig>
+  <VirtualHost TestHooks::trans>
+    PerlTransHandler TestHooks::trans
+    <Location /TestHooks__trans>
+        PerlResponseHandler Apache::TestHandler::ok1
+        SetHandler modperl
+    </Location>
+  </VirtualHost>
+</NoAutoConfig>

diff -ru --exclude=CVS t/hooks/trans.t t/hooks/trans.t
--- t/hooks/trans.t	2003-03-31 23:39:30.000000000 -0500
+++ t/hooks/trans.t	2004-09-22 21:44:10.000000000 -0400
@@ -8,15 +8,20 @@
  use Apache2 ();
  use Apache::Const ':common';

+my $module = 'TestHooks::trans';
+Apache::TestRequest::module($module);
+my $path     = Apache::TestRequest::module2path($module);
+my $config   = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
+
  plan tests => 3;

  t_client_log_error_is_expected();
-ok GET_RC('/nope') == NOT_FOUND;
-
-my $module = '/TestHooks/trans.pm';
+ok t_cmp GET_RC("http://$hostport/nope"), NOT_FOUND;

-my $body = GET_BODY $module;
+my $body = GET_BODY "http://$hostport/TestHooks/trans.pm";

-ok $body =~ /package TestHooks::trans/;
+ok $body =~ /package $module/;

-ok GET_OK '/phooey';
+ok GET_OK "http://$hostport/phooey";



-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:

>> For some reason, your output doesn't match mine. for me the difference 
>> between 22nd and 23 starts from 3428 [1] and goes into the next day, 
>> which is not included in your output:
>>
>> [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch
> 
> 
> I've apparently been bitten by a timezone problem, I've updated that 
> output to reflect more stuff
> rather than less.

Thanks, Philippe. Could you please write a quick writeup on how to 
get/setup that tool that you've used (including the issue of TZ), here:
http://perl.apache.org/docs/2.0/devel/debug/c.html? Thanks!

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:

>> For some reason, your output doesn't match mine. for me the difference 
>> between 22nd and 23 starts from 3428 [1] and goes into the next day, 
>> which is not included in your output:
>>
>> [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch
> 
> 
> I've apparently been bitten by a timezone problem, I've updated that 
> output to reflect more stuff
> rather than less.

Thanks, Philippe. Could you please write a quick writeup on how to 
get/setup that tool that you've used (including the issue of TZ), here:
http://perl.apache.org/docs/2.0/devel/debug/c.html? Thanks!

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:

> Stas Bekman wrote:
>
>> Philippe M. Chiasson wrote:
>>
>>>
>>>
>>> Stas Bekman wrote:
>>>
>>>> I did some binary search and found that:
>>>>
>>>> mp2-20040922 - no core
>>>> mp2-20040923 - core
>>>>
>>>> So we need to diff these two checkouts...
>>>
>>>
>>>
>>>
>>> For a start, I've got these changes exposed in between those 2 dates:
>>>
>>> http://www.apache.org/~gozer/mp2/2004-09-22+23/
>>
>>
>>
>> That's a handy output. I'll try applying each separately to see which 
>> one was the trigger.
>
>
> For some reason, your output doesn't match mine. for me the difference 
> between 22nd and 23 starts from 3428 [1] and goes into the next day, 
> which is not included in your output:
>
> [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch

I've apparently been bitten by a timezone problem, I've updated that 
output to reflect more stuff
rather than less.

> but I think I'm getting there....
>
>


Re: segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:

> Stas Bekman wrote:
>
>> Philippe M. Chiasson wrote:
>>
>>>
>>>
>>> Stas Bekman wrote:
>>>
>>>> I did some binary search and found that:
>>>>
>>>> mp2-20040922 - no core
>>>> mp2-20040923 - core
>>>>
>>>> So we need to diff these two checkouts...
>>>
>>>
>>>
>>>
>>> For a start, I've got these changes exposed in between those 2 dates:
>>>
>>> http://www.apache.org/~gozer/mp2/2004-09-22+23/
>>
>>
>>
>> That's a handy output. I'll try applying each separately to see which 
>> one was the trigger.
>
>
> For some reason, your output doesn't match mine. for me the difference 
> between 22nd and 23 starts from 3428 [1] and goes into the next day, 
> which is not included in your output:
>
> [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch

I've apparently been bitten by a timezone problem, I've updated that 
output to reflect more stuff
rather than less.

> but I think I'm getting there....
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> 
>>
>>
>> Stas Bekman wrote:
>>
>>> I did some binary search and found that:
>>>
>>> mp2-20040922 - no core
>>> mp2-20040923 - core
>>>
>>> So we need to diff these two checkouts...
>>
>>
>>
>> For a start, I've got these changes exposed in between those 2 dates:
>>
>> http://www.apache.org/~gozer/mp2/2004-09-22+23/
> 
> 
> That's a handy output. I'll try applying each separately to see which 
> one was the trigger.

For some reason, your output doesn't match mine. for me the difference 
between 22nd and 23 starts from 3428 [1] and goes into the next day, which 
is not included in your output:

[1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch

but I think I'm getting there....


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> 
>>
>>
>> Stas Bekman wrote:
>>
>>> I did some binary search and found that:
>>>
>>> mp2-20040922 - no core
>>> mp2-20040923 - core
>>>
>>> So we need to diff these two checkouts...
>>
>>
>>
>> For a start, I've got these changes exposed in between those 2 dates:
>>
>> http://www.apache.org/~gozer/mp2/2004-09-22+23/
> 
> 
> That's a handy output. I'll try applying each separately to see which 
> one was the trigger.

For some reason, your output doesn't match mine. for me the difference 
between 22nd and 23 starts from 3428 [1] and goes into the next day, which 
is not included in your output:

[1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch

but I think I'm getting there....


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> 
> 
> Stas Bekman wrote:
> 
>> I did some binary search and found that:
>>
>> mp2-20040922 - no core
>> mp2-20040923 - core
>>
>> So we need to diff these two checkouts...
> 
> 
> For a start, I've got these changes exposed in between those 2 dates:
> 
> http://www.apache.org/~gozer/mp2/2004-09-22+23/

That's a handy output. I'll try applying each separately to see which one 
was the trigger.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> 
> 
> Stas Bekman wrote:
> 
>> I did some binary search and found that:
>>
>> mp2-20040922 - no core
>> mp2-20040923 - core
>>
>> So we need to diff these two checkouts...
> 
> 
> For a start, I've got these changes exposed in between those 2 dates:
> 
> http://www.apache.org/~gozer/mp2/2004-09-22+23/

That's a handy output. I'll try applying each separately to see which one 
was the trigger.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.

Stas Bekman wrote:
> I did some binary search and found that:
> 
> mp2-20040922 - no core
> mp2-20040923 - core
> 
> So we need to diff these two checkouts...

For a start, I've got these changes exposed in between those 2 dates:

http://www.apache.org/~gozer/mp2/2004-09-22+23/

-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.

Stas Bekman wrote:
> I did some binary search and found that:
> 
> mp2-20040922 - no core
> mp2-20040923 - core
> 
> So we need to diff these two checkouts...

For a start, I've got these changes exposed in between those 2 dates:

http://www.apache.org/~gozer/mp2/2004-09-22+23/

-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
I did some binary search and found that:

mp2-20040922 - no core
mp2-20040923 - core

So we need to diff these two checkouts...

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: segfault in worker mpm

Posted by Stas Bekman <st...@stason.org>.
I did some binary search and found that:

mp2-20040922 - no core
mp2-20040923 - core

So we need to diff these two checkouts...

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: segfault in worker mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
I believe I have finally found what is going on, somewhat.

Seems that calling Perl_load_module(aTHX_, flags, SV *name, SV *version, ...)
should be safe, but it seems something is strange in how it's dealing with
va_arg arguments.

I've found that this patch seems to get rid of that segfault on my setup (but
t/filter/both_str_req_add.t still fails occasionally)

Index: src/modules/perl/modperl_util.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.83
diff -u -I$Id -r1.83 modperl_util.c
--- src/modules/perl/modperl_util.c     16 Sep 2004 16:36:29 -0000      1.83
+++ src/modules/perl/modperl_util.c     6 Oct 2004 20:48:10 -0000
@@ -714,7 +714,8 @@
       */
      Perl_load_module(aTHX_ PERL_LOADMOD_NOIMPORT,
                       newSVpvn("B::Deparse", 10),
-                     newSVnv(SvOBJECT((SV*)cv) ? 0.61 : 0.60));
+                     newSVnv(SvOBJECT((SV*)cv) ? 0.61 : 0.60),
+                     Nullsv);

      ENTER;
      SAVETMPS;


P.S. I've attached a small module that demonstrates the segv behaviour