Hi,
I noticed this bug a few months ago but I haven't gotten around to really looking for a solution until recently. When TF 5.0b8 is compiled under (at least some versions of) the amd64 platform, the /ps command at best shows garbled output and at worst crashes TF. A scenario is as follows:
> /repeat -0:1:00 5 /echo monkey
> /ps
PID NEXT T D WORLD PTIME COUNT COMMAND
1 0:01:00 r 5 @a
> /ps
PID NEXT T D WORLD PTIME COUNT COMMAND
[Standard segfault message displayed here]
I dug around in the source code and C function man pages and I'm pretty sure I found the solution, although I'm not sure if my patch is as elegant as it could be. I'm using gentoo linux, and when I compiled as 32-bit it works fine, but 64-bit is broken. It seems that under the 32-bit C library, vsprintf() does not modify the va_list passed to it, while the 64-bit library eats the argument it uses from the va_list, so vSprintf()'s handling of integers eats one more arg than intended per iteration under 64-bit.
Logged In: YES
user_id=1664717
Originator: NO
Thanks for the analysis and the patch. I did not know this before, but according to C99, vsprintf() leaves its va_arg argument in an indeterminate state in the caller, so the only sure way to keep a known state is like you did with va_copy(). The only thing I'll do differently is add an #ifdef va_copy test for pre-C99 platforms. The fix will be included in the next release of tf.