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/08/18 19:36:40 UTC
smoky has found a segfault
t/SMOKE -times=1 -iterations=1 -bug_mode 1 t/compat/apache_file.t
t/apr-ext/base64.t t/modperl/perl_options.t t/hooks/push_handlers.t
t/hooks/authz.t t/apache/scanhdrs2.t t/modperl/exit.t
t/modules/include_subreq.t t/apr-ext/finfo.t t/compat/send_fd.t
t/preconnection/note.t t/modperl/print.t t/api/lookup_uri.t
t/modules/include2.t t/apr-ext/table.t t/api/request_subclass.t
t/modules/apache_status.t t/api/err_headers_out.t t/hooks/headerparser.t
t/apr/uri.t t/modperl/sameinterp.t t/api/status.t t/filter/in_bbs_body.t
t/error/runtime.t t/api/status.t t/api/slurp_filename.t
t/compat/apache_uri.t t/api/slurp_filename.t t/perl/ithreads2.t
t/perl/api.t t/filter/in_str_lc.t t/hooks/hookrun.t t/modperl/method.t
t/filter/in_bbs_msg.t t/modperl/request_rec_perlio_api.t t/apache/read2.t
t/perl/hash_attack.t t/apr/perlio.t t/apache/content_length_header.t
t/compat/apache_uri.t t/apr-ext/uri.t t/filter/both_str_req_proxy.t
t/filter/both_str_req_add.t t/compat/apache_util.t t/preconnection/note.t
t/filter/out_str_lc.t t/filter/in_str_consume.t
t/hooks/push_handlers_same_phase.t t/api/slurp_filename.t
t/modperl/perl_options.t t/modperl/pnotes.t t/modperl/status.t
t/apr-ext/string.t t/modperl/setupenv.t t/apr-ext/threadmutex.t
t/hooks/cleanup2.t t/apr-ext/threadmutex.t t/modperl/cookie.t
t/filter/in_str_msg.t t/perl/ithreads2.t t/apr/constants.t
t/compat/conn_rec.t t/protocol/eliza.t t/modperl/status.t
t/apr-ext/string.t t/apr-ext/pool.t t/modules/cgi2.t
t/hooks/headerparser.t t/apr/os.t t/modperl/io_nested_with_closed_stds.t
t/perl/ithreads.t t/filter/out_str_subreq_default.t t/apr/constants.t
t/filter/in_bbs_underrun.t t/api/aplog.t t/apr-ext/base64.t
t/directive/pod.t t/filter/in_bbs_inject_header.t t/modules/cgipost2.t
t/modules/cgi2.t t/compat/request.t t/apache/post.t
t/filter/in_str_declined.t t/filter/out_bbs_ctx.t t/filter/out_bbs_basic.t
t/modperl/print_utf8_2.t t/filter/in_error.t t/apr/uuid.t t/apr/os.t
t/perl/ithreads.t t/hooks/fixup.t t/compat/conn_authen.t
t/filter/out_bbs_basic.t t/filter/out_bbs_basic.t t/modules/cgi.t
t/apr/socket.t t/apache/add_config.t t/hooks/authz.t
t/compat/conn_authen.t t/apache/read.t t/modperl/perl_options.t
t/protocol/echo_bbs2.t t/compat/conn_authen.t t/api/sub_request.t
t/apr/pool.t t/hooks/push_handlers_blessed.t t/compat/conn_rec.t
t/apr/os.t t/directive/perlloadmodule4.t t/filter/in_bbs_consume.t
t/apr-ext/bucket.t t/apr/uuid.t t/filter/out_str_ctx.t t/compat/request_body.t
consider removing an old /home/stas/apache.org/mp2-pool/t/core.6092 file
before running tests
consider removing an old /home/stas/apache.org/mp2-pool/t/core.23780 file
before running tests
Report file:
/home/stas/apache.org/mp2-pool/smoke-report-Wed_Aug_18_09-56-36_2004.txt
running t/TEST in the bug report mode
t/compat/apache_file..................ok
t/apr-ext/base64......................ok
t/modperl/perl_options................ok
t/hooks/push_handlers.................ok
t/hooks/authz.........................ok
t/apache/scanhdrs2....................ok
t/modperl/exit........................ok
t/modules/include_subreq..............ok
t/apr-ext/finfo.......................ok
t/compat/send_fd......................ok
t/preconnection/note..................ok
t/modperl/print.......................ok
t/api/lookup_uri......................ok
t/modules/include2....................ok
t/apr-ext/table.......................ok
t/api/request_subclass................ok
t/modules/apache_status...............ok
t/api/err_headers_out.................ok
t/hooks/headerparser..................ok
t/apr/uri.............................ok
t/modperl/sameinterp..................ok
t/api/status..........................ok
t/filter/in_bbs_body..................ok
t/error/runtime.......................ok
t/api/status..........................ok
t/api/slurp_filename..................ok
t/compat/apache_uri...................ok
t/api/slurp_filename..................ok
t/perl/ithreads2......................ok
t/perl/api............................ok
t/filter/in_str_lc....................ok
t/hooks/hookrun.......................ok
t/modperl/method......................ok
t/filter/in_bbs_msg...................ok
t/modperl/request_rec_perlio_api......ok
t/apache/read2........................ok
t/perl/hash_attack....................ok
t/apr/perlio..........................ok
t/apache/content_length_header........ok
t/compat/apache_uri...................ok
t/apr-ext/uri.........................ok
t/filter/both_str_req_proxy...........ok
t/filter/both_str_req_add.............ok
t/compat/apache_util..................ok
t/preconnection/note..................ok
t/filter/out_str_lc...................ok
t/filter/in_str_consume...............ok
t/hooks/push_handlers_same_phase......ok
t/api/slurp_filename..................ok
t/modperl/perl_options................ok
t/modperl/pnotes......................ok
t/modperl/status......................ok
t/apr-ext/string......................ok
t/modperl/setupenv....................ok
t/apr-ext/threadmutex.................ok
t/hooks/cleanup2......................ok
t/apr-ext/threadmutex.................ok
t/modperl/cookie......................ok
t/filter/in_str_msg...................ok
t/perl/ithreads2......................ok
t/apr/constants.......................ok
t/compat/conn_rec.....................ok
t/protocol/eliza......................ok
t/modperl/status......................ok
t/apr-ext/string......................ok
t/apr-ext/pool........................ok
t/modules/cgi2........................ok
t/hooks/headerparser..................ok
t/apr/os..............................ok
t/modperl/io_nested_with_closed_stds..ok
t/perl/ithreads.......................ok
t/filter/out_str_subreq_default.......ok
t/apr/constants.......................ok
t/filter/in_bbs_underrun..............ok
t/api/aplog...........................ok
t/apr-ext/base64......................ok
t/directive/pod.......................ok
t/filter/in_bbs_inject_header.........ok
t/modules/cgipost2....................ok
t/modules/cgi2........................ok
t/compat/request......................ok
t/apache/post.........................ok
t/filter/in_str_declined..............ok
t/filter/out_bbs_ctx..................ok
t/filter/out_bbs_basic................ok
t/modperl/print_utf8_2................ok
t/filter/in_error.....................ok
t/apr/uuid............................ok
t/apr/os..............................ok
t/perl/ithreads.......................ok
t/hooks/fixup.........................ok
t/compat/conn_authen..................ok
t/filter/out_bbs_basic................ok
t/filter/out_bbs_basic................ok
t/modules/cgi.........................ok
t/apr/socket..........................ok
t/apache/add_config...................ok
t/hooks/authz.........................ok
t/compat/conn_authen..................ok
t/apache/read.........................ok
t/modperl/perl_options................ok
t/protocol/echo_bbs2..................ok
t/compat/conn_authen..................ok
t/api/sub_request.....................ok
t/apr/pool............................ok
t/hooks/push_handlers_blessed.........ok
t/compat/conn_rec.....................ok
t/apr/os..............................ok
t/directive/perlloadmodule4...........ok
t/filter/in_bbs_consume...............ok
t/apr-ext/bucket......................ok
t/apr/uuid............................ok
t/filter/out_str_ctx..................ok
t/compat/request_body.................FAILED
------------------------------------------------------------
*** run log ***
[warning] setting ulimit to allow core files
ulimit -c unlimited; /home/stas/perl/5.8.5-ithread/bin/perl5.8.5
/home/stas/apache.org/mp2-pool/t/TEST -verbose -run 't/compat/request_body.t'
[ info] consider removing an old
/home/stas/apache.org/mp2-pool/t/core.6092 file before running tests
[ info] consider removing an old
/home/stas/apache.org/mp2-pool/t/core.23780 file before running tests
t/compat/request_body....1..5
# Running under perl version 5.008005 for linux
# Current time local: Wed Aug 18 10:23:43 2004
# Current time GMT: Wed Aug 18 17:23:43 2004
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.13
# testing : $r->send_http_header('text/plain')
# expected: text/plain
# received: text/plain
ok 1
# testing : $r->content via POST
# expected: test content
# received: test content
ok 2
# testing : $r->Apache::args
# expected: test args
# received: test args
ok 3
response had protocol HTTP/0.9 (headers not sent?) at
t/compat/request_body.t line 50
dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 4-5
Failed 2/5 tests, 60.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/compat/request_body.t 255 65280 5 4 80.00% 4-5
Failed 1/1 test scripts, 0.00% okay. 2/5 subtests failed, 60.00% okay.
[ error] error running tests (please examine t/logs/error_log)
[ error] oh jeez, server dumped core
[ error] for stacktrace, run: gdb /home/stas/httpd/prefork/bin/httpd
-core /home/stas/apache.org/mp2-pool/t/core.12586
[ info] an old core file has been found:
/home/stas/apache.org/mp2-pool/t/core.6092
[ info] an old core file has been found:
/home/stas/apache.org/mp2-pool/t/core.23780
*** /home/stas/apache.org/mp2-pool/t/logs/error_log ***
[Wed Aug 18 10:23:53 2004] [notice] child pid 12586 exit signal
Segmentation fault (11), possible coredump in /home/stas/apache.org/mp2-pool/t
*** /home/stas/apache.org/mp2-pool/t/logs/access_log ***
127.0.0.1 - - [18/Aug/2004:10:23:52 -0700] "HEAD
/TestCompat__request_body?test=content-type HTTP/1.0" 200 -
127.0.0.1 - - [18/Aug/2004:10:23:52 -0700] "POST
/TestCompat__request_body HTTP/1.0" 200 12
127.0.0.1 - - [18/Aug/2004:10:23:52 -0700] "GET
/TestCompat__request_body?test=args HTTP/1.0" 200 9
#0 0x4017c9b7 in apr_bucket_free (mem=0x974a538) at apr_buckets_alloc.c:156
156 apr_allocator_free(list->allocator, node->memnode);
(gdb) bt
#0 0x4017c9b7 in apr_bucket_free (mem=0x974a538) at apr_buckets_alloc.c:156
#1 0x4017eaee in heap_bucket_destroy (data=0x94c2f80) at
apr_buckets_heap.c:35
#2 0x4017d83c in apr_brigade_cleanup (data=0x974a560) at apr_brigade.c:55
#3 0x4017d891 in apr_brigade_destroy (b=0x974a560) at apr_brigade.c:68
#4 0x080f5688 in core_output_filter (f=0x94bf020, b=0x974a560) at core.c:4226
#5 0x080eb063 in ap_pass_brigade (next=0x94bf020, bb=0x9745740)
at util_filter.c:511
#6 0x080a785d in ap_http_header_filter (f=0x9a6a7c8, b=0x9745740)
at http_protocol.c:1690
#7 0x080eb063 in ap_pass_brigade (next=0x9a6a7c8, bb=0x9745740)
at util_filter.c:511
#8 0x080edda6 in ap_content_length_filter (f=0x9a6a7b0, b=0x9745740)
at protocol.c:1256
#9 0x080eb063 in ap_pass_brigade (next=0x9a6a7b0, bb=0x9745740)
at util_filter.c:511
#10 0x080a92cb in ap_byterange_filter (f=0x9a6a798, bb=0x9745740)
at http_protocol.c:2875
#11 0x080eb063 in ap_pass_brigade (next=0x9a6a798, bb=0x9745740)
at util_filter.c:511
#12 0x404486de in modperl_wbucket_pass (wb=0x97434f0,
buf=0x97434f4 "%DC%DC+%EC%2E+%D6%D6+%D6%2F", 'x' <repeats 173 times>...,
---Type <return> to continue, or q <return> to quit---
len=27, add_flush_bucket=1) at modperl_filter.c:224
#13 0x40448725 in modperl_wbucket_flush (wb=0x97434f0, add_flush_bucket=1)
at modperl_filter.c:242
#14 0x4061103a in mpxs_Apache__RequestRec_print (my_perl=0x93735b8, items=2,
mark=0x9932fbc, sp=0x9932fb8) at Apache__RequestIO.h:96
#15 0x40612ffc in XS_Apache__RequestRec_print (my_perl=0x93735b8,
cv=0x9061c84)
at RequestIO.xs:143
#16 0x4050cbba in Perl_pp_entersub (my_perl=0x93735b8) at pp_hot.c:2857
#17 0x404e8275 in Perl_runops_debug (my_perl=0x93735b8) at dump.c:1442
#18 0x4048dc49 in S_call_body (my_perl=0x93735b8, myop=0xbfffed50, is_eval=0)
at perl.c:2288
#19 0x4048d775 in Perl_call_sv (my_perl=0x93735b8, sv=0x99138dc, flags=4)
at perl.c:2206
#20 0x404419f1 in modperl_callback (my_perl=0x93735b8, handler=0x9745688,
p=0x9a69918, r=0x9a69950, s=0x813e0c8, args=0x993af68)
at modperl_callback.c:99
#21 0x40442396 in modperl_callback_run_handlers (idx=6, type=4, r=0x9a69950,
c=0x0, s=0x813e0c8, pconf=0x0, plog=0x0, ptemp=0x0,
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:268
#22 0x404425f5 in modperl_callback_per_dir (idx=6, r=0x9a69950,
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:356
---Type <return> to continue, or q <return> to quit---
#23 0x4043b010 in modperl_response_handler_run (r=0x9a69950, finish=1)
at mod_perl.c:905
#24 0x4043b12b in modperl_response_handler (r=0x9a69950) at mod_perl.c:945
#25 0x080db664 in ap_run_handler (r=0x9a69950) at config.c:151
#26 0x080dbdc1 in ap_invoke_handler (r=0x9a69950) at config.c:358
#27 0x080a9f8b in ap_process_request (r=0x9a69950) at http_request.c:246
#28 0x080a4530 in ap_process_http_connection (c=0x94bec50) at http_core.c:250
#29 0x080e814c in ap_run_process_connection (c=0x94bec50) at connection.c:42
#30 0x080e8548 in ap_process_connection (c=0x94bec50, csd=0x94beb78)
at connection.c:175
#31 0x080d9f15 in child_main (child_num_arg=0) at prefork.c:609
#32 0x080da09f in make_child (s=0x813e0c8, slot=0) at prefork.c:703
#33 0x080da112 in startup_children (number_to_start=2) at prefork.c:721
#34 0x080da51f in ap_mpm_run (_pconf=0x81370a8, plog=0x817f1c8, s=0x813e0c8)
at prefork.c:940
#35 0x080e114c in main (argc=9, argv=0xbffff234) at main.c:619
(gdb)
Now going to try and reduce that sequence to a shorter one...
--
__________________________________________________________________
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: smoky has found a segfault
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
> [...]
>
>
>>Well, I use it a lot in filters where I want to reuse the same bucket brigade
>>to only replace those buckets that were modified. I guess it's not needed in
>>this particular case.
>
>
> +1.
>
>
> [...]
>
>
>>>>I wonder why don't I see the problem right away then, and only after
>>>>running a bunch of other tests. Any idea why?
>>>
>>>No clue, yet.
>>
>>:(
>
>
> The segfault is happening on the output filter side. Are there
> any mp2 output filters in play (t/filter/out_str_ctx?) that might be
> screwing things up? I haven't fully groked these failing tests,
> so any tips will help.
they shouldn't affect this test. Actually I haven't investigated that case
at all yet, I just got the segfault over this night and posted to see if
anybody else may have seen it too. Once I finish with the replacement of
safemalloc with subpool testing in the filters, i'll take a look at this.
--
__________________________________________________________________
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: smoky has found a segfault
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Well, I use it a lot in filters where I want to reuse the same bucket brigade
> to only replace those buckets that were modified. I guess it's not needed in
> this particular case.
+1.
[...]
> >>I wonder why don't I see the problem right away then, and only after
> >>running a bunch of other tests. Any idea why?
> > No clue, yet.
>
> :(
The segfault is happening on the output filter side. Are there
any mp2 output filters in play (t/filter/out_str_ctx?) that might be
screwing things up? I haven't fully groked these failing tests,
so any tips will help.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: smoky has found a segfault
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:
>>>
>>>
>>>>Now going to try and reduce that sequence to a shorter one...
>>>
>>>I don't think you need bother- the brigade loop is miscoded in compat.pm's
>>>content sub- you can't ask for the next bucket *after* $b has been
>>>removed.
>>
>>why not? it still points to the next bucket, no?
>
>
> Probably so, because of the way (I think) APR_RING_UNSPLICE is
> currently implemeted. But IMO that's not guaranteed by the
> apr_ring.h documentation (unless that's what is meant by
> "dangling pointers").
And it's not possible to take the pointer to the next bucket before hand,
because of the filebucket inplace bucket split, that you've pointed out
earlier.
>>>Instead of iterating using for(;;), use while():
>>> while ($b = $bb->first) {
>>> ++$seen_eos, last if $b->is_eos;
>>> if ($b->read(my $buf)) {
>>> $data .= $buf;
>>> }
>>> $b->delete; # APR::Bucket needs to wrap apr_bucket_delete(),
>>># since APR_BUCKET_REMOVE() doesn't actually
>>> # decrement the bucket refcount
>>> # so the bucket allocator can reclaim $b
>>> }
>>
>>I've been explicitly rewriting the iteration loops recently not to use the
>>while loop, because for anything more complicated it becomes a mess and too
>>easy to put $b->delete in the wrong place.
>
>
> OK, but don't call $b->remove, because its not doing anything
> useful.
Well, I use it a lot in filters where I want to reuse the same bucket
brigade to only replace those buckets that were modified. I guess it's not
needed in this particular case.
> Leave the buckets in the brigade and call $bb->cleanup
> after each inner for() loop, that way the next call to get_brigade
> will be able to reuse those buckets (if at all possible).
I wish we could use that. It segfaults: see:
modperl-2.0/t/protocol/TestProtocol/echo_bbs2.pm
...
# XXX: ideally $bb->cleanup should be used here and no create/destroy
# bb every time the loop is entered should be done. But it segfaults
# on certain setups:
# http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108967266419527&w=2
>>I wonder why don't I see the problem right away then, and only after
>>running a bunch of other tests. Any idea why?
>
>
> No clue, yet.
:(
--
__________________________________________________________________
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: smoky has found a segfault
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> You were saying delete (which is remove+destroy):
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=109285355117298&w=2
>
> $b->delete; # APR::Bucket needs to wrap apr_bucket_delete(),
> # since APR_BUCKET_REMOVE() doesn't actually
> # decrement the bucket refcount
> # so the bucket allocator can reclaim $b
>
> and I've missed the difference between delete and remove. My bad.
>
> So yes, we need to provide a delete() wrapper and use that.
Which takes us full circle, because my caution against calling
$bb->next($b) *after* calling $b->delete is far more serious,
because with delete, the underlying apr_bucket_t may have been
free()d.
> And hopefully one day someone will resolve the problems with
> $bb->cleanup on win32.
+1 - this would make life much simpler once it actually works there.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: smoky has found a segfault
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>So how do we clean them up? Last time you said that you do want to
>>remove them
>
>
> With either *apr_bucket_destroy* or *apr_brigade_cleanup*, which
> is what I've been saying all along.
You were saying delete (which is remove+destroy):
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=109285355117298&w=2
$b->delete; # APR::Bucket needs to wrap apr_bucket_delete(),
# since APR_BUCKET_REMOVE() doesn't actually
# decrement the bucket refcount
# so the bucket allocator can reclaim $b
and I've missed the difference between delete and remove. My bad.
So yes, we need to provide a delete() wrapper and use that.
And hopefully one day someone will resolve the problems with $bb->cleanup
on win32.
Thanks Joe!
--
__________________________________________________________________
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: smoky has found a segfault
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> So how do we clean them up? Last time you said that you do want to
> remove them
With either *apr_bucket_destroy* or *apr_brigade_cleanup*, which
is what I've been saying all along.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: smoky has found a segfault
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>
>
> [...]
>
>
>>>==================================================
>>>MODULE = APR::Brigade PACKAGE = APR::Brigade PREFIX = apr_brigade_
>>>apr_status_t
>>>apr_brigade_cleanup(data)
>>> void * data
>>>==================================================
>>>I think mp2 is using the wrong typemap here (void *), which may be
>>>causing the $bb->cleanup segfaults on Win32.
>>
>>Ah, what's wrong about it? the declaration is:
>>
>>APU_DECLARE(apr_status_t) apr_brigade_cleanup(void *data);
>
>
>
> You're right, that shouldn't be the cause of the problem,
> although that's a very odd signature for this function
> (since *data must always be an apr_bucket_brigade *).
>
> AFAICT the only functional difference between apr_brigade_cleanup
> and apr_brigade_destroy is the pool cleanup getting deregistered
> by apr_brigade_destroy. I'll take a closer look when I get a
> chance, but I don't think this should hold up 1.99_15- just
> keep in mind that by calling $b->remove here (just to clear the
> brigade for another ap_get_brigade call) you are creating a
> memory leak, because those removed buckets will not get cleaned
> up.
So how do we clean them up? Last time you said that you do want to remove
them nevertheless to reuse the bucket allocation. Now it sounds like you
say the opposite.
--
__________________________________________________________________
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: smoky has found a segfault
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
[...]
> > ==================================================
> > MODULE = APR::Brigade PACKAGE = APR::Brigade PREFIX = apr_brigade_
> > apr_status_t
> > apr_brigade_cleanup(data)
> > void * data
> > ==================================================
> > I think mp2 is using the wrong typemap here (void *), which may be
> > causing the $bb->cleanup segfaults on Win32.
>
> Ah, what's wrong about it? the declaration is:
>
> APU_DECLARE(apr_status_t) apr_brigade_cleanup(void *data);
You're right, that shouldn't be the cause of the problem,
although that's a very odd signature for this function
(since *data must always be an apr_bucket_brigade *).
AFAICT the only functional difference between apr_brigade_cleanup
and apr_brigade_destroy is the pool cleanup getting deregistered
by apr_brigade_destroy. I'll take a closer look when I get a
chance, but I don't think this should hold up 1.99_15- just
keep in mind that by calling $b->remove here (just to clear the
brigade for another ap_get_brigade call) you are creating a
memory leak, because those removed buckets will not get cleaned
up.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: smoky has found a segfault
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:
>>>[...]
>>>
>>>
>>>>Heh, I tried that (removing $b->remove), and t/compat/request_body.t
>>>>then segfaults right there, all by itself.
>>>
>>>:-( Did you remember to replace it with $bb->cleanup?
>>
>>I can't. Remember it crashes on win32:
>>http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108967266419527&w=2
>
>
> Random guess- from WrapXS/APR/Brigade/Brigade.xs
> ==================================================
> MODULE = APR::Brigade PACKAGE = APR::Brigade PREFIX = apr_brigade_
>
> apr_status_t
> apr_brigade_cleanup(data)
> void * data
>
> ==================================================
> I think mp2 is using the wrong typemap here (void *), which may be
> causing the $bb->cleanup segfaults on Win32.
Ah, what's wrong about it? the declaration is:
APU_DECLARE(apr_status_t) apr_brigade_cleanup(void *data);
>>>What's the backtrace look like?
>>
>>I think the same as posted at the head of this thread. I'll check that again.
>
>
> HTTP_IN will segfault if you pass it a non-empty brigade:
>
> http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105513549120399&w=2
>
It does assert. I didn't have a chance to test it until now:
[Thu Aug 19 16:54:26 2004] [crit] [Thu Aug 19 16:54:26 2004] file
http_protocol.c, line 976, assertion "readbytes > 0" failed
and the assertion causing the segfault. Not too smart.
#0 0xffffe410 in ?? ()
#1 0xbfffe83c in ?? ()
#2 0x00000006 in ?? ()
#3 0x00001711 in ?? ()
#4 0x40332925 in raise () from /lib/tls/libc.so.6
#5 0x40334309 in abort () from /lib/tls/libc.so.6
#6 0x080dfd1b in ap_log_assert (szExp=0x8111473 "readbytes > 0",
szFile=0x8111330 "http_protocol.c", nLine=976) at log.c:711
#7 0x080a6662 in ap_http_filter (f=0x9516f20, b=0x94d93e0,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=-18379)
at http_protocol.c:976
#8 0x080eafc1 in ap_get_brigade (next=0x9516f20, bb=0x94d93e0,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at util_filter.c:474
#9 0x080f44b4 in net_time_filter (f=0x9516a80, b=0x94d93e0,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at core.c:3649
#10 0x080eafc1 in ap_get_brigade (next=0x9516a80, bb=0x94d93e0,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at util_filter.c:474
--
__________________________________________________________________
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: smoky has found a segfault
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> > [...]
> >
> >>Heh, I tried that (removing $b->remove), and t/compat/request_body.t
> >>then segfaults right there, all by itself.
> > :-( Did you remember to replace it with $bb->cleanup?
>
> I can't. Remember it crashes on win32:
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108967266419527&w=2
Random guess- from WrapXS/APR/Brigade/Brigade.xs
==================================================
MODULE = APR::Brigade PACKAGE = APR::Brigade PREFIX = apr_brigade_
apr_status_t
apr_brigade_cleanup(data)
void * data
==================================================
I think mp2 is using the wrong typemap here (void *), which may be
causing the $bb->cleanup segfaults on Win32.
>
> > What's the backtrace look like?
>
> I think the same as posted at the head of this thread. I'll check that again.
HTTP_IN will segfault if you pass it a non-empty brigade:
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105513549120399&w=2
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: smoky has found a segfault
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>Heh, I tried that (removing $b->remove), and t/compat/request_body.t
>>then segfaults right there, all by itself.
>
>
> :-( Did you remember to replace it with $bb->cleanup?
I can't. Remember it crashes on win32:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108967266419527&w=2
> What's the backtrace look like?
I think the same as posted at the head of this thread. I'll check that again.
--
__________________________________________________________________
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: smoky has found a segfault
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Heh, I tried that (removing $b->remove), and t/compat/request_body.t
> then segfaults right there, all by itself.
:-( Did you remember to replace it with $bb->cleanup?
What's the backtrace look like?
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: smoky has found a segfault
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
[...]
>>>Instead of iterating using for(;;), use while():
>>> while ($b = $bb->first) {
>>> ++$seen_eos, last if $b->is_eos;
>>> if ($b->read(my $buf)) {
>>> $data .= $buf;
>>> }
>>> $b->delete; # APR::Bucket needs to wrap apr_bucket_delete(),
>>># since APR_BUCKET_REMOVE() doesn't actually
>>> # decrement the bucket refcount
>>> # so the bucket allocator can reclaim $b
>>> }
>>
>>I've been explicitly rewriting the iteration loops recently not to use the
>>while loop, because for anything more complicated it becomes a mess and too
>>easy to put $b->delete in the wrong place.
>
>
> OK, but don't call $b->remove, because its not doing anything
> useful. Leave the buckets in the brigade and call $bb->cleanup
> after each inner for() loop, that way the next call to get_brigade
> will be able to reuse those buckets (if at all possible).
Heh, I tried that (removing $b->remove), and t/compat/request_body.t then
segfaults right there, all by itself.
--
__________________________________________________________________
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: smoky has found a segfault
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> >
> >>Now going to try and reduce that sequence to a shorter one...
> > I don't think you need bother- the brigade loop is miscoded in compat.pm's
> > content sub- you can't ask for the next bucket *after* $b has been
> > removed.
>
> why not? it still points to the next bucket, no?
Probably so, because of the way (I think) APR_RING_UNSPLICE is
currently implemeted. But IMO that's not guaranteed by the
apr_ring.h documentation (unless that's what is meant by
"dangling pointers").
>
> > Instead of iterating using for(;;), use while():
> > while ($b = $bb->first) {
> > ++$seen_eos, last if $b->is_eos;
> > if ($b->read(my $buf)) {
> > $data .= $buf;
> > }
> > $b->delete; # APR::Bucket needs to wrap apr_bucket_delete(),
> > # since APR_BUCKET_REMOVE() doesn't actually
> > # decrement the bucket refcount
> > # so the bucket allocator can reclaim $b
> > }
>
> I've been explicitly rewriting the iteration loops recently not to use the
> while loop, because for anything more complicated it becomes a mess and too
> easy to put $b->delete in the wrong place.
OK, but don't call $b->remove, because its not doing anything
useful. Leave the buckets in the brigade and call $bb->cleanup
after each inner for() loop, that way the next call to get_brigade
will be able to reuse those buckets (if at all possible).
> I wonder why don't I see the problem right away then, and only after
> running a bunch of other tests. Any idea why?
No clue, yet.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: smoky has found a segfault
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>
>>Now going to try and reduce that sequence to a shorter one...
>
>
> I don't think you need bother- the brigade loop is
> miscoded in compat.pm's content sub- you can't
> ask for the next bucket *after* $b has been removed.
why not? it still points to the next bucket, no?
> Instead of iterating using for(;;), use while():
>
> while ($b = $bb->first) {
> ++$seen_eos, last if $b->is_eos;
> if ($b->read(my $buf)) {
> $data .= $buf;
> }
> $b->delete; # APR::Bucket needs to wrap apr_bucket_delete(),
> # since APR_BUCKET_REMOVE() doesn't actually
> # decrement the bucket refcount
> # so the bucket allocator can reclaim $b
> }
I've been explicitly rewriting the iteration loops recently not to use the
while loop, because for anything more complicated it becomes a mess and
too easy to put $b->delete in the wrong place. I wonder why don't I see
the problem right away then, and only after running a bunch of other
tests. Any idea why?
--
__________________________________________________________________
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: smoky has found a segfault
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Now going to try and reduce that sequence to a shorter one...
I don't think you need bother- the brigade loop is
miscoded in compat.pm's content sub- you can't
ask for the next bucket *after* $b has been removed.
Instead of iterating using for(;;), use while():
while ($b = $bb->first) {
++$seen_eos, last if $b->is_eos;
if ($b->read(my $buf)) {
$data .= $buf;
}
$b->delete; # APR::Bucket needs to wrap apr_bucket_delete(),
# since APR_BUCKET_REMOVE() doesn't actually
# decrement the bucket refcount
# so the bucket allocator can reclaim $b
}
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org