httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: core dump in ap_send_fd
Date Fri, 21 Dec 2001 18:07:45 GMT
William A. Rowe, Jr. wrote:

> From: "Stas Bekman" <stas@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/


Mime
View raw message