You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-cvs@httpd.apache.org by jo...@apache.org on 2005/04/28 22:54:50 UTC
svn commit: r165196 - /httpd/apreq/trunk/include/apreq_util.h
Author: joes
Date: Thu Apr 28 13:54:49 2005
New Revision: 165196
URL: http://svn.apache.org/viewcvs?rev=165196&view=rev
Log:
Drop brigade-debugging macros for portability
to httpd 2.0.47.
Modified:
httpd/apreq/trunk/include/apreq_util.h
Modified: httpd/apreq/trunk/include/apreq_util.h
URL: http://svn.apache.org/viewcvs/httpd/apreq/trunk/include/apreq_util.h?rev=165196&r1=165195&r2=165196&view=diff
==============================================================================
--- httpd/apreq/trunk/include/apreq_util.h (original)
+++ httpd/apreq/trunk/include/apreq_util.h Thu Apr 28 13:54:49 2005
@@ -359,9 +359,6 @@
else {
APR_BRIGADE_CONCAT(d, s);
}
-
- APR_BRIGADE_CHECK_CONSISTENCY(s);
- APR_BRIGADE_CHECK_CONSISTENCY(d);
}
Re: svn commit: r165196 - /httpd/apreq/trunk/include/apreq_util.h
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
joes@apache.org wrote:
> Author: joes
> Date: Thu Apr 28 13:54:49 2005
> New Revision: 165196
>
> URL: http://svn.apache.org/viewcvs?rev=165196&view=rev
> Log:
> Drop brigade-debugging macros for portability
> to httpd 2.0.47.
:)
--Geoff
Re: svn commit: r165196 - /httpd/apreq/trunk/include/apreq_util.h
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Schaefer wrote:
> Geoffrey Young <ge...@modperlcookbook.org> writes:
>
>
>>unreasonable to bump up to that version. but the choice is yours, of
>>course :)
>
>
> ITYM "ours". +1 for you to commit your patch, dear committer.
sorry, I didn't mean it like that - regardless of my commit status, I don't
think I've been involved enough to direct the project in this way was all I
meant :)
anyway, patch committed.
> That (sv = 0x0) definitely needs fixing. See what happens if you add a
> "use APR::Request::Error" at the top of upload.pm. If that helps, we
> probably should add that to glue/perl/xsbuilder/APR/Request.pm.
I'll try to get around to that today, but probably monday.
--Geoff
Re: svn commit: r165196 - /httpd/apreq/trunk/include/apreq_util.h
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Schaefer wrote:
> Geoffrey Young <ge...@modperlcookbook.org> writes:
>
>
>>>That (sv = 0x0) definitely needs fixing. See what happens if you add a
>>>"use APR::Request::Error" at the top of upload.pm. If that helps, we
>>>probably should add that to glue/perl/xsbuilder/APR/Request.pm.
>>
>>that takes care of the coredumps. upload.t still fails with this, though:
>
>
> +1 to patching glue/perl/xsbuilder/APR/Request.pm.
ok, but let me check on a few things first - I've been trying to test
different versions and now even the test tarball you uploaded earlier in the
week is failing, which isn't right and points to some messed up foo locally
for me. blarg.
I'll look into things a bit more and report back. sorry for the noise.
--Geoff
Re: svn commit: r165196 - /httpd/apreq/trunk/include/apreq_util.h
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
>> That (sv = 0x0) definitely needs fixing. See what happens if you add a
>> "use APR::Request::Error" at the top of upload.pm. If that helps, we
>> probably should add that to glue/perl/xsbuilder/APR/Request.pm.
>
> that takes care of the coredumps. upload.t still fails with this, though:
+1 to patching glue/perl/xsbuilder/APR/Request.pm.
> Error string not specified yet: apreq_brigade_concat failed; TempDir problem?
Hmm, could it be an old bug in apr's tempdir implementation?
It'd be nice to know the numeric status code here. Possible
clues (starting with r64706):
<URL:
http://svn.apache.org/viewcvs.cgi/apr/
apr/trunk/file_io/unix/tempdir.c?rev=151412&view=log
>
Maybe we just need to bump to 2.0.49?
--
Joe Schaefer
Re: svn commit: r165196 - /httpd/apreq/trunk/include/apreq_util.h
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> That (sv = 0x0) definitely needs fixing. See what happens if you add a
> "use APR::Request::Error" at the top of upload.pm. If that helps, we
> probably should add that to glue/perl/xsbuilder/APR/Request.pm.
that takes care of the coredumps. upload.t still fails with this, though:
Error string not specified yet: apreq_brigade_concat failed; TempDir problem?
HTH
--Geoff
Re: svn commit: r165196 - /httpd/apreq/trunk/include/apreq_util.h
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> unreasonable to bump up to that version. but the choice is yours, of
> course :)
ITYM "ours". +1 for you to commit your patch, dear committer.
> fwiw, even on 2.0.48 I get failures on worker
>
> t/apreq/cgi.t 10 2560 41 10 24.39% 32-41
> t/apreq/upload.t 0 13 20 40 200.00% 1-20
>
> with no messages in the error log save "premature end..." foo. the
> failurs all seem to stem from uploads, but when I run just the upload
> test by itself I get a core dump
>
> (gdb) thread 3
> [Switching to thread 3 (process 16916)]#0 0x010d804a in Perl_sv_unmagic
> (my_perl=0x9f16c08, sv=0x0, type=99) at sv.c:4842
> 4842 if (SvTYPE(sv) < SVt_PVMG || !SvMAGIC(sv))
> (gdb) bt
> #0 0x010d804a in Perl_sv_unmagic (my_perl=0x9f16c08, sv=0x0, type=99) at
> sv.c:4842
That (sv = 0x0) definitely needs fixing. See what happens if you add a
"use APR::Request::Error" at the top of upload.pm. If that helps, we
probably should add that to glue/perl/xsbuilder/APR/Request.pm.
--
Joe Schaefer
Re: svn commit: r165196 - /httpd/apreq/trunk/include/apreq_util.h
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
joes@apache.org wrote:
> Author: joes
> Date: Thu Apr 28 13:54:49 2005
> New Revision: 165196
>
> URL: http://svn.apache.org/viewcvs?rev=165196&view=rev
> Log:
> Drop brigade-debugging macros for portability
> to httpd 2.0.47.
actually, I spoke too soon:
.libs/libapreq2.so: undefined reference to `apr_temp_dir_get'
right now the build system lists 2.0.46 as the minimum version. the best I
can do is build with 2.0.48 at the moment (where apr_temp_dir_get was
introduced). 2.0.48 was released October 29, 2003, so I don't think it's
unreasonable to bump up to that version. but the choice is yours, of course :)
fwiw, even on 2.0.48 I get failures on worker
t/apreq/cgi.t 10 2560 41 10 24.39% 32-41
t/apreq/upload.t 0 13 20 40 200.00% 1-20
with no messages in the error log save "premature end..." foo. the failurs
all seem to stem from uploads, but when I run just the upload test by itself
I get a core dump
(gdb) thread 3
[Switching to thread 3 (process 16916)]#0 0x010d804a in Perl_sv_unmagic
(my_perl=0x9f16c08, sv=0x0, type=99) at sv.c:4842
4842 if (SvTYPE(sv) < SVt_PVMG || !SvMAGIC(sv))
(gdb) bt
#0 0x010d804a in Perl_sv_unmagic (my_perl=0x9f16c08, sv=0x0, type=99) at
sv.c:4842
#1 0x0105d0a7 in Perl_Gv_AMupdate (my_perl=0x9f16c08, stash=0x0) at gv.c:1316
#2 0x010de848 in Perl_sv_bless (my_perl=0x9f16c08, sv=0xa09a08c, stash=0x0)
at sv.c:7899
#3 0x002f6c7d in apreq_xs_croak (my_perl=0x9f16c08, data=0xa065f8c,
rc=20014, func=0x2f7829 "APR::Request::body",
class=0x2f7748 "APR::Request::Error") at apreq_xs_postperl.h:243
#4 0x002f2c18 in apreq_xs_body (my_perl=0x9f16c08, cv=0xa03e5ac) at
APR__Request.h:200
#5 0x010cd486 in Perl_pp_entersub (my_perl=0x9f16c08) at pp_hot.c:2890
#6 0x010ab4e3 in Perl_runops_debug (my_perl=0x9f16c08) at dump.c:1449
#7 0x01054c30 in S_call_body (my_perl=0x9f16c08, myop=0xbe93d710,
is_eval=0) at perl.c:2298
#8 0x0105479e in Perl_call_sv (my_perl=0x9f16c08, sv=0xa065f80, flags=4) at
perl.c:2216
#9 0x01033c70 in modperl_callback (my_perl=0x9f16c08, handler=0xa0267e8,
p=0xa022688, r=0xa0226c0, s=0x9dcee48,
args=0x9e7f7c0) at modperl_callback.c:100
but that shouldn't be a showstopper, I wouldn't think.
anyway, patch attached to bump to 2.0.48 so that it will at least build on
that platform.
--Geoff