From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 23:31:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 619BE106566B for ; Mon, 4 Apr 2011 23:31:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 37CFA8FC0C for ; Mon, 4 Apr 2011 23:31:54 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p34MvBEf054307 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 4 Apr 2011 15:57:12 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9A4CE5.5090900@freebsd.org> Date: Mon, 04 Apr 2011 15:57:41 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 23:31:55 -0000 currently in kernel stack traces I see: [Switching to Thread 100246] 0xffffffff814617f3 in fio_local_to_global_packet () from xxxxxxxxx/mumble.ko (kgdb) bt #0 0xffffffff814617f3 in yyyy () from xxxxxxxxx/mumble.ko #1 0xffffffff8146171f in zzzz () from xxxxxxxxx/mumble.ko [...] #14 0xffffffff805c4b8e in fork_exit (callout=0xffffffff814dfe30 , arg=0x7d8b48000421dbe8, frame=0x814fc340c6c74800) at ../../../kern/kern_fork.c:859 #15 0xf045c748e87d8948 in ?? () #16 0xb5058b4800000000 in ?? () #17 0x000130054800074e in ?? () #18 0x950fc0850c408b00 in ?? () and then the stack trace goes on forever with garbage. #19 0x74c08548c0b60fc0 in ?? () #20 0x814fdb70c6c74816 in ?? () #21 0x0000b800000007bf in ?? () #22 0x48000425b9e80000 in ?? () #23 0x1210c78148e87d8b in ?? () #24 0x4800000bd1ba0000 in ?? () #25 0x3de8814fc340c6c7 in ?? () #26 0x558b4828eb000421 in ?? () #27 0xc68148e8758b48f0 in ?? () #28 0xe87d8b4800001210 in ?? () #29 0xe800001178c78148 in ?? () #30 0x83fc458900041bdc in ?? () #31 0x7d8b480d7400fc7d in ?? () #32 0xc085fffffdfae8e8 in ?? () #33 0x8148e87d8b48cb74 in ?? () #34 0x0bdcba00001210c7 in ?? () #35 0x4fc340c6c7480000 in ?? () #36 0x8b48000420aae881 in ?? () #37 0x000007600548e845 in ?? () #38 0x00000019bfc68948 in ?? () etc is there anyone here with enough gdb/kgdb source experience to know what we would need to put on the stack at fork_exit() to make it stop when it gets there? not only is it annoying but it slows down debugging because kgdb and the ddd front end ask for stacks a LOT. sometimes it actually just hangs as the stack goes into a loop and never ends. I had a quick look but didn't spot how gdb decides it has reached the end of a stack. Julian