From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [Tux3] Tux3 report: A Golden Copy Date: Wed, 31 Dec 2008 19:31:23 +1100 Message-ID: <20081231083123.GF10725@disturbed> References: <200812301935.49303.phillips@phunq.net> <9bd6b5360812302334t2c6aca67s62ba54438d2bda9e@mail.gmail.com> <200812310000.55256.phillips@phunq.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tux3@tux3.org, sniper , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Daniel Phillips Return-path: Received: from ipmail05.adl2.internode.on.net ([203.16.214.145]:33952 "EHLO ipmail05.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752096AbYLaIb3 (ORCPT ); Wed, 31 Dec 2008 03:31:29 -0500 Content-Disposition: inline In-Reply-To: <200812310000.55256.phillips@phunq.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Dec 31, 2008 at 12:00:54AM -0800, Daniel Phillips wrote: > On Tuesday 30 December 2008 23:34, sniper wrote: > > Great, I have mounted tux3 filesystem under UML with stuffs in this mail, > > but I still can't debug it with gdb. Anyone gives me suggestion? .... > In the mean time, you could just tell gdb to mask off all segfaults, > but would be kind of problematic for debugging. Not really. That's the default setting I use for XFS debugging. I just put breakpoints on "panic" and "stop" (sometimes bust_spinlocks) and just let the kernel panic routine handle the segv which will trip a breakpoint. Then just walk back up the stack to the function that triggered the real SEGV and go from there. This is pretty much necessary for XFS debugging because just mounting a filesystem causes 8-10 SEGV signals to occur. You simply can't run xfsqa when that is occurring... Cheers, Dave. -- Dave Chinner david@fromorbit.com