apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Crash in apr_file_close() (Linux)
Date Fri, 16 Oct 2009 13:13:39 GMT
On 16/10/09 11:21, Joe Orton wrote:
> On Fri, Oct 16, 2009 at 11:17:17AM +0200, Mladen Turk wrote:
>> each invocation to apr_file_open_stdout creates a new apr_file_t so
>> each fd->filedes has a value of STDOUT_FILENO.
>> This is the same as calling:
>> close(1);
>> close(1);
>
> Oh, good point.  This is rather horrible :(.  I'm not sure what can be
> done about it, we can't change apr_file_open_stdout() to do a dup()
> internally, since that would break existing apps.
>

I'm not sure why do we call close(0..2) for std files when
the apr_file_open_std* is closed or it's pool destroyed at the
first place.

Reading the:
  * @remark The only reason that the apr_file_open_std* functions exist
  * is that you may not always have a stderr/out/in on Windows.  This
  * is generally a problem with newer versions of Windows and services.

So apr_file_open_std* should just reference the existing
system descriptors. However it behaves like 'attach' rather then open,
meaning once you open it you will destroy the system stdin/stdout/stderr.
Thus by design it's a singleton operation, so if desired,
the second invocation during the process lifetime should always
return EBADF for apr_file_open_std* thought.


Very confusing.


Regards
-- 
^TM


Mime
View raw message