[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] AbstractMIControl Blocking Queue problems
|
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
> Sent: Wednesday, January 23, 2013 2:43 PM
> To: 'CDT General developers list.'
> Subject: Re: [cdt-dev] AbstractMIControl Blocking Queue problems
>
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Jason Litton
> > Sent: Wednesday, January 23, 2013 2:36 PM
> > To: CDT General developers list.
> > Subject: [cdt-dev] AbstractMIControl Blocking Queue problems
> >
> > Hi all,
> > I'm chasing a bug I thought would be simple but really turned
> > out not to be. When I start a sourceless debug session (cdt
> > 8.0 on Indigo, I know, I know) and then try to type an
> > address (000ffe2b, say) Eclipse freezes. I've watched the
> > -data-evaluate-expression go out and saw the return from GDB,
> > but it's in the rx/tx queues that it's hanging. Specifically,
> > in the TxThread inner class in AbstractMIControl, it hangs on
> > the fTxCommands.take() command. It looks like someone is
> > maintaining the handle to the TX queue and never releasing. I
> > have two questions from this:
> > 1) Is this a problem that has been solved? If so, would you
> > mind pointing me to the bug number?
>
> I'm not sure. I would diff the most recent version with the
> one you are using to see if anything looks different with
> respect to that. You can easily diff by showing the file
> history with Egit (right-click on file team->show in history)
>
> > 2) How can I see who has the handle on the fTxCommands queue?
>
> For dead-locks, look in your development eclipse in the Debug
> View and interrupt the UI thread (called Main), the DSF
> executor (called org.eclipse.cdt.dsf.gdb), the "MI TX Thread"
> and the "MI RX Thread", and then look at who's waiting for
> what. Hopefully you'll see the reason for the lock.
Oh, and you can display the Monitors that are held by an
interrupted thread by going to the Debug view menu and
selecting Java->Show Monitors
