Date: Fri, 17 Sep 2004 17:16:32 -0700 From: Sean McNeil <sean@mcneil.com> To: freebsd-amd64@freebsd.org Subject: gdb problems with args to functions after a vararg routine Message-ID: <1095466592.48494.11.camel@server.mcneil.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1095466592.48494.11.camel>