From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12184 invoked by alias); 21 Apr 2004 16:33:20 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 12175 invoked from network); 21 Apr 2004 16:33:18 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 21 Apr 2004 16:33:18 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3LGXHFe025405 for ; Wed, 21 Apr 2004 12:33:17 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3LGXHp31801; Wed, 21 Apr 2004 12:33:17 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i3LGXGK6027054; Wed, 21 Apr 2004 12:33:17 -0400 Subject: Re: Insight + ARM-9 + BDI2000: Hang on exec From: Keith Seitz To: Toralf Lund Cc: "insight@sources.redhat.com" In-Reply-To: <40863904.5020702@procaptura.com> References: <4083CC5E.6060502@procaptura.com> <1082393564.2007.3.camel@lindt.uglyboxes.com> <4084DB79.20105@procaptura.com> <1082477715.2010.32.camel@lindt.uglyboxes.com> <40863904.5020702@procaptura.com> Content-Type: text/plain Message-Id: <1082565232.2004.23.camel@lindt.uglyboxes.com> Mime-Version: 1.0 Date: Wed, 21 Apr 2004 16:33:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-q2/txt/msg00020.txt.bz2 On Wed, 2004-04-21 at 02:04, Toralf Lund wrote: > >So, when you do this, the UI just "hangs"? Control buttons disabled > >(grayed-out)? > > > No. Nothing changes; the UI just stops responding to input. I can't > select icons, open menus, scroll the source view, or even close the window. Ok, this screams of a malignant back-end or similar problem. If the UI doesn't even do screen updates, then I can pretty much guarantee that the back-end code for your target is locking the UI out (blocked in a system call). This happens rather more frequently than I wished. I get reports of this every few months. [However, you're using a standard "remote" target, and this should not happen, so something else must be amiss.] The problem is that gdb has several event loops. Insight further burdens the debugging model by adding yet another one. Let me quickly clarify. The two main event loops in gdb are the target event loop (where the target code is waiting for debug messages from the target) and the UI (or mi or cli) event loop, where the user interface is waiting for input from the user. Unfortunately, gdb and insight don't share the same event loops for these things, and they probably never will until all target event loops go async. In the meantime, we came up with a hack: have the target code periodically call out to the UI to allow it to run it's event loop. This is the evil "ui_loop_hook" that is in gdb. For example, one of the little nasty things that is done (for which I am regrettably responsible many years ago) involves breaking up serial and network read requests into small chunks. Instead of waiting N seconds for a reply from the target, gdb will wait 1 second, N times. After every second, it calls the ui_loop_hook to update the UI (in this case, only insight needs to register a hook callback). So, now for your problems, the question is: why isn't the ui_loop_hook being called? Better yet, why isn't the connect command completing and returning control to gdb-proper? To answer these questions may not be too difficult with a little diligence on your part. So, here are some questions/comments: 1) Let's see if we cannot get gdb/Insight to timeout after the connect and return control to the UI. Before connecting to the target, can you open a console and enter the command "set remote timeout 1". Now try connecting. Does it ever return control to you, i.e., does the UI update at all? 2) I believe you said you were using a remote tcp target, right? Hmm. Looking over src/gdb/ser-tcp.c, I see calls to ui_loop_hook. Well, to check this, we have no choice: you're going to have to load insight into gdb and set a breakpoint on "x_event" in gdbtk-hooks.c. When you attach to the target, does it ever stop at the breakpoint and run the hook? 3) The easy way: Run insight on gdb. Connect to your target (where the hang occurs), and interrupt insight and get a backtrace of where it stopped. Demonstrate anything? Blocked in a system call? 4) The hard way: If all else fails, you're going to have to set a break in remote_open in remote.c and follow it through to the protocol level (for tcp, that's in ser-tcp.c). Does it do the N 1-second timeouts, calling ui loop hook? Or is it blocked? 5) The really hard way: Use strace to find out what's going on. 6) Can you remind me what version of gdb/insight you're using? (Show complete output of "insight -v".) Keith