From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14337 invoked by alias); 13 Nov 2007 22:36:28 -0000 Received: (qmail 14251 invoked by uid 22791); 13 Nov 2007 22:36:27 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 Nov 2007 22:36:25 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Is4LW-0001By-M1 for gdb@sources.redhat.com; Tue, 13 Nov 2007 22:35:02 +0000 Received: from i577bf06d.versanet.de ([87.123.240.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Nov 2007 22:35:02 +0000 Received: from Stephen.Berman by i577bf06d.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Nov 2007 22:35:02 +0000 To: gdb@sources.redhat.com From: Stephen Berman Subject: Re: GDB cannot access memory after Emacs abort Date: Tue, 13 Nov 2007 22:36:00 -0000 Message-ID: <87d4uddbjw.fsf@escher.local.home> References: <87r6j6rvn3.fsf@escher.local.home> <87hcjtllau.fsf@escher.local.home> <1194763094.16917.278.camel@localhost.localdomain> <20071111192237.GA11728@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-IsSubscribed: yes 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: 2007-11/txt/msg00111.txt.bz2 On Mon, 12 Nov 2007 10:38:36 +0300 Vladimir Prus wrote: > Daniel Jacobowitz wrote: > >> On Sat, Nov 10, 2007 at 10:38:14PM -0800, Michael Snyder wrote: >>> >>> Making sure that I understand -- you ran emacs under gdb, >>> you set a breakpoint at abort, you hit the breakpoint -- >>> and your desktop is locked up? >>> >>> That seems unusual -- do you have any idea of the cause? >> >> This is pretty common when debugging X programs, IIRC. I believe >> there's some ways in which an application can "own" a display while >> something is in progress. > > I believe it's XGrabPointer, which causes all mouse and/or keyboard > event to be delivered to specific application. If that application is > stopped by gdb, it means, in effect, that events are not processed at all. > > I have no idea if that's the cause, since the emacs diff posted in another > email does not have any apparent locking thing, but it very likely. But as I pointed out in my followup to Jim Blandy, the lockup only happens when emacs aborts while running under gdb; starting emacs directly from the shell and inducing the abort does not lock up the desktop. Steve Berman