From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13119 invoked by alias); 24 Jul 2012 19:06:37 -0000 Received: (qmail 13110 invoked by uid 22791); 24 Jul 2012 19:06:36 -0000 X-SWARE-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from imr3.ericy.com (HELO imr3.ericy.com) (198.24.6.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jul 2012 19:06:22 +0000 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q6OJ5b29012297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jul 2012 14:06:13 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 24 Jul 2012 15:05:51 -0400 From: Marc Khouzam To: "'Abid, Hafiz'" CC: "'gdb-patches@sourceware.org'" , "'Eli Zaretskii'" Date: Tue, 24 Jul 2012 19:06:00 -0000 Subject: RE: [patch] MI telnet service Message-ID: References: <837gu9az0t.fsf@gnu.org>, In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00498.txt.bz2 > > Here are some issues I found: > >=20 > > - If I set a tty (-inferior-tty-set), GDB exits (or crashes?) when > > sending an > > empty command (just pressing enter) over telnet. Eclipse uses a tty > > for the > > inferiors. > Can you kindly list the steps to reproduce this crash. I=20 > tried but it worked ok for me. It happens all the time with Eclipse. I thought I had also reproduced it on the command line but today I just can get it to happen anymore directly in GDB. But I also can't stop it from=20 happening in Eclipse :) I reproduced the _exact_ same MI session outside of eclipse as the one that crashes, and it still doesn't happen. I'll have to figure out what is different. You could try it with Eclipse and see if it happens to you also. Just launch a debug session and start the telnet service from the eclipse gdb console, then telnet in and press enter. While trying to reproduce this, I ran into another problem that I could reproduce outside of Eclispe. In async-mode, gdb seems to go into a tight-loop when resuming execution from the telnet session (excerpts of the session below): > ./gdb/gdb -i mi ~"GNU gdb (GDB) 7.5.50.20120724-cvs\n" (gdb) -gdb-set target-async on ^done (gdb) start &"start\n" ~"Temporary breakpoint 1 at 0x804850d: file loopfirst.cc, line 5.\n" [...] *stopped,reason=3D"breakpoint-hit",disp=3D"del",bkptno=3D"1",frame=3D{addr= =3D"0x0804850d",func=3D"main",args=3D[],file=3D"loopfirst.cc",fullname=3D"/= home/lmckhou/testing/loopfirst.cc",line=3D"5"},thread-id=3D"1",stopped-thre= ads=3D"all",core=3D"0" =3Dbreakpoint-deleted,id=3D"1" (gdb) -start-telnet-service 9999 ^done =3D> start a telnet session from another terminal and give the 'next' comma= nd =3D> from the telnet session. Switching to interpreter "console". (gdb) ^running *running,thread-id=3D"all" =3D> gdb grabs 100% of the CPU and must be killed with -9 > > - For every command sent over telnet, there is a printout=20 > in the orinal > > GDB > > saying "Switching to interpreter "console"." Not a big=20 > deal, but maybe > > something to remove. > >=20 > > - starting the telnet service, connecting to it, and then=20 > stopping the > > service (-stop-telnet-service), does no seem to clean up the port > > propertly > > and I see: > > ^error,msg=3D"Error: port 9996 can't be bind" > >=20 > > - If I start GDB in CLI mode, and try to use the telnet service, GDB > > segfaults > > after the first command is sent over telnet. I know this service is > > not > > currently meant to be used with the CLI mode, but it should=20 > not crash > > :) > > I personally think this would be cool to have even for CLI=20 > mode, but if > > it > > won't be for now, maybe the telnet service should be=20 > disabled in that > > case. > >=20 > > I realize this is a first and important step, but it will=20 > be even nicer > > when the telnet service supports tab-completion and command-history. > >=20 > > This is very exciting! Thanks! > >=20 > > Marc > Thanks for taking time to test. >=20 > Regards, > Abid >=20