Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] AbstractMIControl Blocking Queue problems

For an update: It was something dumb I did to my own AbstractMIControl. Thanks a bunch to Marc for the debug tips. Doing that, I found it in 5 minutes. Protip: If generating an error window from AbstractMIControl, give that process its own thread.


From: "Alena Laskavaia" <elaskavaia.cdt@xxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: Wednesday, January 23, 2013 6:55:09 PM
Subject: Re: [cdt-dev] AbstractMIControl Blocking Queue problems

This code known to have deadlocks because it does a lot of locking, good thing you can reproduce it because then you can find a deadlock using java debugger as Marc pointed out


On Wed, Jan 23, 2013 at 3:40 PM, Jason Litton <jason@xxxxxxxxxxxxxxx> wrote:
That's a great trick to know. Thanks. I'll get to looking at this deadlock a little more later. Like I said, I thought it was a quick bug I could work while I was waiting for other stuff to happen.


----- Original Message -----
From: "Marc Khouzam" <marc.khouzam@xxxxxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: Wednesday, January 23, 2013 1:26:00 PM
Subject: 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

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top