Re: svn commit: r568779 - /httpd/httpd/trunk/server/main.c

On 08/23/2007 02:10 AM, wroweapache.org wrote:
> Author: wrowe
> Date: Wed Aug 22 17:10:35 2007
> New Revision: 568779
> 
> URL: 
http://svn.apache.org/viewvc?rev=568779&view=rev
> Log:
> main core: Emit errors during the initial
apr_app_initialize()
> or apr_pool_create() (when apr-based error reporting is
not ready).

In general this looks correct, but could you please give me
a pointer
what exactly fails with ap_log_error?
Why is it safe to use apr_ctime() and apr_time_now() in this
case?
It would help me to better understand the problem and the
reasoning.


Regards

Rüdiger

Ruediger Pluem wrote:
> 
> On 08/23/2007 02:10 AM, wroweapache.org wrote:
>> Author: wrowe
>> Date: Wed Aug 22 17:10:35 2007
>> New Revision: 568779
>>
>> URL: 
http://svn.apache.org/viewvc?rev=568779&view=rev
>> Log:
>> main core: Emit errors during the initial
apr_app_initialize()
>> or apr_pool_create() (when apr-based error
reporting is not ready).
> 
> In general this looks correct, but could you please
give me a pointer
> what exactly fails with ap_log_error?
> Why is it safe to use apr_ctime() and apr_time_now() in
this case?
> It would help me to better understand the problem and
the reasoning.

Presume apr is not initialized; it refuses to create our
process->pool,
or (in 2.0) the global NULL pool.

apr_ctime and apr_time_now, *fortunately* do no pool
allocation.

I was near ready to log this as "- [crit] bad thing
happened", until
I audited ctime and time_now.

Yes, there's an implicit assumption that ctime and time_now
won't end
up with a pool allocation.  Yes, there's near no likelyhood
that this
would not function.  But on the off chance that mutexes or
other APR
resources are too corrupt in the kernel to complete
apr_init, we
should at least give the server a fighting chance to scream
it's final
death.

Bill