Menu
▾
▴
naviserver-devel
|
From: Vlad S. <vl...@cr...> - 2007-10-12 22:05:11
|
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 |
|
From: Gustaf N. <ne...@wu...> - 2007-10-12 22:37:43
|
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 > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vlad S. <vl...@cr...> - 2007-10-12 22:43:33
|
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 >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> > > > ------------------------------------------------------------------------- > 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 > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Gustaf N. <ne...@wu...> - 2007-10-13 16:46:37
|
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
>>>
>>>
|
|
From: Vlad S. <vl...@cr...> - 2007-10-13 17:50:32
|
When i replaced Ns_VALog with pure vfprintf it does not crash anymore, so it is definitely something with passing va_list. I tried as discussed here but it still crashes: http://osdir.com/ml/redhat.amd64/2006-12/msg00001.html void Ns_Log(Ns_LogSeverity severity, CONST char *fmt, ...) { va_list ap; va_start(ap, fmt); vfprintf(stderr, fmt, ap); fprintf(stderr, "\n"); //Ns_VALog(severity, fmt, ap); va_end(ap); } Gustaf Neumann wrote: > 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 > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Vlad S. <vl...@cr...> - 2007-10-13 18:11:51
|
I was able to find the location which causes the crash but i am not sure
how to fix it
In function Ns_VALog i call vsnprintf directly, it works, when it is
called via Ns_DStringVPintf it crashes. using va_copy does not help
{
char buf[4096];
vsnprintf(buf, sizeof(buf), fmt, *vaPtr);
Ns_DStringAppend(&cachePtr->buffer, buf);
}
//Ns_DStringVPrintf(&cachePtr->buffer, fmt, *vaPtr);
Gustaf Neumann wrote:
> 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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Vlad S. <vl...@cr...> - 2007-10-13 18:31:57
|
with included old dsprintf.c it works fine
Vlad Seryakov wrote:
> I was able to find the location which causes the crash but i am not sure
> how to fix it
>
> In function Ns_VALog i call vsnprintf directly, it works, when it is
> called via Ns_DStringVPintf it crashes. using va_copy does not help
>
>
> {
> char buf[4096];
> vsnprintf(buf, sizeof(buf), fmt, *vaPtr);
> Ns_DStringAppend(&cachePtr->buffer, buf);
> }
> //Ns_DStringVPrintf(&cachePtr->buffer, fmt, *vaPtr);
>
>
> Gustaf Neumann wrote:
>> 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
>> nav...@li...
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
>
--
Vlad Seryakov
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Stephen D. <sd...@gm...> - 2007-10-13 19:09:01
|
On 10/13/07, Vlad Seryakov <vl...@cr...> wrote:
> I was able to find the location which causes the crash but i am not sure
> how to fix it
>
> In function Ns_VALog i call vsnprintf directly, it works, when it is
> called via Ns_DStringVPintf it crashes. using va_copy does not help
>
diff -r 22a912b584eb nsd/dstring.c
--- a/nsd/dstring.c Fri Oct 12 20:35:13 2007 +0100
+++ b/nsd/dstring.c Sat Oct 13 19:46:22 2007 +0100
@@ -176,10 +176,11 @@ Ns_DStringPrintf(Ns_DString *dsPtr, CONS
*/
char *
-Ns_DStringVPrintf(Ns_DString *dsPtr, CONST char *fmt, va_list ap)
-{
- char *buf;
- int origLength, newLength, bufLength, result;
+Ns_DStringVPrintf(Ns_DString *dsPtr, CONST char *fmt, va_list apSrc)
+{
+ char *buf;
+ int origLength, newLength, bufLength, result;
+ va_list ap;
origLength = dsPtr->length;
@@ -205,11 +206,13 @@ Ns_DStringVPrintf(Ns_DString *dsPtr, CON
buf = dsPtr->string + origLength;
bufLength = newLength - origLength;
+ va_copy(ap, apSrc);
#ifdef __WIN32
result = _vsnprintf_s(buf, bufLength, fmt, ap);
#else
result = vsnprintf(buf, bufLength, fmt, ap);
#endif
+ va_end(ap);
/*
* Check for overflow and retry. For win32 just double the buffer size
@@ -229,11 +232,13 @@ Ns_DStringVPrintf(Ns_DString *dsPtr, CON
buf = dsPtr->string + origLength;
bufLength = newLength - origLength;
+ va_copy(ap, apSrc);
#ifdef __WIN32
result = _vsnprintf_s(buf, bufLength, fmt, ap);
#else
result = vsnprintf(buf, bufLength, fmt, ap);
#endif
+ va_end(ap);
}
|
|
From: Vlad S. <vl...@cr...> - 2007-10-13 19:12:49
|
Yes, works fine now, Thanks
Stephen Deasey wrote:
> On 10/13/07, Vlad Seryakov <vl...@cr...> wrote:
>> I was able to find the location which causes the crash but i am not sure
>> how to fix it
>>
>> In function Ns_VALog i call vsnprintf directly, it works, when it is
>> called via Ns_DStringVPintf it crashes. using va_copy does not help
>>
>
>
> diff -r 22a912b584eb nsd/dstring.c
> --- a/nsd/dstring.c Fri Oct 12 20:35:13 2007 +0100
> +++ b/nsd/dstring.c Sat Oct 13 19:46:22 2007 +0100
> @@ -176,10 +176,11 @@ Ns_DStringPrintf(Ns_DString *dsPtr, CONS
> */
>
> char *
> -Ns_DStringVPrintf(Ns_DString *dsPtr, CONST char *fmt, va_list ap)
> -{
> - char *buf;
> - int origLength, newLength, bufLength, result;
> +Ns_DStringVPrintf(Ns_DString *dsPtr, CONST char *fmt, va_list apSrc)
> +{
> + char *buf;
> + int origLength, newLength, bufLength, result;
> + va_list ap;
>
> origLength = dsPtr->length;
>
> @@ -205,11 +206,13 @@ Ns_DStringVPrintf(Ns_DString *dsPtr, CON
> buf = dsPtr->string + origLength;
> bufLength = newLength - origLength;
>
> + va_copy(ap, apSrc);
> #ifdef __WIN32
> result = _vsnprintf_s(buf, bufLength, fmt, ap);
> #else
> result = vsnprintf(buf, bufLength, fmt, ap);
> #endif
> + va_end(ap);
>
> /*
> * Check for overflow and retry. For win32 just double the buffer size
> @@ -229,11 +232,13 @@ Ns_DStringVPrintf(Ns_DString *dsPtr, CON
> buf = dsPtr->string + origLength;
> bufLength = newLength - origLength;
>
> + va_copy(ap, apSrc);
> #ifdef __WIN32
> result = _vsnprintf_s(buf, bufLength, fmt, ap);
> #else
> result = vsnprintf(buf, bufLength, fmt, ap);
> #endif
> + va_end(ap);
> }
>
> -------------------------------------------------------------------------
> 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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Stephen D. <sd...@gm...> - 2007-10-15 18:32:49
|
On 10/15/07, Vlad Seryakov <vl...@cr...> wrote:
> The only thing which broke my old code regarding switching to vsnprintf
> is that old Ns_DStringPrintf handled empty string differently, vsnprintf
> now puts (null), before that empty string did not put anything.
>
> I still need to review si the damage is critical enough or never upgrade
> until all code updated. That sucks
The printf familly calls make no guarantee about NULLs. If we're
relying on that anywhere in the code it's a bug and we need to fix it.
e.g.:
Ns_Log(Warning, "huh?: %s", nullable ? nullable : "uh-oh");
Otherwise, we can expect crashes.
|
|
From: Vlad S. <vl...@cr...> - 2007-10-15 18:41:15
|
yes, i know, i am complaining about myself relying on particular formatting. Stephen Deasey wrote: > On 10/15/07, Vlad Seryakov <vl...@cr...> wrote: >> The only thing which broke my old code regarding switching to vsnprintf >> is that old Ns_DStringPrintf handled empty string differently, vsnprintf >> now puts (null), before that empty string did not put anything. >> >> I still need to review si the damage is critical enough or never upgrade >> until all code updated. That sucks > > > The printf familly calls make no guarantee about NULLs. If we're > relying on that anywhere in the code it's a bug and we need to fix it. > > e.g.: > > Ns_Log(Warning, "huh?: %s", nullable ? nullable : "uh-oh"); > > > Otherwise, we can expect crashes. > > ------------------------------------------------------------------------- > 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 > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vlad S. <vl...@cr...> - 2007-10-15 17:44:24
|
The only thing which broke my old code regarding switching to vsnprintf
is that old Ns_DStringPrintf handled empty string differently, vsnprintf
now puts (null), before that empty string did not put anything.
I still need to review si the damage is critical enough or never upgrade
until all code updated. That sucks
Vlad Seryakov wrote:
> Yes, works fine now, Thanks
>
> Stephen Deasey wrote:
>> On 10/13/07, Vlad Seryakov <vl...@cr...> wrote:
>>> I was able to find the location which causes the crash but i am not sure
>>> how to fix it
>>>
>>> In function Ns_VALog i call vsnprintf directly, it works, when it is
>>> called via Ns_DStringVPintf it crashes. using va_copy does not help
>>>
>>
>> diff -r 22a912b584eb nsd/dstring.c
>> --- a/nsd/dstring.c Fri Oct 12 20:35:13 2007 +0100
>> +++ b/nsd/dstring.c Sat Oct 13 19:46:22 2007 +0100
>> @@ -176,10 +176,11 @@ Ns_DStringPrintf(Ns_DString *dsPtr, CONS
>> */
>>
>> char *
>> -Ns_DStringVPrintf(Ns_DString *dsPtr, CONST char *fmt, va_list ap)
>> -{
>> - char *buf;
>> - int origLength, newLength, bufLength, result;
>> +Ns_DStringVPrintf(Ns_DString *dsPtr, CONST char *fmt, va_list apSrc)
>> +{
>> + char *buf;
>> + int origLength, newLength, bufLength, result;
>> + va_list ap;
>>
>> origLength = dsPtr->length;
>>
>> @@ -205,11 +206,13 @@ Ns_DStringVPrintf(Ns_DString *dsPtr, CON
>> buf = dsPtr->string + origLength;
>> bufLength = newLength - origLength;
>>
>> + va_copy(ap, apSrc);
>> #ifdef __WIN32
>> result = _vsnprintf_s(buf, bufLength, fmt, ap);
>> #else
>> result = vsnprintf(buf, bufLength, fmt, ap);
>> #endif
>> + va_end(ap);
>>
>> /*
>> * Check for overflow and retry. For win32 just double the buffer size
>> @@ -229,11 +232,13 @@ Ns_DStringVPrintf(Ns_DString *dsPtr, CON
>> buf = dsPtr->string + origLength;
>> bufLength = newLength - origLength;
>>
>> + va_copy(ap, apSrc);
>> #ifdef __WIN32
>> result = _vsnprintf_s(buf, bufLength, fmt, ap);
>> #else
>> result = vsnprintf(buf, bufLength, fmt, ap);
>> #endif
>> + va_end(ap);
>> }
>>
>> -------------------------------------------------------------------------
>> 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
>> nav...@li...
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X