httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Wulms <alex.wu...@scarlet.be>
Subject Re: Error log format configuration syntax
Date Wed, 28 Jul 2010 07:51:08 GMT
Hi,

While adding some debug log statements to a module I'm working on, I ran
into the problem that ap_log_error (in apache 2.2) does not support %zd
or %zu conversion for type_t arguments. This was problematic to make the
code compile on both 32 and 64 bit platforms. So I made a small wrapper
(see below) to workaround the problem. I suggest to build support for
%zd and %zu conversion into the unified logger.

/**
 * ap_log_error does not support %zd or %zu conversion for type_t arguments
 * So with ap_log_error one would have to specify either %d or %ld,
depending on the
 * platform (32-bit or 64-bit). This violates the whole purpose of
type_t, which
 * was introduced in C exactly to provide cross-platform compatibility...
 * This wrapper function supports %zd and %zu conversion parameters.
 * Note that it truncates the logged message to 1000 bytes, so don't use
it to log messages that might
 * be longer
 */
void ap_log_error_wrapper(const char *file, int line, int level,
apr_status_t status, const server_rec *s,
        const char *fmt, ...)
{
    char msg[1000];
    va_list ap;
    va_start(ap, fmt);
    vsnprintf(msg, sizeof(msg), fmt, ap);
    ap_log_error(file, line, level, status, s, "%s", msg);
}




Cheers,
Alex




Op 27-07-10 23:11, Stefan Fritsch schreef:
> On Wednesday 21 July 2010, William A. Rowe Jr. wrote:
>   
>> On 7/21/2010 4:35 PM, Stefan Fritsch wrote:
>>     
>>> And I agree that a unified logging formatter would be nice, but
>>> this is not something that will be done before 2.3.7 and it
>>> would likely mean an incompatible API change for modules
>>> providing handlers for mod_log_config. IMHO, this can wait until
>>> 3.0.
>>>       
>> IMHO, it must not.  The simple reason is that the more code
>> duplication we introduce, the more opportunity for flaws and
>> maintenance headaches during the 2.4 lifecycle.  I'd accept
>> waiting for this entire custom error log feature for 3.0, but
>> really would rather introduce it sooner and not later.
>>     
> I fear a unified logging formatter may either delay 2.4 or not make it 
> into 2.4. In 2.4, we really need some way to omit some of the fields 
> we currently have in the error log prefix (> 100 chars of prefix is 
> insane). But as I had less time in the last few days than I hoped, it 
> does not look like my (non-unified) errorlog formatter would be ready 
> for 2.3.7 in any case. So we will have time until 2.3.8 to decide what 
> to do.
>
>   
>> If there is a resulting API change, I think everyone is willing to
>> accept this during the 2.3-alpha/beta cycle.  2.4.0 is our
>> 'lockdown'.
>>
>> I'm willing to help with this code, although I'm just starting to
>> dig out of the hole from my two recent hand surgeries.  6-finger
>> typing isn't all that efficient :)
>>     
> I think there are more important things that could use your and my 
> attention than avoiding this bit of code duplication.
>
>
> Buf if you want to start a bit of technical discussion: The main 
> technical difference between error and access log is that for the 
> access log, everything is allocated from the request pool and then 
> written to the log file (i.e. there is no length limit). For the error
> log, there is a fixed 8K buffer (allocated on the stack). For the
> error log, it is not possible to use any of the existing pools to
> avoid unbounded memory usage. The unified log formatter would either
> have to use a pre-allocated buffer or a temp pool.
>
> For my work on the error log formatter, I have stayed with the pre- 
> allocated buffer. Would this be a reasonable solution for the unified 
> logger? It would mean a fixed limit for the access logs lines (though 
> the access log could use a larger buffer than the error log, I guess 
> 16 or 32K would be enough even for the access log). The pool approach 
> would require a per-thread temp logging pool (using 
> apr_threadkey_private_create or the like) or creating and destroying a 
> sub-pool for every log line.
>
> Which solution looks better to you?
>
>
> Cheers,
> Stefan
>
>   


Mime
View raw message