You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2004/10/01 00:53:28 UTC
t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
1. Problem Description:
Current cvs segfaults w/perl 5.8.5, not reproducible with 5.8.4:
#0 0x0000002a9682334b in Perl_safesysmalloc (size=24) at util.c:78
78 my_exit(1);
This may be an ithread-related bug in 5.8.5, not mp2.
% t/TEST -v t/directive/cmdparms.t
...
t/directive/cmdparms....request has failed (the response code was: 500)
see t/logs/error_log for more details
t/directive/cmdparms....dubious
Test returned status 255 (wstat 65280, 0xff00)
FAILED--1 test script could be run, alas--no output ever seen
[warning] server localhost.localdomain:9500 shutdown
[ error] error running tests (please examine t/logs/error_log)
[ error] oh crap, server dumped core
% cat t/log/error_log
Thu Sep 30 18:44:34 2004] [info] mod_unique_id: using ip addr 192.168.1.5
END in modperl_extra.pl, pid=18025
END in modperl_extra.pl, pid=18025
[Thu Sep 30 18:44:36 2004] [notice] Digest: generating secret for digest authent
ication ...
[Thu Sep 30 18:44:36 2004] [notice] Digest: done
[Thu Sep 30 18:44:36 2004] [info] mod_unique_id: using ip addr 192.168.1.5
[Thu Sep 30 18:44:38 2004] [info] Child process pid=18046 is exiting
END in modperl_extra.pl, pid=18046
END in modperl_extra.pl, pid=18046
[Thu Sep 30 18:44:38 2004] [info] removed PID file /home/smoke/src/apache/modper
l-2.0/t/logs/httpd.pid (pid=18029)
[Thu Sep 30 18:44:38 2004] [notice] caught SIGTERM, shutting down
END in modperl_extra.pl, pid=18029
END in modperl_extra.pl, pid=18029
2. Used Components and their Configuration:
*** mod_perl version 1.9917
*** using /home/smoke/src/apache/modperl-2.0/lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APR_LIB => aprext
MP_APXS => /home/smoke/apache/httpd-worker/bin/apxs
MP_COMPAT_1X => 1
MP_DEBUG => 1
MP_GENERATE_XS => 1
MP_INST_APACHE2 => 1
MP_LIBNAME => mod_perl
MP_MAINTAINER => 1
MP_TRACE => 1
MP_USE_DSO => 1
*** /home/smoke/apache/httpd-worker/bin/httpd -V
Server version: Apache/2.1.0-dev
Server built: Sep 28 2004 15:52:23
Server's Module Magic Number: 20040425:1
Architecture: 64-bit
Server MPM: Worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
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/smoke/apache/httpd-worker"
-D SUEXEC_BIN="/home/smoke/apache/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/smoke/lib -lapr-1 -lrt -lcrypt -lpthread -ldl
-L/home/smoke/lib -laprutil-1 -lgdbm -ldb-4.2 -lexpat
*** /opt/perl/bin/perl -V
Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
Platform:
osname=linux, osvers=2.6.1-rc2, archname=x86_64-linux-thread-multi
uname='linux gemini 2.6.1-rc2 #17 smp sun feb 15 12:19:49 est 2004 x86_64 gnulinux '
config_args='-Dprefix=/opt/perl -Dusethreads -Duseshrplib -Doptimize=-O2 -g-des'
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=define use64bitall=define uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='3.3.4 (Debian 1:3.3.4-13)', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, 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.2.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/opt/perl/lib/5.8.5/x86_64-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_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Sep 30 2004 18:20:53
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/opt/perl/lib/5.8.5/x86_64-linux-thread-multi
/opt/perl/lib/5.8.5
/opt/perl/lib/site_perl/5.8.5/x86_64-linux-thread-multi
/opt/perl/lib/site_perl/5.8.5
/opt/perl/lib/site_perl
.
*** Packages of interest status:
Apache::Request: -
CGI : 3.05
LWP : 5.800
mod_perl : -
3. This is the core dump trace: (if you get a core dump):
#0 0x0000002a9682334b in Perl_safesysmalloc (size=24) at util.c:78
78 my_exit(1);
(gdb) bt
#0 0x0000002a9682334b in Perl_safesysmalloc (size=24) at util.c:78
#1 0x0000002a9668bfeb in modperl_svptr_table_store (my_perl=0x25a5340,
tbl=0x2fc08f0, oldv=0x139d1c0, newv=0x355e1c0) at modperl_svptr_table.c:212
#2 0x0000002a96689d05 in modperl_module_config_merge (p=0x307b290, basev=0x0,
addv=0x139d1c0, type=1) at modperl_module.c:237
#3 0x0000000000428c9f in ap_merge_per_dir_configs (p=0x307b290,
base=0x580190, new_conf=0x2480590)
at /home/smoke/src/apache/httpd-2.0/server/config.c:245
#4 0x000000000044008d in ap_location_walk (r=0x356b070)
at /home/smoke/src/apache/httpd-2.0/server/request.c:1295
#5 0x000000000043ed04 in ap_process_request_internal (r=0x356b070)
at /home/smoke/src/apache/httpd-2.0/server/request.c:135
#6 0x0000000000424048 in ap_process_request (r=0x356b070)
at /home/smoke/src/apache/httpd-2.0/modules/http/http_request.c:244
#7 0x000000000041f235 in ap_process_http_connection (c=0x30799e0)
at /home/smoke/src/apache/httpd-2.0/modules/http/http_core.c:253
#8 0x0000000000432041 in ap_run_process_connection (c=0x30799e0)
at /home/smoke/src/apache/httpd-2.0/server/connection.c:42
#9 0x0000000000425419 in process_socket (p=0x3078760, sock=0x2dd6240,
my_child_num=1, my_thread_num=424, bucket_alloc=0x30799e0)
at /home/smoke/src/apache/httpd-2.0/server/mpm/worker/worker.c:520
#10 0x0000000000425b56 in worker_thread (thd=0x33702b0, dummy=0x3)
at /home/smoke/src/apache/httpd-2.0/server/mpm/worker/worker.c:856
#11 0x0000002a95e3fcab in dummy_worker (opaque=0x0)
at ../../apr/threadproc/unix/thread.c:137
#12 0x0000002a9619ae85 in pthread_start_thread () from /lib/libpthread.so.0
#13 0x0000002a964f7f70 in clone () from /lib/libc.so.6
This report was generated by t/REPORT on Thu Sep 30 22:37:53 2004 GMT.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
[...]
> > No luck. In fact, actually I am wondering why
> > modperl_interp_pool_select() does not call PERL_SET_CONTEXT, but
> > modperl_interp_select() does.
>
> I suppose these were added as the problems were appearing.
>
> > If it did, that would resolve my segfault:
>
> You mean with this patch, the segfault goes away?
Yes- both with and without your patch.
> > Index: src/modules/perl/modperl_interp.c
> > ===================================================================
> > RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
> > retrieving revision 1.63
> > diff -u -p -r1.63 modperl_interp.c
> > --- src/modules/perl/modperl_interp.c 18 Sep 2004 04:33:34 -0000 1.63
> > +++ src/modules/perl/modperl_interp.c 8 Oct 2004 02:36:29 -0000
> > @@ -368,6 +368,7 @@ modperl_interp_t *modperl_interp_pool_se
> > }
> > }
> > + PERL_SET_CONTEXT(interp->perl);
> > return interp;
> > }
>
> I think it has a problem, since potentially you haven't had a chance
> to save the original context yet,
In this case the original context is bogus (the interpreter
which first set it seems to have left the building), so
restoring it doesn't offer any protection in this case.
Indeed, as mentioned earlier modperl_callback_run_handlers
segfaults when localization is attempted, because it seems
to assume modperl_interp_select will call PERL_SET_CONTEXT
(which isn't always so).
> before calling ..._select, and this SET call will lose it.
> I think we should write MACRO wrappers around these calls, which will
> do the following: get the original context and store it in the interp
> struct. the override the current context with the context of the
> selected interpreter. On unselect it should make sure to restore the
> original context.
Perhaps. I'll think about this more after the
"thread pools & dynamic config" enlightens me a bit more.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>Index: src/modules/perl/modperl_module.c
>>===================================================================
>>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v
>>retrieving revision 1.17
>>diff -u -r1.17 modperl_module.c
>>--- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 -0000 1.17
>>+++ src/modules/perl/modperl_module.c 8 Oct 2004 02:04:48 -0000
>>@@ -168,7 +168,7 @@
>>
>> #ifdef USE_ITHREADS
>> modperl_interp_t *interp;
>>- dTHX;
>>+ pTHX;
>> #endif
>>
>> /* if the module is loaded in vhost, base==NULL */
>>
>>need to check if we have other places that use dTHX instead of pTHX
>>
>>pTHX: register PerlInterpreter *my_perl
>>dTHX: register PerlInterpreter *my_perl = PERL_GET_THX
>>
>>Could that be the problem that you see? Could you please try with my
>>patch above, reversing yours first?
>
>
> No luck. In fact, actually I am wondering why
> modperl_interp_pool_select() does not call PERL_SET_CONTEXT, but
> modperl_interp_select() does.
I suppose these were added as the problems were appearing.
> If it did, that would resolve my segfault:
You mean with this patch, the segfault goes away?
> Index: src/modules/perl/modperl_interp.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 modperl_interp.c
> --- src/modules/perl/modperl_interp.c 18 Sep 2004 04:33:34 -0000 1.63
> +++ src/modules/perl/modperl_interp.c 8 Oct 2004 02:36:29 -0000
> @@ -368,6 +368,7 @@ modperl_interp_t *modperl_interp_pool_se
> }
> }
>
> + PERL_SET_CONTEXT(interp->perl);
> return interp;
> }
I think it has a problem, since potentially you haven't had a chance to
save the original context yet, before calling ..._select, and this SET
call will lose it.
I think we should write MACRO wrappers around these calls, which will do
the following: get the original context and store it in the interp struct.
the override the current context with the context of the selected
interpreter. On unselect it should make sure to restore the original context.
--
__________________________________________________________________
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Index: src/modules/perl/modperl_module.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v
> retrieving revision 1.17
> diff -u -r1.17 modperl_module.c
> --- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 -0000 1.17
> +++ src/modules/perl/modperl_module.c 8 Oct 2004 02:04:48 -0000
> @@ -168,7 +168,7 @@
>
> #ifdef USE_ITHREADS
> modperl_interp_t *interp;
> - dTHX;
> + pTHX;
> #endif
>
> /* if the module is loaded in vhost, base==NULL */
>
> need to check if we have other places that use dTHX instead of pTHX
>
> pTHX: register PerlInterpreter *my_perl
> dTHX: register PerlInterpreter *my_perl = PERL_GET_THX
>
> Could that be the problem that you see? Could you please try with my
> patch above, reversing yours first?
No luck. In fact, actually I am wondering why
modperl_interp_pool_select() does not call PERL_SET_CONTEXT, but
modperl_interp_select() does.
If it did, that would resolve my segfault:
Index: src/modules/perl/modperl_interp.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
retrieving revision 1.63
diff -u -p -r1.63 modperl_interp.c
--- src/modules/perl/modperl_interp.c 18 Sep 2004 04:33:34 -0000 1.63
+++ src/modules/perl/modperl_interp.c 8 Oct 2004 02:36:29 -0000
@@ -368,6 +368,7 @@ modperl_interp_t *modperl_interp_pool_se
}
}
+ PERL_SET_CONTEXT(interp->perl);
return interp;
}
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>>Stas Bekman <st...@stason.org> writes:
>>>[...]
>>>
>>>
>>>>Joe, this still needs to applied? But please make sure that you
>>>>restore the context when you are done with it. Look at the other
>>>>places where this is done (grep for SET_CONTEXT).
>>>
>>>AFAICT the only place where the context is "localized" is in modperl_cmd.c:
>>>#define MP_PERL_DECLARE_CONTEXT \
>>> PerlInterpreter *orig_perl; \
>>> pTHX;
>>>/* XXX: .htaccess support cannot use this perl with threaded MPMs */
>>>#define MP_PERL_OVERRIDE_CONTEXT \
>>> orig_perl = PERL_GET_CONTEXT; \
>>> aTHX = scfg->mip->parent->perl; \
>>> PERL_SET_CONTEXT(aTHX);
>>>#define MP_PERL_RESTORE_CONTEXT \
>>> PERL_SET_CONTEXT(orig_perl);
>>>Is that what you have in mind here?
>>
>>Exactly.
>
>
> Here's the patch- unfortunately it doesn't quite work...
> I get a similar segfault when the perl handler runs
> (this patch only affects modperl_module_config_merge).
>
> Index: src/modules/perl/modperl_module.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v
> retrieving revision 1.17
> diff -u -r1.17 modperl_module.c
> --- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 -0000 1.17
> +++ src/modules/perl/modperl_module.c 7 Oct 2004 18:50:57 -0000
> @@ -169,6 +169,7 @@
> #ifdef USE_ITHREADS
> modperl_interp_t *interp;
> dTHX;
> + PerlInterpreter *orig_perl = aTHX;
> #endif
I wonder why do we have dTHX there. It's most likely the cause of the
problem, as essentially it grabs the latest context that was used
recently. It should be:
Index: src/modules/perl/modperl_module.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v
retrieving revision 1.17
diff -u -r1.17 modperl_module.c
--- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 -0000 1.17
+++ src/modules/perl/modperl_module.c 8 Oct 2004 02:04:48 -0000
@@ -168,7 +168,7 @@
#ifdef USE_ITHREADS
modperl_interp_t *interp;
- dTHX;
+ pTHX;
#endif
/* if the module is loaded in vhost, base==NULL */
need to check if we have other places that use dTHX instead of pTHX
pTHX: register PerlInterpreter *my_perl
dTHX: register PerlInterpreter *my_perl = PERL_GET_THX
Could that be the problem that you see? Could you please try with my patch
above, reversing yours first?
--
__________________________________________________________________
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> > [...]
> >
> >>Joe, this still needs to applied? But please make sure that you
> >>restore the context when you are done with it. Look at the other
> >>places where this is done (grep for SET_CONTEXT).
> > AFAICT the only place where the context is "localized" is in modperl_cmd.c:
> > #define MP_PERL_DECLARE_CONTEXT \
> > PerlInterpreter *orig_perl; \
> > pTHX;
> > /* XXX: .htaccess support cannot use this perl with threaded MPMs */
> > #define MP_PERL_OVERRIDE_CONTEXT \
> > orig_perl = PERL_GET_CONTEXT; \
> > aTHX = scfg->mip->parent->perl; \
> > PERL_SET_CONTEXT(aTHX);
> > #define MP_PERL_RESTORE_CONTEXT \
> > PERL_SET_CONTEXT(orig_perl);
> > Is that what you have in mind here?
>
> Exactly.
Here's the patch- unfortunately it doesn't quite work...
I get a similar segfault when the perl handler runs
(this patch only affects modperl_module_config_merge).
Index: src/modules/perl/modperl_module.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v
retrieving revision 1.17
diff -u -r1.17 modperl_module.c
--- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 -0000 1.17
+++ src/modules/perl/modperl_module.c 7 Oct 2004 18:50:57 -0000
@@ -169,6 +169,7 @@
#ifdef USE_ITHREADS
modperl_interp_t *interp;
dTHX;
+ PerlInterpreter *orig_perl = aTHX;
#endif
/* if the module is loaded in vhost, base==NULL */
@@ -185,6 +186,7 @@
#ifdef USE_ITHREADS
interp = modperl_interp_pool_select(p, s);
aTHX = interp->perl;
+ PERL_SET_CONTEXT(aTHX);
#endif
table = modperl_module_config_table_get(aTHX_ TRUE);
@@ -239,7 +241,7 @@
if (!is_startup) {
modperl_module_config_obj_cleanup_register(aTHX_ p, table, mrg);
}
-
+ PERL_SET_CONTEXT(orig_perl);
return (void *)mrg;
}
~>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1099901296 (LWP 5305)]
0x0000002a967c286d in Perl_safesysmalloc (size=96) at util.c:75
(gdb) up
#1 0x0000002a967f01d7 in Perl_sv_upgrade (my_perl=0x14204c0, sv=0x1490250, mt=13)
at sv.c:1506
(gdb)
#2 0x0000002a96764286 in Perl_gv_init (my_perl=0x14204c0, gv=0x1490250,
stash=0x2fa2720, name=0x2a968b2e45 "DESTROY", len=7, multi=1) at gv.c:112
(gdb) #3 0x0000002a96764807 in Perl_gv_fetchmeth (my_perl=0x14204c0, stash=0x2fa2720,
name=0x2a968b2e45 "DESTROY", len=7, level=0) at gv.c:225
(gdb)
#4 0x0000002a96764e47 in Perl_gv_fetchmeth_autoload (my_perl=0x14204c0,
stash=0x2fa2720, name=0x2a968b2e45 "DESTROY", len=7, level=0) at gv.c:338
(gdb)
#5 0x0000002a967681db in Perl_Gv_AMupdate (my_perl=0x14204c0, stash=0x2fa2720)
at gv.c:1363
(gdb)
#6 0x0000002a96801108 in Perl_sv_bless (my_perl=0x14204c0, sv=0x1490230,
stash=0x2fa2720) at sv.c:7894
(gdb)
#7 0x0000002a96800e34 in Perl_newSVrv (my_perl=0x14204c0, rv=0x1490230,
classname=0x2a96615908 "Apache::RequestRec") at sv.c:7748
(gdb)
#8 0x0000002a96800ea6 in Perl_sv_setref_pv (my_perl=0x14204c0, rv=0x1490230,
classname=0x2a96615908 "Apache::RequestRec", pv=0x274a6a8) at sv.c:7779
(gdb)
#9 0x0000002a965f9576 in modperl_ptr2obj (my_perl=0x14204c0,
classname=0x2a96615908 "Apache::RequestRec", ptr=0x274a6a8)
at modperl_util.c:192
(gdb)
#10 0x0000002a965f7d99 in modperl_handler_make_args (my_perl=0x14204c0,
avp=0x418f2158) at modperl_handler.c:238
(gdb)
#11 0x0000002a965f6c23 in modperl_callback_run_handlers (idx=6, type=4,
r=0x274a6a8, c=0x0, s=0x5a0b80, pconf=0x0, plog=0x0, ptemp=0x0,
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:237
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>Joe, this still needs to applied? But please make sure that you
>>restore the context when you are done with it. Look at the other
>>places where this is done (grep for SET_CONTEXT).
>
>
> AFAICT the only place where the context is "localized" is in modperl_cmd.c:
>
> #define MP_PERL_DECLARE_CONTEXT \
> PerlInterpreter *orig_perl; \
> pTHX;
>
> /* XXX: .htaccess support cannot use this perl with threaded MPMs */
> #define MP_PERL_OVERRIDE_CONTEXT \
> orig_perl = PERL_GET_CONTEXT; \
> aTHX = scfg->mip->parent->perl; \
> PERL_SET_CONTEXT(aTHX);
>
> #define MP_PERL_RESTORE_CONTEXT \
> PERL_SET_CONTEXT(orig_perl);
>
>
> Is that what you have in mind here?
Exactly.
--
__________________________________________________________________
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Joe, this still needs to applied? But please make sure that you
> restore the context when you are done with it. Look at the other
> places where this is done (grep for SET_CONTEXT).
AFAICT the only place where the context is "localized" is in modperl_cmd.c:
#define MP_PERL_DECLARE_CONTEXT \
PerlInterpreter *orig_perl; \
pTHX;
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
#define MP_PERL_OVERRIDE_CONTEXT \
orig_perl = PERL_GET_CONTEXT; \
aTHX = scfg->mip->parent->perl; \
PERL_SET_CONTEXT(aTHX);
#define MP_PERL_RESTORE_CONTEXT \
PERL_SET_CONTEXT(orig_perl);
Is that what you have in mind here?
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
[...]
> So it seems Perl_safesysmalloc depends on PERL_SET_CONTEXT. This
> patch fixes the segfault, but I'm not sure it's an acceptable solution:
>
> Index: src/modules/perl/modperl_module.c
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_module.c,v
> retrieving revision 1.17
> diff -u -r1.17 modperl_module.c
> --- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 -0000 1.17
> +++ src/modules/perl/modperl_module.c 2 Oct 2004 04:06:04 -0000
> @@ -185,6 +185,7 @@
> #ifdef USE_ITHREADS
> interp = modperl_interp_pool_select(p, s);
> aTHX = interp->perl;
> + PERL_SET_CONTEXT(aTHX);
> #endif
>
> table = modperl_module_config_table_get(aTHX_ TRUE);
Joe, this still needs to applied? But please make sure that you restore
the context when you are done with it. Look at the other places where this
is done (grep for SET_CONTEXT).
Let me know if you need help.
--
__________________________________________________________________
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>The whole issue is very sensitive, and it's usually win32 that has a
>>problem with it due to the nature it's memory allocator/deallocator
>>works, so we really need to add tests that break before trying to
>>change anything.
>
>
> +1, especially to fleshing all this out for the various
> PerlInterpScope directives.
>
> FWIW, although the patch fixes this particular test for me,
> I still occasionally get segfaults in t/perl/ithreads.t during
> a full t/TEST run (with or without the patch, it's been a problem
> I've had for quite a while). So there's still plenty of work to
> do ...
Everybody gets it once in a while (at the moment it's excluded from the
distro). I can't see how it can be fixed, since it happens totally randomly.
> Coming up with some more tests to isolate the ithread/PerlInterpScope
> bugs would really help a lot, because t/SMOKE isn't able to reduce it
> to under ~400 tests (mainly because the ithreads.t tests doesn't *always*
> fail for me, and it *never* seems to fail when it's run all by
> itself).
Right. Most likely it's caused by a PERL_(SET|GET)_CONTEXT issue, but the
cause could be different too. Debugging threads is not fun. I had cases
where t/SMOKE would get just a few tens of tests, but it was still not
very helpful.
--
__________________________________________________________________
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> The whole issue is very sensitive, and it's usually win32 that has a
> problem with it due to the nature it's memory allocator/deallocator
> works, so we really need to add tests that break before trying to
> change anything.
+1, especially to fleshing all this out for the various
PerlInterpScope directives.
FWIW, although the patch fixes this particular test for me,
I still occasionally get segfaults in t/perl/ithreads.t during
a full t/TEST run (with or without the patch, it's been a problem
I've had for quite a while). So there's still plenty of work to
do ...
Coming up with some more tests to isolate the ithread/PerlInterpScope
bugs would really help a lot, because t/SMOKE isn't able to reduce it
to under ~400 tests (mainly because the ithreads.t tests doesn't *always*
fail for me, and it *never* seems to fail when it's run all by
itself).
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>What I'm interested in is why I can't reproduce that problem. And if
>>you could come up with an explicit test that exposes that problem
>>clearly and exercises just that, it's a good idea to add it to the
>>test suite, so in the future we don't accidently "optimise" it away,
>>when doing some refactoring.
>
>
> Coming up with a test will be difficult, because the behavior most
> likely depends on how the the pthreads are created & scheduled. I/we
> probably need to go through the callbacks & ithread code in mp2 to make
> sure we're calling PERL_SET_CONTEXT as often as needed.
Actually, it's not very simple to just do that and now that I think of it,
your patch that I said it was OK may need more work. When you change the
global context, you can't leave it set if you switch to a different
interpreter. i.e. when you are done with the interpreter and you put it
back into the pool, you need to restore the previous global context to
whatever it was before (most likely it'll be the parent perl).
The whole issue is very sensitive, and it's usually win32 that has a
problem with it due to the nature it's memory allocator/deallocator works,
so we really need to add tests that break before trying to change anything.
--
__________________________________________________________________
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> What I'm interested in is why I can't reproduce that problem. And if
> you could come up with an explicit test that exposes that problem
> clearly and exercises just that, it's a good idea to add it to the
> test suite, so in the future we don't accidently "optimise" it away,
> when doing some refactoring.
Coming up with a test will be difficult, because the behavior most
likely depends on how the the pthreads are created & scheduled. I/we
probably need to go through the callbacks & ithread code in mp2 to make
sure we're calling PERL_SET_CONTEXT as often as needed.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
[...]
>>What the assembly dump is helpful for? do you think the C function wasn't
>>compiled properly?
>
>
> gdb was acting very weird, and I was losing confidence in what
> I was seeing, but Joe cleared up the fog for me. Here's what
> happens on the bad request, letting it segfault this time (I recompiled
> perl-5.8.5 w/ -Doptimize="-gdwarf-2 -g3" to enable macro expansions
> in gdb):
Yeah, these are very cool options, these and others are documented here:
http://perl.apache.org/docs/2.0/devel/debug/c.html#Expanding_C_Macros
> 0x0000002a967c486d in Perl_safesysmalloc (size=24) at util.c:75
> (gdb) list Perl_safesysmalloc
> 54
> 55 /* paranoid version of system's malloc() */
> 56
> 57 Malloc_t
> 58 Perl_safesysmalloc(MEM_SIZE size)
> 59 {
> 60 dTHX;
> 61 Malloc_t ptr;
> 62 #ifdef HAS_64K_LIMIT
> 63 if (size > 0xffff) {
> (gdb) macro expand dTHX
> expands to: PerlInterpreter *my_perl __attribute__((unused)) = ((PerlInterpreter *)pthread_getspecific(PL_thr_key))
> (gdb) p PL_thr_key
> $1 = 3
> (gdb) p my_perl
> $2 = (PerlInterpreter *) 0x0
>
>
> So it seems Perl_safesysmalloc depends on PERL_SET_CONTEXT. This
> patch fixes the segfault, but I'm not sure it's an acceptable solution:
>
> Index: src/modules/perl/modperl_module.c
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_module.c,v
> retrieving revision 1.17
> diff -u -r1.17 modperl_module.c
> --- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 -0000 1.17
> +++ src/modules/perl/modperl_module.c 2 Oct 2004 04:06:04 -0000
> @@ -185,6 +185,7 @@
> #ifdef USE_ITHREADS
> interp = modperl_interp_pool_select(p, s);
> aTHX = interp->perl;
> + PERL_SET_CONTEXT(aTHX);
> #endif
>
> table = modperl_module_config_table_get(aTHX_ TRUE);
It is a perfectly correct solution. You can find quite a few other
examples of the same thing in the mp2 code. The problem is that perl was
originally written w/o multiplicity support. When later on that support
was added, many of the internal functions (like malloc/free wrappers) were
still relying on the global context, and no one has bothered to provide a
new API that will accept aTHX as an argument. Not only it sucks that we
have this kind of problem (we have bumped into and solved many of this
kind before), the overhead of calling PERL_GET_CONTEXT in the threaded
enviroment becomes pretty significant since functions like malloc/free are
called very often. I was planning to provide that alternative set of API
for perl for a long time already, but it probably won't happen until after
mp2 is released.
What I'm interested in is why I can't reproduce that problem. And if you
could come up with an explicit test that exposes that problem clearly and
exercises just that, it's a good idea to add it to the test suite, so in
the future we don't accidently "optimise" it away, when doing some
refactoring.
--
__________________________________________________________________
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Geoffrey Young wrote:
> > Joe Schaefer wrote:
> >
> >>Joe Schaefer <jo...@sunstarsys.com> writes:
> >>
> >>
> >>
> >>>1. Problem Description:
> >>>
> >>>Current cvs segfaults w/perl 5.8.5, not reproducible with 5.8.4:
> >>>
> >>>#0 0x0000002a9682334b in Perl_safesysmalloc (size=24) at util.c:78
> >>>78 my_exit(1);
> >>>
> >>>This may be an ithread-related bug in 5.8.5, not mp2.
> >>>
> >>>% t/TEST -v t/directive/cmdparms.t
> >>
> >>
> >>Any assembler gurus out there? This is starting to look
> >>like a gcc/ld bug on my debian-amd64 box now...
> > fwiw, I don't see this error on my 5.8.5 threaded perl (-V below), but I'm
> > not using the same system (or processor) you are. I don't know if anything
> > else stands out...
>
> Same here, i686 and no segfault.
>
> What the assembly dump is helpful for? do you think the C function wasn't
> compiled properly?
gdb was acting very weird, and I was losing confidence in what
I was seeing, but Joe cleared up the fog for me. Here's what
happens on the bad request, letting it segfault this time (I recompiled
perl-5.8.5 w/ -Doptimize="-gdwarf-2 -g3" to enable macro expansions
in gdb):
0x0000002a967c486d in Perl_safesysmalloc (size=24) at util.c:75
(gdb) list Perl_safesysmalloc
54
55 /* paranoid version of system's malloc() */
56
57 Malloc_t
58 Perl_safesysmalloc(MEM_SIZE size)
59 {
60 dTHX;
61 Malloc_t ptr;
62 #ifdef HAS_64K_LIMIT
63 if (size > 0xffff) {
(gdb) macro expand dTHX
expands to: PerlInterpreter *my_perl __attribute__((unused)) = ((PerlInterpreter *)pthread_getspecific(PL_thr_key))
(gdb) p PL_thr_key
$1 = 3
(gdb) p my_perl
$2 = (PerlInterpreter *) 0x0
So it seems Perl_safesysmalloc depends on PERL_SET_CONTEXT. This
patch fixes the segfault, but I'm not sure it's an acceptable solution:
Index: src/modules/perl/modperl_module.c
===================================================================
RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_module.c,v
retrieving revision 1.17
diff -u -r1.17 modperl_module.c
--- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 -0000 1.17
+++ src/modules/perl/modperl_module.c 2 Oct 2004 04:06:04 -0000
@@ -185,6 +185,7 @@
#ifdef USE_ITHREADS
interp = modperl_interp_pool_select(p, s);
aTHX = interp->perl;
+ PERL_SET_CONTEXT(aTHX);
#endif
table = modperl_module_config_table_get(aTHX_ TRUE);
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Joe Schaefer wrote:
>
>>Joe Schaefer <jo...@sunstarsys.com> writes:
>>
>>
>>
>>>1. Problem Description:
>>>
>>>Current cvs segfaults w/perl 5.8.5, not reproducible with 5.8.4:
>>>
>>>#0 0x0000002a9682334b in Perl_safesysmalloc (size=24) at util.c:78
>>>78 my_exit(1);
>>>
>>>This may be an ithread-related bug in 5.8.5, not mp2.
>>>
>>>% t/TEST -v t/directive/cmdparms.t
>>
>>
>>Any assembler gurus out there? This is starting to look
>>like a gcc/ld bug on my debian-amd64 box now...
>
>
> fwiw, I don't see this error on my 5.8.5 threaded perl (-V below), but I'm
> not using the same system (or processor) you are. I don't know if anything
> else stands out...
Same here, i686 and no segfault.
What the assembly dump is helpful for? do you think the C function wasn't
compiled properly? I think that it's quite possible that some other memory
corruption occuring early simply affects this particular frame. If you
always hit the same address, try setting a watchpoint for it and see if
anything touches it beforehand?
Also try to minimize the test (and various httpd.conf/modperl_extra.pl
blocks) to a very minumum and then may be it'll be easier to find the cause.
--
__________________________________________________________________
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>
>>1. Problem Description:
>>
>>Current cvs segfaults w/perl 5.8.5, not reproducible with 5.8.4:
>>
>>#0 0x0000002a9682334b in Perl_safesysmalloc (size=24) at util.c:78
>>78 my_exit(1);
>>
>>This may be an ithread-related bug in 5.8.5, not mp2.
>>
>> % t/TEST -v t/directive/cmdparms.t
>
>
> Any assembler gurus out there? This is starting to look
> like a gcc/ld bug on my debian-amd64 box now...
fwiw, I don't see this error on my 5.8.5 threaded perl (-V below), but I'm
not using the same system (or processor) you are. I don't know if anything
else stands out...
--Geoff
Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
Platform:
osname=linux, osvers=2.4.22-1.2115.nptl, archname=i686-linux-thread-multi
uname='linux jib.modperlcookbook.net 2.4.22-1.2115.nptl #1 wed oct 29
15:42:51 est 2003 i686 i686 i386 gnulinux '
config_args='-des -Dusethreads -Dprefix=/perl/perl-5.8.5 -Doptimize=-g
-Dusedevel -Uinstallusrbinperl -Uversiononly -DDEBUGGING'
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
-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 -DDEBUGGING
-fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.3.2 20031022 (Red Hat Linux 3.3.2-1)',
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.2.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
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 Aug 3 2004 07:44:47
@INC:
/perl/perl-5.8.5/lib/5.8.5/i686-linux-thread-multi
/perl/perl-5.8.5/lib/5.8.5
/perl/perl-5.8.5/lib/site_perl/5.8.5/i686-linux-thread-multi
/perl/perl-5.8.5/lib/site_perl/5.8.5
/perl/perl-5.8.5/lib/site_perl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Orton <jo...@redhat.com> writes:
> On Fri, Oct 01, 2004 at 01:10:37PM -0400, Joe Schaefer wrote:
> > I cranked up httpd via gdb and stepped through the test.
> > Here's the first bad stack frame I see- notice first two
> > arguments to apr_pcalloc_debug are mangled (they *should*
> > be (pool=0x2f01080, size=16) at modperl_module.c:39-
>
> Is this output after manually stepping into that function rather than
> after the segfault triggers? It's normal on amd64 that the stack frame
> doesn't appear correctly in gdb immediately after entering the function:
> after you stepi a few times it rights itself.
Thanks Joe! That explains quite well what I've been seeing from gdb-
it does correct itself after a while. I still don't have a clue yet
about what's causing the segfault a few steps later on.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Oct 01, 2004 at 01:10:37PM -0400, Joe Schaefer wrote:
> I cranked up httpd via gdb and stepped through the test.
> Here's the first bad stack frame I see- notice first two
> arguments to apr_pcalloc_debug are mangled (they *should*
> be (pool=0x2f01080, size=16) at modperl_module.c:39-
Is this output after manually stepping into that function rather than
after the segfault triggers? It's normal on amd64 that the stack frame
doesn't appear correctly in gdb immediately after entering the function:
after you stepi a few times it rights itself.
>
> (gdb) f 0
> #0 apr_pcalloc_debug (pool=0x34, size=47922976, file_line=0x2a9661a620 "modperl_module.c:40") at memory/unix/apr_pools.c:1313
> (gdb) up 1
> #1 0x0000002a96607c61 in modperl_module_cfg_new (p=0x2f01080) at modperl_module.c:39
> (gdb)
> #2 0x0000002a9660805d in modperl_module_config_merge (p=0x2f01080, basev=0x1bdb340, addv=0x1c08860, type=1) at modperl_module.c:198
> (gdb)
> #3 0x0000002a966086c7 in modperl_module_config_dir_merge (p=0x2f01080, basev=0x1bdb340, addv=0x1c08860) at modperl_module.c:249
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> 1. Problem Description:
>
> Current cvs segfaults w/perl 5.8.5, not reproducible with 5.8.4:
>
> #0 0x0000002a9682334b in Perl_safesysmalloc (size=24) at util.c:78
> 78 my_exit(1);
>
> This may be an ithread-related bug in 5.8.5, not mp2.
>
> % t/TEST -v t/directive/cmdparms.t
Any assembler gurus out there? This is starting to look
like a gcc/ld bug on my debian-amd64 box now...
I cranked up httpd via gdb and stepped through the test.
Here's the first bad stack frame I see- notice first two
arguments to apr_pcalloc_debug are mangled (they *should*
be (pool=0x2f01080, size=16) at modperl_module.c:39-
(gdb) f 0
#0 apr_pcalloc_debug (pool=0x34, size=47922976, file_line=0x2a9661a620 "modperl_module.c:40") at memory/unix/apr_pools.c:1313
(gdb) up 1
#1 0x0000002a96607c61 in modperl_module_cfg_new (p=0x2f01080) at modperl_module.c:39
(gdb)
#2 0x0000002a9660805d in modperl_module_config_merge (p=0x2f01080, basev=0x1bdb340, addv=0x1c08860, type=1) at modperl_module.c:198
(gdb)
#3 0x0000002a966086c7 in modperl_module_config_dir_merge (p=0x2f01080, basev=0x1bdb340, addv=0x1c08860) at modperl_module.c:249
(gdb)
#4 0x0000000000428d9f in ap_merge_per_dir_configs (p=0x2f01080, base=0x5d7420, new_conf=0x1c1c520) at config.c:245
(gdb)
#5 0x000000000044018d in ap_location_walk (r=0x319f420) at request.c:1295
(gdb)
#6 0x000000000043ee04 in ap_process_request_internal (r=0x319f420) at request.c:135
(gdb)
#7 0x0000000000424148 in ap_process_request (r=0x319f420) at http_request.c:244
(gdb)
#8 0x000000000041f335 in ap_process_http_connection (c=0x2f5a5c0) at http_core.c:253
(gdb)
#9 0x0000000000432141 in ap_run_process_connection (c=0x2f5a5c0) at connection.c:42
FWIW- here's my assembler dump of modperl_module_cfg_new. I'm
really out of my depth here, so any help is really appreciated!
(gdb) disass modperl_module_cfg_new
Dump of assembler code for function modperl_module_cfg_new:
0x0000002a96607c40 <modperl_module_cfg_new+0>: push %rbp
0x0000002a96607c41 <modperl_module_cfg_new+1>: mov %rsp,%rbp
0x0000002a96607c44 <modperl_module_cfg_new+4>: sub $0x10,%rsp
0x0000002a96607c48 <modperl_module_cfg_new+8>: mov %rdi,0xfffffffffffffff8(%rbp)
0x0000002a96607c4c <modperl_module_cfg_new+12>: mov 0xfffffffffffffff8(%rbp),%rdi
0x0000002a96607c50 <modperl_module_cfg_new+16>: lea 76233(%rip),%rdx # 0x2a9661a620 <__func__.3+240>
0x0000002a96607c57 <modperl_module_cfg_new+23>: mov $0x10,%esi
0x0000002a96607c5c <modperl_module_cfg_new+28>: callq 0x2a965ecee0 <_init+280>
0x0000002a96607c61 <modperl_module_cfg_new+33>: mov %rax,0xfffffffffffffff0(%rbp)
0x0000002a96607c65 <modperl_module_cfg_new+37>: mov 0xfffffffffffffff0(%rbp),%rax
0x0000002a96607c69 <modperl_module_cfg_new+41>: leaveq
0x0000002a96607c6a <modperl_module_cfg_new+42>: retq
End of assembler dump.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org