You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2004/06/11 05:03:10 UTC
5.6.1 segfaults during perl tests (was Re: 2.03-dev-rc1 available)
Joe Schaefer <jo...@sunstarsys.com> writes:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>
> [...]
>
> >
> > On a related note, I get the same segfaults with 5.6.1 (no ithreads)
> > on Debian woody. Everything compiles and all the non-perl tests
> > pass, but all the perl tests segfault.
>
> The main problem appears to be that sv_magic has changed
> substantially between 5.6.1 and 5.8.x. I can get all
> the request tests to pass after rewriting the sv_magic()
That was the problem- it needs to be rewritten in both
apreq_xs_c2perl and apreq_xs_table_c2perl. I've got
all tests passing on 5.6.1 now. Will commit shortly.
--
Joe Schaefer
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Markus Wichitill <ma...@gmx.de>.
> After a few +1s we'll let the modperl list take
> a crack at it.
+1 on SuSE Linux 9.0 with Apache 2.0.49 (worker), Perl 5.8.3, mod_perl 1.99_14.
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Steve Hay <st...@uk.radan.com>.
Joe Schaefer wrote:
> Please try this bundle and report back,
>especially if you encountered problems testing
>a previous candidate.
>
> http://cvs.apache.org/~joes/libapreq2-2.03-dev-rc3.tar.gz
>
All successful now on Win32 (5.8.4 / 2.0.49 / 1.99_15-dev).
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Martin Nilsson <ma...@gneto.com>.
Joe Schaefer wrote:
> Please try this bundle and report back,
> especially if you encountered problems testing
> a previous candidate.
>
> http://cvs.apache.org/~joes/libapreq2-2.03-dev-rc3.tar.gz
>
Works OK on FreeBSD 4.10 with perl 5.8.4 (not threaded) and gmake.
/Martin
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 10 Jun 2004, Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
> Folks,
>
> Please try this bundle and report back,
> especially if you encountered problems testing
> a previous candidate.
>
> http://cvs.apache.org/~joes/libapreq2-2.03-dev-rc3.tar.gz
>
> After a few +1s we'll let the modperl list take
> a crack at it.
>
> Thanks for the help!
>
Works fine for me (Win32, Apache/2.0.49, perl-5.8.0
[ActivePerl compatibile]). +1. Thanks, Joe!
--
best regards,
randy
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by "Edward J. Sabol" <sa...@alderaan.gsfc.nasa.gov>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> Please try this bundle and report back, especially if you encountered
> problems testing a previous candidate.
>
> http://cvs.apache.org/~joes/libapreq2-2.03-dev-rc3.tar.gz
>
> After a few +1s we'll let the modperl list take a crack at it.
All tests pass with Perl 5.6.1! Way to go, Joe! +1.
Thanks,
Ed
Re: [NOMINATE] Geoffrey Young as committer (was Re: 2.03-dev-rc3)
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 11 Jun 2004, Joe Schaefer wrote:
>
>
>>Thanks, applied. I'd like to also recommend you become an committer
>>here so we don't need to keep appyling your patches for you. After
>>few more votes from the other committers I'll try to make it happen.
>>
>>Here's my +1.
>
>
> +1 - great idea.
+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
Re: [NOMINATE] Geoffrey Young as committer (was Re: 2.03-dev-rc3)
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 11 Jun 2004, Joe Schaefer wrote:
> Thanks, applied. I'd like to also recommend you become an committer
> here so we don't need to keep appyling your patches for you. After
> few more votes from the other committers I'll try to make it happen.
>
> Here's my +1.
+1 - great idea.
--
best regards,
randy
[NOMINATE] Geoffrey Young as committer (was Re: 2.03-dev-rc3)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
[...]
> something anyway. I tried current cvs and rc3 with 5.8.3 and there
> are no problems. well, no real problems - I didn't have lwp installed
> so lots of the tests failed. patch for that attached.
Thanks, applied. I'd like to also recommend you become an committer
here so we don't need to keep appyling your patches for you. After
few more votes from the other committers I'll try to make it happen.
Here's my +1.
--
Joe Schaefer
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Schaefer wrote:
> Geoffrey Young <ge...@modperlcookbook.org> writes:
>
>
>>just to limit things further, disabling -Werror and letting the
>>warnings fly by still dumps core (without my patch). same results
>>with rc1, rc2, and rc3 using the perl-5.8.4 I posted last time. I
>>couldn't find any older versions by poking around your ~user page, but
>>if you would like me to try some of
>>them I can.
>
>
> Nope, that's all I have. Are you able to test
> the previous 2.02-dev release (www.apache.org/dist/httpd/libapreq)?
> We definitely need to find a working reference point.
hmph. I tried all the official releases and none work with my 5.8.4. I
checked the archives as well, and the last time I seem to have had one pass
was around april 16, which is just days before 5.8.4 was released.
> Perhaps we need a new ppport.h file for 5.8.4?
something anyway. I tried current cvs and rc3 with 5.8.3 and there are no
problems. well, no real problems - I didn't have lwp installed so lots of
the tests failed. patch for that attached.
unlike randy, though, current cvs still does not work for me with 5.8.4.
--Geoff
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 11 Jun 2004, Geoffrey Young wrote:
> > I'm not sure if this helps in narrowing things down, but
> > with the current cvs (including the change just made a few
> > minutes ago), I find all tests pass:
>
> > usethreads=undef
>
> as I mentioned in the other response, I'm not seeing the
> same thing. but it seems you are using a non-threaded
> perl whereas I am not. I'll try building a non-threaded
> 5.8.4 and see if that helps.
>
> --Geoff
Also, I should have mentioned - I'm using mod_perl-1.9914
(the CPAN version).
--
best regards,
randy
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
> +#ifdef USE_ITHREADS
> struct apreq_xs_do_arg *d = (struct apreq_xs_do_arg *)data;
> dTHXa(d->perl);
> +#endif
I wasn't quite following recently, so it's unrelated to Geoff's patch, but you
should be careful when doing things like above. Always do:
PERL_SET_CONTEXT(...);
when switching aTHX.
as well. W/o it any SV operation may allocate memory from a wrong interpreter.
Though it might be OK for this particular case.
--
__________________________________________________________________
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: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> It's great that it worked itself out, but I wonder if it may
> not be such a silly error - perhaps a mismatch between using
> part of an installed version and the rest from the new
> build? I've seen that happen on Win32, which admittedly is
> quite different in this respect, but when it does happen,
> it leads to similar errors (I'm working on trying to prevent
> it on Win32).
hmm, that's a definite possibility. lately my nightly builds have been
taking so long that they are still running when I start work in the morning.
so today I stopped the running one midway to speed up the server, then
when I went to test libapreq I _thought_ I did a make realclean before
starting up the mod_perl build again. but maybe I didn't. and maybe it was
in the middle of a 2.1 build or something and there were 2.1-based files
mixed with 2.0 or something. the price you pay for trying to maintain lots
of different versions, I guess :)
anyway, I'll holler if it crops up again, but I tried a few new builds and
still wasn't able to reproduce.
--Geoff
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 11 Jun 2004, Geoffrey Young wrote:
> > Regarding the 5.8.4+ithreads problem, I'd again suggest
> > you take a look at any changes in sv_magic's
> > implementation, because that's what we use to pass the
> > request_rec (env for us) along to the the parent class
> > (Apache::RequestRec), and it's being mangled somehow.
> > Otherwise diff ppport.h and see what's changed in the
> > THX macros...
>
> ok, I have a feeling this might have all been my fault.
> I've gone through so many builds today that I can hardly
> keep things straight, but at some point I started with a
> fresh apache and mod_perl build and now I can't get my old
> problem back. bugs that fix themselves, nice :)
>
> so, unless someone that isn't me has any issues with a
> threaded 5.8.4, it might have just been a silly user
> error.
It's great that it worked itself out, but I wonder if it may
not be such a silly error - perhaps a mismatch between using
part of an installed version and the rest from the new
build? I've seen that happen on Win32, which admittedly is
quite different in this respect, but when it does happen,
it leads to similar errors (I'm working on trying to prevent
it on Win32).
--
best regards,
randy
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Ahh, you are a stickler, aren't you. I bet it was a "used only once"
> warning :-).
sorry, it's not me :) I have maintainer mode set up for mod_perl so I don't
get into trouble and libapreq inherits the -Werror from there. so, if I
don't remember to explicitly unset it things start to error out.
> In any case, it's now applied.
:)
>
> Regarding the 5.8.4+ithreads problem, I'd again suggest you take a look
> at any changes in sv_magic's implementation, because that's what we use
> to pass the request_rec (env for us) along to the the parent class
> (Apache::RequestRec), and it's being mangled somehow. Otherwise diff
> ppport.h and see what's changed in the THX macros...
ok, I have a feeling this might have all been my fault. I've gone through
so many builds today that I can hardly keep things straight, but at some
point I started with a fresh apache and mod_perl build and now I can't get
my old problem back. bugs that fix themselves, nice :)
so, unless someone that isn't me has any issues with a threaded 5.8.4, it
might have just been a silly user error.
but at least some warnings and other little nits got fixed in the process,
but sorry to have caused undo grief.
--Geoff
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
[...]
> Regarding the 5.8.4+ithreads problem, I'd again suggest you take a look
> at any changes in sv_magic's implementation, because that's what we use
> to pass the request_rec (env for us) along to the the parent class
> (Apache::RequestRec), and it's being mangled somehow. Otherwise diff
> ppport.h and see what's changed in the THX macros...
The current cvs works fine for me with worker and prefork with 5.8.4-ithreads
on linux.
--
__________________________________________________________________
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: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> Geoffrey Young wrote:
> >>I'm not sure if this helps in narrowing things down, but
> >>with the current cvs (including the change just made a few
> >>minutes ago), I find all tests pass:
> >
> >
> >> usethreads=undef
> >
> >
> > as I mentioned in the other response, I'm not seeing the same thing.
> > but it seems you are using a non-threaded perl whereas I am not.
> > I'll try building a non-threaded 5.8.4 and see if that helps.
>
> ok, unthreaded 5.8.4 works ok. and it compiles cleanly after the attached
> patch :)
Ahh, you are a stickler, aren't you. I bet it was a "used only once"
warning :-). In any case, it's now applied.
Regarding the 5.8.4+ithreads problem, I'd again suggest you take a look
at any changes in sv_magic's implementation, because that's what we use
to pass the request_rec (env for us) along to the the parent class
(Apache::RequestRec), and it's being mangled somehow. Otherwise diff
ppport.h and see what's changed in the THX macros...
> and thanks for the nomination.
My pleasure.
> I feel really bad that I haven't been able to contribute as much as I
> should here,
No worries- committership is not meant to be an obligation, mainly
an recognition of your long-time participation here, as well as a
strong desire to get out of your way :-).
> but I guess you can't do everything. well, unless you're a whirlwind
> like someone I know ;)
Yup, we're pretty lucky to have a few of those guys around. I'm
still waiting for the other whirlwind to weigh in, even though he
surely hates me now for forcing him to do it in public again :-).
--
Joe Schaefer
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Geoffrey Young wrote:
>>I'm not sure if this helps in narrowing things down, but
>>with the current cvs (including the change just made a few
>>minutes ago), I find all tests pass:
>
>
>> usethreads=undef
>
>
> as I mentioned in the other response, I'm not seeing the same thing. but it
> seems you are using a non-threaded perl whereas I am not. I'll try building
> a non-threaded 5.8.4 and see if that helps.
ok, unthreaded 5.8.4 works ok. and it compiles cleanly after the attached
patch :)
and thanks for the nomination. I feel really bad that I haven't been able
to contribute as much as I should here, but I guess you can't do everything.
well, unless you're a whirlwind like someone I know ;)
--Geoff
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I'm not sure if this helps in narrowing things down, but
> with the current cvs (including the change just made a few
> minutes ago), I find all tests pass:
> usethreads=undef
as I mentioned in the other response, I'm not seeing the same thing. but it
seems you are using a non-threaded perl whereas I am not. I'll try building
a non-threaded 5.8.4 and see if that helps.
--Geoff
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 11 Jun 2004, Joe Schaefer wrote:
> Geoffrey Young <ge...@modperlcookbook.org> writes:
>
> > just to limit things further, disabling -Werror and letting the
> > warnings fly by still dumps core (without my patch). same results
> > with rc1, rc2, and rc3 using the perl-5.8.4 I posted last time. I
> > couldn't find any older versions by poking around your ~user page, but
> > if you would like me to try some of
> > them I can.
>
> Nope, that's all I have. Are you able to test
> the previous 2.02-dev release (www.apache.org/dist/httpd/libapreq)?
> We definitely need to find a working reference point.
>
> Perhaps we need a new ppport.h file for 5.8.4?
I'm not sure if this helps in narrowing things down, but
with the current cvs (including the change just made a few
minutes ago), I find all tests pass:
gcc -v:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
perl -V:
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=linux, osvers=2.4.20-28.9, archname=i686-linux
uname='linux theoryx5.uwinnipeg.ca 2.4.20-28.9 #1 thu dec 18 13:45:22 est 2003 i686 i686 i386 gnulinux '
config_args='-Dprefix=/opt'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)', 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 -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -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: USE_LARGE_FILES
Built under linux
httpd -V:
Server version: Apache/2.0.49
Server built: May 4 2004 21:54:48
Server's Module Magic Number: 20020903:7
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_PROC_PTHREAD_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/usr/local/httpd"
-D SUEXEC_BIN="/usr/local/httpd/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
--
best regards,
randy
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> just to limit things further, disabling -Werror and letting the
> warnings fly by still dumps core (without my patch). same results
> with rc1, rc2, and rc3 using the perl-5.8.4 I posted last time. I
> couldn't find any older versions by poking around your ~user page, but
> if you would like me to try some of
> them I can.
Nope, that's all I have. Are you able to test
the previous 2.02-dev release (www.apache.org/dist/httpd/libapreq)?
We definitely need to find a working reference point.
Perhaps we need a new ppport.h file for 5.8.4?
--
Joe Schaefer
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Geoffrey Young wrote:
>>Thanks- that's a very good possibility, but let's eliminate the
>>sv_magic() issue first.
>
>
> it doesn't look like it is. with the off_t/size_t patch in place, neither
> switching the magic logic back nor rc2 pass the glue tests.
just to limit things further, disabling -Werror and letting the warnings fly
by still dumps core (without my patch). same results with rc1, rc2, and rc3
using the perl-5.8.4 I posted last time. I couldn't find any older versions
by poking around your ~user page, but if you would like me to try some of
them I can.
--Geoff
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Thanks- that's a very good possibility, but let's eliminate the
> sv_magic() issue first.
it doesn't look like it is. with the off_t/size_t patch in place, neither
switching the magic logic back nor rc2 pass the glue tests.
btw, sorry for not issuing a proper bug report with all the important info.
I've tried 2.0.49 and 2.0.50-dev (and 2.1 :), all worker, with perl 5.8.4
(threaded). perl -V and httpd -V below.
--Geoff
Summary of my perl5 (revision 5 version 8 subversion 4) 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.4 -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 -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 -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'
Server version: Apache/2.0.49
Server built: Apr 26 2004 10:47:57
Server's Module Magic Number: 20020903:7
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_PROC_PTHREAD_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/apache/2.0.49/worker/perl-5.8.4"
-D SUEXEC_BIN="/apache/2.0.49/worker/perl-5.8.4/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"
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> (gdb) thread 3
> [Switching to thread 3 (process 9176)]#0 0x08078101 in ap_get_module_config
> (cv=0x0, m=0xbb6480) at util_debug.c:105
> 105 return ((void **)cv)[m->module_index];
> (gdb) bt
> #0 0x08078101 in ap_get_module_config (cv=0x0, m=0xbb6480) at util_debug.c:105
> #1 0x00328fcf in mpxs_Apache__RequestRec_content_type (my_perl=0x9837fd0,
> r=0x99fd468, type=0x9a52fe4)
> at Apache__RequestRec.h:23
Clearly cv shouldn't be NULL here. Since this stack trace looks
similar to the 5.6.1 coredumps, I'm wondering if the sv_magic fix
I committed to rc3 broke your build. See if any of the other
release candidates (rc1, rc2) still segfault (with your patch applied),
or just read the sv_magic comments in glue/perl/xsbuilder/apreq_xs_postperl.h
and replace the 5.6.1-compatible call with the original code (that is now
commented out).
[...]
> I'm not sure if it's the same issue, but we went a few rounds over in
> mod_perl land with joe orton on something similar. the (very long)
> threads starts here:
>
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108079557016990&w=2
>
> the most interesting part (which you probably already know) is here
>
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108091576021446&w=2
>
> I really didn't understand most of it, but joe and stas worked
> something out for the mod_perl build system IIRC. maybe that needs to
> happen here as well?
Thanks- that's a very good possibility, but let's eliminate the
sv_magic() issue first.
--
Joe Schaefer
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>but I guess the reason it fails
>
>
> Wait- does the patch you submitted still fail to compile or complete
> the tests?
it compiles. the glue tests core dump all over the place. sorry for the
confusion.
> If so, please provide more details.
(gdb) thread 3
[Switching to thread 3 (process 9176)]#0 0x08078101 in ap_get_module_config
(cv=0x0, m=0xbb6480) at util_debug.c:105
105 return ((void **)cv)[m->module_index];
(gdb) bt
#0 0x08078101 in ap_get_module_config (cv=0x0, m=0xbb6480) at util_debug.c:105
#1 0x00328fcf in mpxs_Apache__RequestRec_content_type (my_perl=0x9837fd0,
r=0x99fd468, type=0x9a52fe4)
at Apache__RequestRec.h:23
#2 0x003295f7 in XS_Apache__RequestRec_content_type (my_perl=0x9837fd0,
cv=0x9a00fd4) at RequestRec.xs:37
#3 0x00b03615 in Perl_pp_entersub (my_perl=0x9837fd0) at pp_hot.c:2854
#4 0x00ae095f in Perl_runops_debug (my_perl=0x9837fd0) at dump.c:1442
#5 0x00a8a86c in S_call_body (my_perl=0x9837fd0, myop=0xbe8e3710,
is_eval=0) at perl.c:2285
#6 0x00a8a3da in Perl_call_sv (my_perl=0x9837fd0, sv=0x9873774, flags=4) at
perl.c:2203
#7 0x00a6afe2 in modperl_callback (my_perl=0x9837fd0, handler=0x9a20350,
p=0x99fd430, r=0x99fd468, s=0x976fe48,
args=0x98250a8) at modperl_callback.c:99
#8 0x00a6b949 in modperl_callback_run_handlers (idx=6, type=4, r=0x99fd468,
c=0x0, s=0x976fe48, pconf=0x0, plog=0x0,
ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:268
[lots more calls snipped]
>>is because the apr_off_t is larger (which I didn't realize - I thought
>>they were both ints).
>
>
> It depends on your LARGEFILE setting, since off_t's are usually used
> to represent the seek pointer of a file. If you're not using
> LARGEFILES, they may both be ints, in which case apr_size_t
> can represent larger numbers (being unsigned).
I'm not sure if it's the same issue, but we went a few rounds over in
mod_perl land with joe orton on something similar. the (very long) thread
starts here:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108079557016990&w=2
the most interesting part (which you probably already know) is here
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108091576021446&w=2
I really didn't understand most of it, but joe and stas worked something out
for the mod_perl build system IIRC. maybe that needs to happen here as well?
--Geoff
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> well, this is what I tried, both with and without the cast in the
> assignment.
Right- the cast shouldn't make a difference in the assignment,
because C will do an arithmetic conversion (from apr_off_t to apr_size_t)
anyway.
> but I guess the reason it fails
Wait- does the patch you submitted still fail to compile or complete
the tests? If so, please provide more details. If it works, but
you're wondering why it didn't without the patch, it's probably
because C doesn't do any arithmetic conversion on the *contents*
of the pointer argument, it just pretends the bit-patterns are
identical for apr_size_t and apr_off_t. Evidently that's not
kosher on your box (casting a pointer just changes the *pointer's*
type, not the pointer's *contents*).
> is because the apr_off_t is larger (which I didn't realize - I thought
> they were both ints).
It depends on your LARGEFILE setting, since off_t's are usually used
to represent the seek pointer of a file. If you're not using
LARGEFILES, they may both be ints, in which case apr_size_t
can represent larger numbers (being unsigned).
--
Joe Schaefer
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> It's because brigades can represent data streams (eg files) that may be
> larger than available memory. But reading a brigade into a string
> does demand the brigade actually fit; thus the (usually smaller) apr_size_t
> instead of apr_off_t.
cool, thanks for the explanation.
>>anyway, I tried fixing it by declaring both types and using some casts
>>so it compiles, but I get core dumps left and right in the tests. so
>>sorry, no patch from me atm.
>
>
> I'm aware of the warning, but have not bothered to deal with it.
> Typecasts might be a mistake here (because we're mixing
> signed and unsigned numeric types). Maybe we just need an extra
> apr_size_t variable?
well, this is what I tried, both with and without the cast in the
assignment. but I guess the reason it fails is because the apr_off_t is
larger (which I didn't realize - I thought they were both ints). and my C
skills aren't good enough to know why if this doesn't work it would work for
me if I ignored the warnings (which I haven't tried yet).
--Geoff
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> > Folks,
> >
> > Please try this bundle and report back,
> > especially if you encountered problems testing
> > a previous candidate.
> >
> > http://cvs.apache.org/~joes/libapreq2-2.03-dev-rc3.tar.gz
> >
> > After a few +1s we'll let the modperl list take
> > a crack at it.
>
> I am getting warnings with fedora core 1 (gcc 3.3.2) on 2.0.49 and 2.0 dev.
>
> Apache__Request.h: In function `apreq_xs_upload_slurp':
> Apache__Request.h:203: warning: passing arg 3 of `apr_brigade_flatten' from
> incompatible pointer type
>
> since I build with -Werror this stops things for me (and -Werror is a good
> idea for us developers anyway, since stas will inevitably pick up on it and
> let you know ;)
>
> apr_brigade_flatten takes an apr_size_t while apr_brigade_length takes an
> apr_off_t (go figure).
It's because brigades can represent data streams (eg files) that may be
larger than available memory. But reading a brigade into a string
does demand the brigade actually fit; thus the (usually smaller) apr_size_t
instead of apr_off_t.
> anyway, I tried fixing it by declaring both types and using some casts
> so it compiles, but I get core dumps left and right in the tests. so
> sorry, no patch from me atm.
I'm aware of the warning, but have not bothered to deal with it.
Typecasts might be a mistake here (because we're mixing
signed and unsigned numeric types). Maybe we just need an extra
apr_size_t variable?
--
Joe Schaefer
Re: 2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Folks,
>
> Please try this bundle and report back,
> especially if you encountered problems testing
> a previous candidate.
>
> http://cvs.apache.org/~joes/libapreq2-2.03-dev-rc3.tar.gz
>
> After a few +1s we'll let the modperl list take
> a crack at it.
I am getting warnings with fedora core 1 (gcc 3.3.2) on 2.0.49 and 2.0 dev.
Apache__Request.h: In function `apreq_xs_upload_slurp':
Apache__Request.h:203: warning: passing arg 3 of `apr_brigade_flatten' from
incompatible pointer type
since I build with -Werror this stops things for me (and -Werror is a good
idea for us developers anyway, since stas will inevitably pick up on it and
let you know ;)
apr_brigade_flatten takes an apr_size_t while apr_brigade_length takes an
apr_off_t (go figure). anyway, I tried fixing it by declaring both types
and using some casts so it compiles, but I get core dumps left and right in
the tests. so sorry, no patch from me atm.
--Geoff
2.03-dev-rc3 (was Re: 5.6.1 segfaults during perl tests)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> That was the problem- it needs to be rewritten in both
> apreq_xs_c2perl and apreq_xs_table_c2perl. I've got
> all tests passing on 5.6.1 now. Will commit shortly.
Folks,
Please try this bundle and report back,
especially if you encountered problems testing
a previous candidate.
http://cvs.apache.org/~joes/libapreq2-2.03-dev-rc3.tar.gz
After a few +1s we'll let the modperl list take
a crack at it.
Thanks for the help!
--
Joe Schaefer