From owner-freebsd-amd64@FreeBSD.ORG Sat Sep 18 00:16:34 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AADF16A4CE for ; Sat, 18 Sep 2004 00:16:34 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BB7943D1F for ; Sat, 18 Sep 2004 00:16:34 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 023D5F1A06 for ; Fri, 17 Sep 2004 17:16:34 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18363-06 for ; Fri, 17 Sep 2004 17:16:33 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 02987F1A02 for ; Fri, 17 Sep 2004 17:16:32 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org Content-Type: text/plain Message-Id: <1095466592.48494.11.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 17:16:32 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: gdb problems with args to functions after a vararg routine X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 00:16:34 -0000 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