-exec-step over a blocking function call

-exec-step over a blocking function call

[Aleksandar Ristovski]

Hello,

I have encountered a problem using MI interface. It is not very easy to 
reproduce, hence no real test case, but I will try to describe what I am
seeing:

This is the situation I have:

(gdb)
-exec-step 1
^running
(gdb)
~"Single stepping until exit from function SyncSemWait, \n"
~"which has no line number information.\n"


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?



Thanks,

Aleksandar Ristovski
QNX Software Systems

Re: -exec-step over a blocking function call

[Vladimir Prus]

Aleksandar Ristovski wrote:

> Hello,
> 
> I have encountered a problem using MI interface. It is not very easy to
> reproduce, hence no real test case, but I will try to describe what I am
> seeing:
> 
> This is the situation I have:
> 
> (gdb)
> -exec-step 1
> ^running
> (gdb)
> ~"Single stepping until exit from function SyncSemWait, \n"
> ~"which has no line number information.\n"
> 
> 
> 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).

So which is that -- crash or appear frozen?

In the majority of cases, GDB does not read or processes further 
MI commands while waiting for the target to stop 
(which it does in your case). And even if it accepts commands, 
there's just one allowed command -exec-interrupt.
If the IDE attempts to any other command, the IDE has a bug.

> 
> I am not sure how should gdb deal with this situation. Any ideas?

Please check the spec of MI changes for async targets that I've posted
yesterday. It would be great if the IDE developers also glance and make
omments before I implement it all.

- Volodya

Re: -exec-step over a blocking function call

[Nick Roberts]

 > 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