Re: Insight + ARM-9 + BDI2000: Hang on exec

[Toralf Lund <toralf@procaptura.com>]

Keith Seitz wrote:

>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.
>>    
>>
I suddenly discovered what's been going on now - just as I was trying to 
debug the debugger ;-) It was something quite different from what we 
expected, and I should have noticed it earlier, but I just didn't 
consider the possibility, perhaps because it was too simple...

Anyhow, the situation was simply that at the point of the "hang", 
insight would display a modal dialog window of some kind. On connect it 
would contain the message "Successfully connected", on "Run" it asked 
whether I wanted to restart the program, while View->Registers lead to 
an "internal error" popup (I'll investigate that later.)

The problem was that I never could see these popups - not because I'm 
blind or something, but because they would always be opened in the 
"minimized" (iconic) state - so instead of the popup, I just got a 
tasklist entry that I never noticed. (Hmmm... Maybe I should run the 
"window list" applet after all, rather than just using the task pulldown 
of the menu panel. I otherwise find it quite useless when I have more 
than about 3 windows open, and I always do...)

I still haven't figured out why this happened, and if it was insight 
itself or the window manager that caused it, but everything is OK now, 
after I played around a bit with minimize and unminize (or whatever you 
call it) of the popups and the main window.

Sorry for the trouble...

- Toralf

>
>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
>
>  
>


-- 
Toralf Lund <toralf@procaptura.com> +47 66 85 51 22
ProCaptura AS                       +47 66 85 51 00 (switchboard)
http://www.procaptura.com/~toralf   +47 66 85 51 01 (fax)