gdb problems with args to functions after a vararg routine

[Sean McNeil]

I've noticed this lately and have a clear-cut example where things look
right but something is certainly off:

seahorse crashes for me on amd64-current during initialization.  The
backtrace looks ok until I get to a vararg call and then it looks like
arguments to funtion call further down the trace are hosed.

For instance, this call actually has one parameter after it that is the
vararg item:

#3  0x0000000202f43382 in g_signal_new (signal_name=0x41adec "add",
    itype=5714304, signal_flags=G_SIGNAL_RUN_LAST, class_offset=160,
    accumulator=0, accu_data=0x0, c_marshaller=0x1, return_type=4,
n_params=1)
    at gsignal.c:1130

then the next call looks sane and correct

#2  0x0000000202f44b98 in g_signal_new_valist (signal_name=0x41adec
"add",
    itype=5714304, signal_flags=G_SIGNAL_RUN_LAST,
class_closure=0x56f980,
    accumulator=0, accu_data=0x0, c_marshaller=0x1, return_type=1,
n_params=1,
    args=0x7fffffffe2e0) at gsignal.c:1370

but then it messes up with

#1  0x0000000202f43faa in g_signal_newv (signal_name=0x0, itype=5714304,
    signal_flags=G_SIGNAL_RUN_LAST, class_closure=0x56f980,
accumulator=0,
    accu_data=0x0, c_marshaller=0x1, return_type=4, n_params=1,
    param_types=0x569a00) at gsignal.c:1267

All that happens in between is that the varargs are scanned and put into
an array 'param_types'.  All the args look correct with the exception of
the first one.  Actlually looking at all calls to this function it would
appear that gdb cannot understand the arguments at this point.  All
calls to this function have hosed arguments displayed.

Sean