You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Stas Bekman <st...@stason.org> on 2001/12/20 19:09:57 UTC
core dump in ap_send_fd
ap_send_fd expects the length of the input to send.
First of all is there a way not to specify the length? I've a fd (can be
a pipe to a process), and I've no way to figure out the length of the
output. How APR can handle this? This breaks the compatibility with
send_fd from httpd-1.3.x.
Second, I've found something that appears to be a bug. If I tell
ap_send_fd to send one char more than the size of the file that I try to
send, it asserts and dumps core, the latter probably is bad.
[Fri Dec 21 02:03:29 2001] file core.c, line 2271, assertion
"total_bytes_left > 0 && tmplen > 0" failed
[Fri Dec 21 02:03:30 2001] [error] server reached MaxClients setting,
consider raising the MaxClients setting
[Fri Dec 21 02:03:30 2001] [notice] child pid 2607 exit signal Aborted
(6), possible coredump in /home/stas/apache.org/mp-subproc/t
Here is the trace:
#0 0x402aea41 in kill () from /lib/libc.so.6
#1 0x40272f9b in raise (sig=6) at signals.c:65
#2 0x402afe73 in abort () from /lib/libc.so.6
#3 0x080b853d in ap_log_assert () at log.c:569
#4 0x080c4ab7 in sendfile_it_all (c=0x8bbf9b0, fd=0x8bd17d0,
hdtr=0xbffff1d0,
file_offset=344, file_bytes_left=1, total_bytes_left=1, flags=1)
at core.c:2271
#5 0x080c5e7b in core_output_filter (f=0x8bbfc50, b=0x8bbfcc0) at
core.c:3314
#6 0x080bf3e9 in ap_pass_brigade (next=0x8bbfc50, bb=0x8bd1858)
at util_filter.c:388
#7 0x0808e440 in ap_http_header_filter (f=0x8bca888, b=0x8bd1858)
at http_protocol.c:1241
#8 0x080bf3e9 in ap_pass_brigade (next=0x8bca888, bb=0x8bd1858)
at util_filter.c:388
#9 0x080c10e5 in ap_content_length_filter (f=0x8bca870, b=0x8bd1858)
at protocol.c:994
#10 0x080bf3e9 in ap_pass_brigade (next=0x8bca870, bb=0x8bd1878)
at util_filter.c:388
#11 0x080c0a3c in end_output_stream (r=0x8bc38f0) at protocol.c:736
#12 0x08090338 in ap_process_request (r=0x8bc38f0) at http_request.c:301
#13 0x0808cb77 in ap_process_http_connection (c=0x8bbf9c0) at
http_core.c:280
#14 0x080bda27 in ap_run_process_connection (c=0x8bbf9c0) at connection.c:84
#15 0x080b42fe in child_main (child_num_arg=0) at prefork.c:684
---Type <return> to continue, or q <return> to quit---
#16 0x080b4443 in make_child (s=0x8bae9b8, slot=0) at prefork.c:772
#17 0x080b44a4 in startup_children (number_to_start=1) at prefork.c:795
#18 0x080b4789 in ap_mpm_run (_pconf=0x81025c8, plog=0x81486e0, s=0x8bae9b8)
at prefork.c:994
#19 0x080b9279 in main (argc=7, argv=0xbffff624) at main.c:457
#20 0x4029c6a0 in __libc_start_main () from /lib/libc.so.6
This is with:
*** /home/stas/httpd/prefork/bin/httpd -V
Server version: Apache/2.0.30-dev
Server built: Dec 18 2001 16:22:19
Server's Module Magic Number: 20011212:0
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
-D APR_USE_FCNTL_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/home/stas/httpd/prefork"
-D SUEXEC_BIN="/home/stas/httpd/prefork/bin/suexec"
-D DEFAULT_ERRORLOG="logs/error_log"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
uname -a
Linux hope.stason.org 2.4.8-19mdk #1 Wed Sep 5 16:41:25 CEST 2001 i686
unknown
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: core dump in ap_send_fd
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 21 December 2001 12:09 am, Stas Bekman wrote:
> William A. Rowe, Jr. wrote:
>
> > From: "Stas Bekman" <st...@stason.org>
> > Sent: Friday, December 21, 2001 12:14 AM
> >
> >
> >
> >>>In the meanwhile, you need to use the buckets directly.
> >>>It's only four lines of code as opposed to one.
> >>>
> >>>apr_bucket_brigade *bb = apr_brigade_create(r->pool);
> >>>apr_bucket *b = apr_bucket_pipe_create(thepipe);
> >>>APR_BRIGADE_INSERT_TAIL(bb, b);
> >>>ap_pass_brigade(bb);
> >>>
> >>
> >>can I use this for sending an opened file as well? given that I've a fd
> >>already opened from Perl. I use ap_os_file_put to convert it into
> >>apr_file_t.
> >>
> >
> > That is most certainly not portable. Win32, particularly, has alternate
> > semantics for opening files as 'sendfile ready'. Passing in an fd [which
> > would be a HANDLE on win32] isn't send-file-able.
>
>
> Please suggest a portable alternative. In 1.3.x we have:
>
> include/http_protocol.h:
> API_EXPORT(long) ap_send_fd_length(FILE *f, request_rec *r, long
> length);
>
> (which supported length=-1, for 'figure it out yourself')
>
> and it's being used in many places. When people move to 2.0 what can
> they do? Their code will break since this functionality is not available
> in APR.
It can't easily be done portably. We could do it in 1.3, because we relied
on POSIX, but that killed performance on non-Unix platforms. In 2.0, we
use APR to get better performance with good portability.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: core dump in ap_send_fd
Posted by Stas Bekman <st...@stason.org>.
Cliff Woolley wrote:
> On Sat, 22 Dec 2001, Stas Bekman wrote:
>
>
>>I think the misunderstanding started from the moment Cliff forwarded my
>>email, but snipped the end of it. At at the end it had:
>>
>>[Fri Dec 21 02:03:29 2001] file core.c, line 2271, assertion
>>"total_bytes_left > 0 && tmplen > 0" failed
>>[Fri Dec 21 02:03:30 2001] [error] server reached MaxClients setting,
>>consider raising the MaxClients setting
>>[Fri Dec 21 02:03:30 2001] [notice] child pid 2607 exit signal Aborted
>>(6), possible coredump in /home/stas/apache.org/mp-subproc/t
>>
>>I was just asking why if the code *does* the check and asserts
>>
>
> You must be in maintainer mode if it actually did the check.
yup!
>>(see the log before the stack trace), it also dumps core?
>
> Because that's what assert does. :) It exits with an Aborted signal,
> which triggers a coredump for debugging purposes. (coredump != SEGV)
OK, that explains everything. Sorry for bothering you with this.
>>My goal is somehow to get back the ability to take an OS specific fh
>>generated outside APR, convert it into apr_file_t and be able to use
>>send_fd optionally without specifying the length, as it was possible in
>>1.3.x.
>>
>
> Is it the case that you know whether the thing is a file or a pipe? If
> so, just use the correct kind of bucket directly. If you know the thing
> is a file and you just don't know the length, do the fseek/ftell yourself.
> The thing will be _way_ faster. If you give the buckets code a file
> descriptor and don't know the length, (assuming that were possible, which
> it currently isn't, unless you were to put the file into a pipe bucket),
> it would have to read the file 8KB at a time, rather than being able to
> MMAP it or sendfile() the fd. That's a massive amount of overhead that
> you probably want to avoid like the plague (I've benchmarked it... it's
> awful, even for files < 8KB).
>
> Just stop using ap_send_fd(). Use the buckets code directly. For one
> thing, you can save yourself some extra brigade-creation overhead, and you
> can probably save yourself a few calls down the filter stack as well.
> (And yes, the code I gave you the other day will work for files as well.
> While you could in theory put a file into a pipe bucket, I wouldn't
> recommend it.)
Thanks Cliff, I understand how to go about it now.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: core dump in ap_send_fd
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sat, 22 Dec 2001, Stas Bekman wrote:
> I think the misunderstanding started from the moment Cliff forwarded my
> email, but snipped the end of it. At at the end it had:
>
> [Fri Dec 21 02:03:29 2001] file core.c, line 2271, assertion
> "total_bytes_left > 0 && tmplen > 0" failed
> [Fri Dec 21 02:03:30 2001] [error] server reached MaxClients setting,
> consider raising the MaxClients setting
> [Fri Dec 21 02:03:30 2001] [notice] child pid 2607 exit signal Aborted
> (6), possible coredump in /home/stas/apache.org/mp-subproc/t
>
> I was just asking why if the code *does* the check and asserts
You must be in maintainer mode if it actually did the check.
> (see the log before the stack trace), it also dumps core?
Because that's what assert does. :) It exits with an Aborted signal,
which triggers a coredump for debugging purposes. (coredump != SEGV)
> My goal is somehow to get back the ability to take an OS specific fh
> generated outside APR, convert it into apr_file_t and be able to use
> send_fd optionally without specifying the length, as it was possible in
> 1.3.x.
Is it the case that you know whether the thing is a file or a pipe? If
so, just use the correct kind of bucket directly. If you know the thing
is a file and you just don't know the length, do the fseek/ftell yourself.
The thing will be _way_ faster. If you give the buckets code a file
descriptor and don't know the length, (assuming that were possible, which
it currently isn't, unless you were to put the file into a pipe bucket),
it would have to read the file 8KB at a time, rather than being able to
MMAP it or sendfile() the fd. That's a massive amount of overhead that
you probably want to avoid like the plague (I've benchmarked it... it's
awful, even for files < 8KB).
Just stop using ap_send_fd(). Use the buckets code directly. For one
thing, you can save yourself some extra brigade-creation overhead, and you
can probably save yourself a few calls down the filter stack as well.
(And yes, the code I gave you the other day will work for files as well.
While you could in theory put a file into a pipe bucket, I wouldn't
recommend it.)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: core dump in ap_send_fd
Posted by Stas Bekman <st...@stason.org>.
William A. Rowe, Jr. wrote:
> From: "Stas Bekman" <st...@stason.org>
> Sent: Friday, December 21, 2001 2:09 AM
>
>
>
>>Please suggest a portable alternative. In 1.3.x we have:
>>
>> include/http_protocol.h:
>> API_EXPORT(long) ap_send_fd_length(FILE *f, request_rec *r, long
>>length);
>>
>>(which supported length=-1, for 'figure it out yourself')
>>
>>and it's being used in many places. When people move to 2.0 what can
>>they do? Their code will break since this functionality is not available
>>in APR.
>>
>
> YES IT IS [if you use apr_file_t.]
But this if is crucial. In 1.3.x the operations were done on FILE*, so
you could convert between an external system and httpd both ways.
Currently if you can call apr_file_open you are all set, but if you have
to integrate with another system that already supplies you an opened fd
(or a handle, what not), you say that this won't work. How can you tell
that APR preserves back compatibility at this plane?
Please notice that I'm not trying to prove anything, I work on porting
send_fd glue for mod_perl which according to what you say won't work as
it did before. Which means that all the people who were using the
modperl 1.x API, will not have their code working without changes, which
may result in degraded performance.
> First, you should be able to choose -1 for a file as well (can we say, SendItAll?)
> If the sendfile semantic on a platform can't support SendItAll mode, then that
> platform will have to resolve the size with an fstat{size}-ftell(), at that time.
> Most sendfiles have no problem offering a SendItAll method.
>
> So as far as a file bucket, we aught to support -1 all the time. {certainly
> sub-optimal on some platforms, so avoid whenever you can.}
Great! How do we make 'should be able to choose -1' into APR?
>>>I doubt we will take the hit on an fstat() just to see if the coder
>>>had a clue about what they were doing.
>>>
>>Not really, in this case it's impossible to do the validation on the
>>user side if you are being handed a fd and a length. How can you check?
>>You don't have a path, just an already opened fd.
>>
>
> You need a handle for the win32 apr_os_file_put call;
>
> ((HANDLE)_get_osfhandle(fileno(fd))).
>
> But I was also apparently wrong about opening a file especially for sendfile.
>>>From the PSDK;
>
> Handle to the open file that the TransmitFile function transmits.
> Since operating system reads the file data sequentially, you can improve
> caching performance by opening the handle with FILE_FLAG_SEQUENTIAL_SCAN.
>
> So that's an option, not a requirement... the other side of the coin was the
> OVERLAPPED structure, but that's on the SOCKET - not on the file handle...
>
> If the socket handle has been opened as overlapped, specify this parameter
> in order to achieve an overlapped (asynchronous) I/O operation. By default,
> socket handles are opened as overlapped.
>
> Finally, the only other time that you must open the _FILE_ for overlapped IO
> is when you will pass the same filehandle to the server at the same moment on
> different threads [think file cache.] That's the odd APR_XTHREAD flag that
> some folks have wondered about. It's there to create a 'stateless' filehandle,
> if you look at the seek/read/write code in Win32, you will see we have to jump
> through hoops to do simple reads, since it won't maintain a seek/tell position.
> I don't expect we will support that at all through apr_os_file_put.
I think the misunderstanding started from the moment Cliff forwarded my
email, but snipped the end of it. At at the end it had:
[Fri Dec 21 02:03:29 2001] file core.c, line 2271, assertion
"total_bytes_left > 0 && tmplen > 0" failed
[Fri Dec 21 02:03:30 2001] [error] server reached MaxClients setting,
consider raising the MaxClients setting
[Fri Dec 21 02:03:30 2001] [notice] child pid 2607 exit signal Aborted
(6), possible coredump in /home/stas/apache.org/mp-subproc/t
Here is the trace:
#0 0x402aea41 in kill () from /lib/libc.so.6
#1 0x40272f9b in raise (sig=6) at signals.c:65
#2 0x402afe73 in abort () from /lib/libc.so.6
#3 0x080b853d in ap_log_assert () at log.c:569
#4 0x080c4ab7 in sendfile_it_all (c=0x8bbf9b0, fd=0x8bd17d0,
hdtr=0xbffff1d0,
file_offset=344, file_bytes_left=1, total_bytes_left=1, flags=1)
at core.c:2271
#5 0x080c5e7b in core_output_filter (f=0x8bbfc50, b=0x8bbfcc0) at
core.c:3314
#6 0x080bf3e9 in ap_pass_brigade (next=0x8bbfc50, bb=0x8bd1858)
at util_filter.c:388
#7 0x0808e440 in ap_http_header_filter (f=0x8bca888, b=0x8bd1858)
at http_protocol.c:1241
#8 0x080bf3e9 in ap_pass_brigade (next=0x8bca888, bb=0x8bd1858)
at util_filter.c:388
#9 0x080c10e5 in ap_content_length_filter (f=0x8bca870, b=0x8bd1858)
at protocol.c:994
#10 0x080bf3e9 in ap_pass_brigade (next=0x8bca870, bb=0x8bd1878)
at util_filter.c:388
#11 0x080c0a3c in end_output_stream (r=0x8bc38f0) at protocol.c:736
#12 0x08090338 in ap_process_request (r=0x8bc38f0) at http_request.c:301
#13 0x0808cb77 in ap_process_http_connection (c=0x8bbf9c0) at
http_core.c:280
#14 0x080bda27 in ap_run_process_connection (c=0x8bbf9c0) at connection.c:84
#15 0x080b42fe in child_main (child_num_arg=0) at prefork.c:684
---Type <return> to continue, or q <return> to quit---
#16 0x080b4443 in make_child (s=0x8bae9b8, slot=0) at prefork.c:772
#17 0x080b44a4 in startup_children (number_to_start=1) at prefork.c:795
#18 0x080b4789 in ap_mpm_run (_pconf=0x81025c8, plog=0x81486e0, s=0x8bae9b8)
at prefork.c:994
#19 0x080b9279 in main (argc=7, argv=0xbffff624) at main.c:457
#20 0x4029c6a0 in __libc_start_main () from /lib/libc.so.6
I was just asking why if the code *does* the check and asserts (see the
log before the stack trace), it also dumps core?
My goal is somehow to get back the ability to take an OS specific fh
generated outside APR, convert it into apr_file_t and be able to use
send_fd optionally without specifying the length, as it was possible in
1.3.x.
Thanks!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: core dump in ap_send_fd
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Stas Bekman" <st...@stason.org>
Sent: Friday, December 21, 2001 2:09 AM
> Please suggest a portable alternative. In 1.3.x we have:
>
> include/http_protocol.h:
> API_EXPORT(long) ap_send_fd_length(FILE *f, request_rec *r, long
> length);
>
> (which supported length=-1, for 'figure it out yourself')
>
> and it's being used in many places. When people move to 2.0 what can
> they do? Their code will break since this functionality is not available
> in APR.
YES IT IS [if you use apr_file_t.]
First, you should be able to choose -1 for a file as well (can we say, SendItAll?)
If the sendfile semantic on a platform can't support SendItAll mode, then that
platform will have to resolve the size with an fstat{size}-ftell(), at that time.
Most sendfiles have no problem offering a SendItAll method.
So as far as a file bucket, we aught to support -1 all the time. {certainly
sub-optimal on some platforms, so avoid whenever you can.}
> > I doubt we will take the hit on an fstat() just to see if the coder
> > had a clue about what they were doing.
>
> Not really, in this case it's impossible to do the validation on the
> user side if you are being handed a fd and a length. How can you check?
> You don't have a path, just an already opened fd.
You need a handle for the win32 apr_os_file_put call;
((HANDLE)_get_osfhandle(fileno(fd))).
But I was also apparently wrong about opening a file especially for sendfile.
>From the PSDK;
Handle to the open file that the TransmitFile function transmits.
Since operating system reads the file data sequentially, you can improve
caching performance by opening the handle with FILE_FLAG_SEQUENTIAL_SCAN.
So that's an option, not a requirement... the other side of the coin was the
OVERLAPPED structure, but that's on the SOCKET - not on the file handle...
If the socket handle has been opened as overlapped, specify this parameter
in order to achieve an overlapped (asynchronous) I/O operation. By default,
socket handles are opened as overlapped.
Finally, the only other time that you must open the _FILE_ for overlapped IO
is when you will pass the same filehandle to the server at the same moment on
different threads [think file cache.] That's the odd APR_XTHREAD flag that
some folks have wondered about. It's there to create a 'stateless' filehandle,
if you look at the seek/read/write code in Win32, you will see we have to jump
through hoops to do simple reads, since it won't maintain a seek/tell position.
I don't expect we will support that at all through apr_os_file_put.
Bill
Re: core dump in ap_send_fd
Posted by Stas Bekman <st...@stason.org>.
William A. Rowe, Jr. wrote:
> From: "Stas Bekman" <st...@stason.org>
> Sent: Friday, December 21, 2001 12:14 AM
>
>
>
>>>In the meanwhile, you need to use the buckets directly.
>>>It's only four lines of code as opposed to one.
>>>
>>>apr_bucket_brigade *bb = apr_brigade_create(r->pool);
>>>apr_bucket *b = apr_bucket_pipe_create(thepipe);
>>>APR_BRIGADE_INSERT_TAIL(bb, b);
>>>ap_pass_brigade(bb);
>>>
>>
>>can I use this for sending an opened file as well? given that I've a fd
>>already opened from Perl. I use ap_os_file_put to convert it into
>>apr_file_t.
>>
>
> That is most certainly not portable. Win32, particularly, has alternate
> semantics for opening files as 'sendfile ready'. Passing in an fd [which
> would be a HANDLE on win32] isn't send-file-able.
Please suggest a portable alternative. In 1.3.x we have:
include/http_protocol.h:
API_EXPORT(long) ap_send_fd_length(FILE *f, request_rec *r, long
length);
(which supported length=-1, for 'figure it out yourself')
and it's being used in many places. When people move to 2.0 what can
they do? Their code will break since this functionality is not available
in APR.
Thanks!
>>>Um, why would you ever do that and expect it to work? I mean, I
guess we
>>>could theoretically check the length you pass in against the length
of the
>>>file, but that goes against the
>>>we-expect-the-caller-to-pass-us-sane-arguments mentality that we
typically
>>>maintain around here.
>>>
>>Well, I don't think it is normal to dump core if some of the
arguments is not proper,
>>
>>especially in this case where it's just the count that can be wrong.
But that bothers me less,
>>
>>if you think it's fine to core dump, rather than cleanly exit with an
error message :)
>>
>
> Where are we going with this, to the win32-friendly and safe api?
<eyeballs rolling>
>
> Seriously, we've made a very consiencious decision in APR not to
check safety
> on user args.
>
> If mod-perl needs to be the 'safe and simple' solution - it will need
to wrap
> up perl with arg checking itself. This is simply not compatible with
anyone's
> vision of APR performance. We have enough arguments over
debug-asserts, that
> I doubt we will take the hit on an fstat() just to see if the coder
had a clue
> about what they were doing.
Not really, in this case it's impossible to do the validation on the
user side if you are being handed a fd and a length. How can you check?
You don't have a path, just an already opened fd.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: core dump in ap_send_fd
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Stas Bekman" <st...@stason.org>
Sent: Friday, December 21, 2001 12:14 AM
> > In the meanwhile, you need to use the buckets directly.
> > It's only four lines of code as opposed to one.
> >
> > apr_bucket_brigade *bb = apr_brigade_create(r->pool);
> > apr_bucket *b = apr_bucket_pipe_create(thepipe);
> > APR_BRIGADE_INSERT_TAIL(bb, b);
> > ap_pass_brigade(bb);
>
>
> can I use this for sending an opened file as well? given that I've a fd
> already opened from Perl. I use ap_os_file_put to convert it into
> apr_file_t.
That is most certainly not portable. Win32, particularly, has alternate
semantics for opening files as 'sendfile ready'. Passing in an fd [which
would be a HANDLE on win32] isn't send-file-able.
> > Um, why would you ever do that and expect it to work? I mean, I guess we
> > could theoretically check the length you pass in against the length of the
> > file, but that goes against the
> > we-expect-the-caller-to-pass-us-sane-arguments mentality that we typically
> > maintain around here.
>
> Well, I don't think it is normal to dump core if some of the arguments is not proper,
>
> especially in this case where it's just the count that can be wrong. But that bothers me less,
>
> if you think it's fine to core dump, rather than cleanly exit with an error message :)
Where are we going with this, to the win32-friendly and safe api? <eyeballs rolling>
Seriously, we've made a very consiencious decision in APR not to check safety
on user args.
If mod-perl needs to be the 'safe and simple' solution - it will need to wrap
up perl with arg checking itself. This is simply not compatible with anyone's
vision of APR performance. We have enough arguments over debug-asserts, that
I doubt we will take the hit on an fstat() just to see if the coder had a clue
about what they were doing.
Re: core dump in ap_send_fd
Posted by Stas Bekman <st...@stason.org>.
Cliff Woolley wrote:
> [moving this to dev@httpd since it's an httpd issue]
>
>
> On Fri, 21 Dec 2001, Stas Bekman wrote:
>
>
>>ap_send_fd expects the length of the input to send.
>>
>>First of all is there a way not to specify the length? I've a fd (can be
>>a pipe to a process), and I've no way to figure out the length of the
>>output. How APR can handle this? This breaks the compatibility with
>>send_fd from httpd-1.3.x.
>>
>
> You don't want to send a pipe with ap_send_fd() in Apache 2.0, as it would
> put the pipe in a file bucket, which is wrong.
Agreed. But it breaks the backwards compatibility with ap_send_fd from
1.3.x. I am porting ap_send_fd for mod_perl 2.0 and it has to stay the same.
> Maybe we should add an
> ap_send_pipe(), or maybe we should change the ap_send_fd() API to accept
> -1 as a magic length and to recognize it as meaning the thing is a pipe
> not a file.
Yup, that's how it was in 1.3.x's version.
which will work for files as well. If you can do that, the problem is
solved.
> In the meanwhile, you need to use the buckets directly.
> It's only four lines of code as opposed to one.
>
> apr_bucket_brigade *bb = apr_brigade_create(r->pool);
> apr_bucket *b = apr_bucket_pipe_create(thepipe);
> APR_BRIGADE_INSERT_TAIL(bb, b);
> ap_pass_brigade(bb);
can I use this for sending an opened file as well? given that I've a fd
already opened from Perl. I use ap_os_file_put to convert it into
apr_file_t.
Does using a ap_send_pipe (from above) instead of a ap_send_fd have any
performance implications? Other than the fact that the fast native
sendfile won't be used for sending real files?
>>Second, I've found something that appears to be a bug. If I tell
>>ap_send_fd to send one char more than the size of the file that I try to
>>send, it asserts and dumps core, the latter probably is bad.
>>
>
> Um, why would you ever do that and expect it to work? I mean, I guess we
> could theoretically check the length you pass in against the length of the
> file, but that goes against the
> we-expect-the-caller-to-pass-us-sane-arguments mentality that we typically
> maintain around here.
Well, I don't think it is normal to dump core if some of the arguments is not proper,
especially in this case where it's just the count that can be wrong. But that bothers me less,
if you think it's fine to core dump, rather than cleanly exit with an error message :)
Thanks Cliff,
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: core dump in ap_send_fd
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 20 Dec 2001, Cliff Woolley wrote:
> apr_bucket_brigade *bb = apr_brigade_create(r->pool);
> apr_bucket *b = apr_bucket_pipe_create(thepipe);
> APR_BRIGADE_INSERT_TAIL(bb, b);
> ap_pass_brigade(bb);
That last line should have been
ap_pass_brigade(r->output_filters, bb);
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: core dump in ap_send_fd
Posted by Cliff Woolley <cl...@yahoo.com>.
[moving this to dev@httpd since it's an httpd issue]
On Fri, 21 Dec 2001, Stas Bekman wrote:
> ap_send_fd expects the length of the input to send.
>
> First of all is there a way not to specify the length? I've a fd (can be
> a pipe to a process), and I've no way to figure out the length of the
> output. How APR can handle this? This breaks the compatibility with
> send_fd from httpd-1.3.x.
You don't want to send a pipe with ap_send_fd() in Apache 2.0, as it would
put the pipe in a file bucket, which is wrong. Maybe we should add an
ap_send_pipe(), or maybe we should change the ap_send_fd() API to accept
-1 as a magic length and to recognize it as meaning the thing is a pipe
not a file. In the meanwhile, you need to use the buckets directly.
It's only four lines of code as opposed to one.
apr_bucket_brigade *bb = apr_brigade_create(r->pool);
apr_bucket *b = apr_bucket_pipe_create(thepipe);
APR_BRIGADE_INSERT_TAIL(bb, b);
ap_pass_brigade(bb);
> Second, I've found something that appears to be a bug. If I tell
> ap_send_fd to send one char more than the size of the file that I try to
> send, it asserts and dumps core, the latter probably is bad.
Um, why would you ever do that and expect it to work? I mean, I guess we
could theoretically check the length you pass in against the length of the
file, but that goes against the
we-expect-the-caller-to-pass-us-sane-arguments mentality that we typically
maintain around here.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA