there is nothing wrong on using *va_list in general.
the problem is rather in vsnprintf, which does most probably
a loop like in Ns_DStringVarAppend
char *
Ns_DStringVarAppend(Ns_DString *dsPtr, ...)
{
register char *s;
va_list ap;
va_start(ap, dsPtr);
while ((s = va_arg(ap, char *)) != NULL) {
Ns_DStringAppend(dsPtr, s);
}
va_end(ap);
return dsPtr->string;
}
which fails, when the va_list is terminated by 0 and not (char*)NULL.
however, this should not account for the problem with vsnprintf(),
which should not read more arguments as indicated by the fmt string.
You are the, the number of %-codes corresponds to the arguments?
Is the error produced via Ns_TclLogErrorInfo() ?
What happens, if you add at the end of the vararglist in the call
causing the problem a (char*)NULL)?
-gustaf neumann
Vlad Seryakov schrieb:
> I use ns_log or Ns_Log, so it should take care about it, it ends up in
> Ns_DStringPrintf which calls vsnprintf.
>
>
> Is it correct in x64 to pass *va_list?
>
> Ns_VALog(Ns_LogSeverity severity, CONST char *fmt, va_list *vaPtr)
>
> Gustaf Neumann wrote:
>
>> be sure to terminate va_* argument lists with NULL (or to be on the safe
>> side
>> with (char*)NULL) and not with 0. when you have sizeof(int) !=
>> sizeof(char *),
>> the compiler will put a 32bit for 0, a comparison with a 64bit null
>> pointer
>> will fail. I am pretty sure, the vsnprintf() tries to write an error
>> message....
>> and misses the end of the var arg list....
>>
>> -gustaf neumann
>>
>> PS: fixed a similar issue in xotcl more than a year ago.
>>
>> Vlad Seryakov schrieb:
>>
>>> Hi,
>>>
>>> This is an example when it crashes inside vsnprintf, experimenting i
>>> found that issuing long unknown command crashes as well. In my case i
>>> noticed that trying to log long lines does not work as well. In x32
>>> everything works fine
>>>
>>> db:vlad[18:01:19]#uname -a
>>> Linux db 2.6.22-ARCH #1 SMP PREEMPT Thu Oct 4 11:47:51 EDT 2007 x86_64
>>> Intel(R) Xeon(R) CPU X5355 @ 2.66GHz GenuineIntel GNU/Linux
>>>
>>>
>>> ossweb:nscp 1>
>>> ossweb:nscp 1> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>>>
>>>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
naviserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/naviserver-devel