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 naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel