From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12827 invoked by alias); 19 Mar 2008 20:51:20 -0000 Received: (qmail 12820 invoked by uid 22791); 19 Mar 2008 20:51:19 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Mar 2008 20:50:54 +0000 Received: from kahikatea.snap.net.nz (115.62.255.123.dynamic.snap.net.nz [123.255.62.115]) by viper.snap.net.nz (Postfix) with ESMTP id 41A5E3D844E; Thu, 20 Mar 2008 09:50:52 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id D3FEF8FC6D; Thu, 20 Mar 2008 08:50:49 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18401.31912.560280.609399@kahikatea.snap.net.nz> Date: Wed, 19 Mar 2008 21:03:00 -0000 To: Aleksandar Ristovski Cc: gdb@sourceware.org Subject: Re: -exec-step over a blocking function call In-Reply-To: <47E13AAD.9050504@qnx.com> References: <47E13AAD.9050504@qnx.com> X-Mailer: VM 7.19 under Emacs 22.1.92.2 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: 2008-03/txt/msg00166.txt.bz2 > Where SyncSemWait is a blocking function (as the name suggests, waiting for > semaphore). Gdb will just sit here since the inferior has several threads, > one > of which is reading stdin waiting for user input, and apparently input would > > unblock. But until it does, gdb is sitting here. The problem I am seeing is > that > often, while waiting for SyncSemWait to return IDE would issue additional mi > > commands which eventually make gdb crash or appear frozen (unresponsive). > > I am not sure how should gdb deal with this situation. Any ideas? There is a problem with gdb if it crashes. Although it might not fix your problem, you could attach the gdb in your IDE to another instance of gdb to catch and analyse the crash if/when it happens. -- Nick http://www.inet.net.nz/~nickrob