[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] GDB hangs after a series of commands?
|
Hi,
We ran into the problem in DSF-GDB. Exactly what Steve describes.
We did two things about it:
1- DSF-GDB no longer writes to the console before the console is running.
Of course, we cannot control what other debugger integrators will do.
2- we created a new class, LargePipedInputStream, which increases the buffer
size by a factor of 1024.
The bug is bug 223154: [console] Application writing a lot to the output deadlock.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=223154
Marc
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Steve Goodrich
> Sent: Thursday, April 22, 2010 2:18 PM
> To: 'CDT General developers list.'
> Subject: RE: [cdt-dev] GDB hangs after a series of commands?
>
> And, if I'd had more sleep, I would have seen that this is a
> deadlock. I'll
> try putting my Runnable on a separate thread.
> -- Steve G.
>
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Steve Goodrich
> Sent: Thursday, April 22, 2010 12:09 PM
> To: 'CDT General developers list.'
> Subject: [cdt-dev] GDB hangs after a series of commands?
>
> It is, indeed, a console problem.
>
> BUG: If the console is enabled ("Verbose console mode" checkbox on the
> Debugger tab) and you have a thread which sends around 80 K
> of text to the
> console before the console can be displayed, the system will hang.
>
> Here's what I believe to be happening:
> With console enabled, I have a thread (a BusyIndicator
> Runnable) which is
> activated via a button press (SelectionEvent) in my View. Within this
> thread I send dozens of commands to GDB (e.g. "show print"). During
> execution of this thread the GDB console window (Console
> View) does not
> update, and therefore the GDB output gets queued up in that
> OutputStream.
> At some point during output, the OutputStream reaches a point
> of being full
> and can accept no more data. The RXThread keeps trying to add the GDB
> output to that stream and gets blocked because the stream is
> waiting to be
> emptied. Unfortunately, the stream will not get emptied because [I'm
> guessing here] the Thread managing the Console View is not
> executing and
> therefore is not pulling data out of that OutputStream. Thus, a hang.
>
> With the console disabled, the OutputStream is not gating RXThread and
> therefore there is no hang.
>
> Is this worthy of being filed as a bug?
> -- Steve G.
>
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Mikhail Khodjaiants
> Sent: Tuesday, April 20, 2010 3:07 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] GDB hangs after a series of commands?
>
> It could be a console problem. I remember seeing bug reports
> about large
> output blocking the console.
>
> On 20/04/2010 1:02 PM, James Blackburn wrote:
> > It looks like your're using CDI. One thing that can make it
> hang is if
> > GDB itself is blocked trying to write to one of its output streams
> > (stdout and stderr). Before CDT 7 we never read from stderr, so if
> > there's periodic output here, GDB eventually locks up.
> >
> > It's worth finding out what the other end is doing -- attach another
> > to the gdb eclipse is talking to to find out...
> >
> > Cheers,
> > James
> >
> > On 20 April 2010 17:45, Steve
> Goodrich<steve.goodrich@xxxxxxxxxx> wrote:
> >
> >> I'm working on a custom View in the context of CDI. I have a valid
> >> MISession, and I'm hammering it with commands:
> >>
> >> CLICommand cli = new CLICommand("test");
> >> MIOOBRecord oobRecord[] = null;
> >> for (int i = 0; i< 2000; i++) {
> >> System.out.println(String.format("%4d -
> sending", i));
> >> try {
> >> miSession.postCommand(cli,
> MISession.FOREVER);
> >>
> System.out.println(String.format("%4d - waiting",
> >> i));
> >> oobRecord =
> >> cli.getMIInfo().getMIOutput().getMIOOBRecords();
> >> System.out.println(String.format("%4d -
> completed",
> >> i));
> >> } catch (Exception e) {
> >> System.out.println(String.format("%4d -
> exception:
> >> ", i) + e.getMessage());
> >> }
> >> }
> >> System.out.println("DONE!");
> >>
> >>
> >> I'm able to go through this loop about 900 times, and then my debug
> session
> >> will hang. The last debug output I have is this (the exception is
> expected
> >> since "test" is not a valid GDB command):
> >>
> >> 890 - sending
> >> 890 - waiting
> >> 890 - exception: Undefined command: "test". Try "help".
> >> 891 - sending
> >>
> >>
> >> And now Eclipse is hung. The call stack looks like this:
> >>
> >> Thread [main] (Suspended)
> >> Object.wait(long) line: not available
> [native method]
> >> PipedInputStream.awaitSpace() line: not available
> >> PipedInputStream.receive(byte[], int, int)
> line: not
> >> available
> >> PipedOutputStream.write(byte[], int, int) line: not
> >> available
> >>
> PipedOutputStream(OutputStream).write(byte[]) line: not
> >> available
> >> MISession.writeToConsole(String) line: 831
> >> MISession.postCommand0(Command, long) line: 591
> >> MISession.postCommand(Command, long) line: 573
> >> MyView.testloop(boolean) line: 602
> >> (etc.)
> >>
> >>
> >> I don't have the PipedOutputStream or PipedInputStream
> sources, so the
> >> lowest level at which I have visibility is here:
> >>
> >> protected void writeToConsole(String text) {
> >> OutputStream console = getConsolePipe();
> >> if (console != null) {
> >> try {
> >> console.write(text.getBytes());
> //<<<<<<<<
> >> hangs somewhere in here
> >> console.flush();
> >> }
> >> catch(IOException e) {
> >> }
> >> }
> >> }
> >>
> >>
> >> Does this make sense to anyone? Aside from "don't do that
> to GDB", is
> there
> >> something obvious I'm doing wrong? Is there some pacing I
> need to follow
> >> when dealing with MISession? Is there some way to get
> more information
> on
> >> this so I can figure out what's happening?
> >>
> >> Thanks!
> >> -- Steve G.
> >>
> >>
> >> _______________________________________________
> >> 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
>
>
>
> _______________________________________________
> 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
>