From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23863 invoked by alias); 11 Jan 2010 14:29:23 -0000 Received: (qmail 23842 invoked by uid 22791); 11 Jan 2010 14:29:22 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from na3sys009aog114.obsmtp.com (HELO na3sys009aog114.obsmtp.com) (74.125.149.211) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jan 2010 14:29:17 +0000 Received: from source ([209.85.219.223]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKS0s1u+gjLKxmSAHCtM961MPMKQDi0YP8@postini.com; Mon, 11 Jan 2010 06:29:17 PST Received: by ewy23 with SMTP id 23so23130ewy.4 for ; Mon, 11 Jan 2010 06:29:14 -0800 (PST) Received: by 10.213.109.75 with SMTP id i11mr3379930ebp.68.1263220153630; Mon, 11 Jan 2010 06:29:13 -0800 (PST) Received: from ?172.17.49.70? ([72.14.240.161]) by mx.google.com with ESMTPS id 7sm10806200eyg.41.2010.01.11.06.29.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 06:29:13 -0800 (PST) Subject: Re: Debugging X with GDB From: Jonathan Morton To: Daniel Jacobowitz Cc: Bernie Innocenti , dclark , xorg-devel@lists.x.org, rms@gnu.org, gdb@sourceware.org In-Reply-To: <20100111140155.GD428@caradoc.them.org> References: <1263170536.29695.86.camel@giskard> <20100111140155.GD428@caradoc.them.org> Content-Type: text/plain Date: Mon, 11 Jan 2010 14:29:00 -0000 Message-Id: <1263219976.15247.81.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00109.txt.bz2 On Mon, 2010-01-11 at 09:01 -0500, Daniel Jacobowitz wrote: > On Sun, Jan 10, 2010 at 07:42:16PM -0500, Bernie Innocenti wrote: > > I think X might change TTY state and piss gdb off > > I'd imagine this is it, but it's impossible to tell without debugging > the TTY state. > > When you hit ^C, that doesn't necessarily cause anything to happen. > The TTY subsystem sees ^C, and may or may not generate a SIGINT to the > foreground process group depending on the tty settings; try checking > using stty -F, for instance. Then the foreground process group is X, > not GDB; if the SIGINT is blocked or ignored, it won't be delivered, > so GDB can't intercept it at delivery. > > Using ^C is not always reliable. A good trick might be to run X+gdb via SSH or a serial console. This is then immune to VT switching semantics. If X screws up sufficiently well to leave the graphics hardware in an unusable state, or traps in gdb while you're watching it and is thus unable to release the hardware to textmode, using SSH or serial console also allows you to continue debugging. -- ------ From: Jonathan Morton jonathan.morton@movial.com