Varargs issues

[Peter Wemm]

Adriaan de Groot wrote:
> [aside: most-recent cvsup doesn't compile without options SMP, due to that
> mp_maxid issue]
> 
> amd64/59650 is a PR of mine that I'd like to pimp for attention. The
> real and present effect is that the ogg123 program from the vorbis-tools
> port bus errors, but there's several test programs - even a short one - in
> the PR. The problem still persists in a system rebuilt on the 23rd, and
> I'm still waiting to see if today's builds are stable (ie. boot at all) to
> test it on that.
> 
> The problem with the problem is that (a) I've no idea if I'm linking
> everything correcly or need to do other thread magic (if so, the ogg12 app
> has the same issues) and (b) I only have one amd64 box, so there's
> a chance that the problem is purely local, even. Could someone, anyone,
> run the test program in order to confirm (or deny) the problem? 'cause if
> it _is_ a problem, then it potentially affects any application that does
> threading.

The biggest problem is that 'va_args ap' is a pointer, not an integral
copyable type.  There are a few programs that do this sort of thing:

foo(int param, va_args ap)
{
	va_args ap2;

	ap2 = ap;
	vprintf(..., ap2);
	vprintf(..., ap);
}

You can get away with this on i386, ia64, sparc64, alpha because the assignment
copies the entire state, while on amd64 and powerpc, you're just copying a
pointer to the state.  And as a result, the arguments are incrementally
emptied out each time its used, instead of resetting back to the first arg.

The official way to do this is:
	va_copy(ap2, ap);
	vprintf(..., ap2);
	vprintf(..., ap);
..

However, I suspect the real problem with the ogg123 stuff is that there is
likely a missing #ifdef and its defaulting to assuming that longs are 32 bit.
mpg123 had the exact same problem FWIW.

Cheers,
-Peter
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5