Menu

#4 amd64 /ps problem

5.0 beta 8
closed-fixed
nobody
Bug: fatal (10)
5
2007-02-05
2007-02-02
Joe Pelkey
No

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.

Discussion

  • Joe Pelkey

    Joe Pelkey - 2007-02-02
     
  • Ken Keys

    Ken Keys - 2007-02-05
    • status: open --> closed-fixed
     
  • Ken Keys

    Ken Keys - 2007-02-05

    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.

     

Log in to post a comment.