Community
Participate
Working Groups
Hello open source world, I am using the Latest Eclipse build (Build Id:-200406301200) with compatible CDT plugins on Linux platform. When I try debugging a C or C++ project, I am getting the following error. "Launching (Error: Target request failed: Target is not responding(timed out).) However, there was no such problem with the earlier releases. I have the latest version of debugger. May I know what causes this problem. Please help me to make it work. Thanks in advance, Ragav.
PR was not targeted to any particular release. Changing target milestone to 2.1
Created attachment 13046 [details] log file Have attached the log file for more details.
Created attachment 13050 [details] log file Have attached the log file for more details.
Please check your path to make sure you have a version of gdb that is 5.2.1 or later versions. You can verify by typing: # gdb -i mi1 In the CDT FAQ web pages it describes a way to get the output of gdb via trace logging, I would like to see this. So far, I do not have enough information on what is a problem to be of good help. Thanks
I've look at the the trace and it seems to work ok. However, you seem to have the disassembly view on. Turn this off for the test, i.e. do not use the disassembly view. that will help us isolate the problem. Do the normal next/next. what is of surpise to me is this: [1,089,778,307,755] 30-exec-continue [1,089,778,307,770] I AM FOO I AM BAR (gdb)=20 [1,089,778,307,771] 30^running [1,089,778,307,771] (gdb)=20 [1,089,778,307,771] 30*stopped [1,089,778,307,774] 31 info threads [1,089,778,307,774] (gdb)=20 [1,089,778,307,775] &"info threads\n" [1,089,778,307,775] &"No stack.\n" [1,089,778,307,776] 31^error,msg=3D"No stack." [1,089,778,307,776] 32 info threads [1,089,778,307,777] (gdb)=20 After the print out, the program stop for unknown reason, just "*stopped" for unknown reasons or it reach the end. With the disassembly off is it working better ?
Vlad/Mathieu Do you have an HP machine to quickly run hello_world type of program on the debugger ? We do not have any HP machine here, so debugging this is extremmely painfull. If an hello_world type of program does not work, could you send me the MI log trace ... Note: you need gdb-5.2.1 or newer on HP Thanks
Created attachment 13546 [details] HP-UX SOM Binary parser patch HP-UX SOM Binary parser patch
I was not able to make Debugging work in CDT 2.0 GA on HP-UX because there is only one Debugger available in the C/C++ Local configuration and that is GDB Server. When I was trying to debug the HelloWorld application with this debugger I was getting errors (same as Ragav, and some similar ones). Then I applied a quick fix to the new HP-UX SOM binary parser and got GDB Debugger as well, which worked just fine. Attached are the patch and the GDB trace output of successful debugging session. The patch is applicable to both HEAD and the branch.
Created attachment 13547 [details] GDB session output
I have narrowed down the problem to MIPlugin.java Line No:166 (see the attached file). In this code, there are two blocks one if pty == null and other for pty ! =null. If pty !=null, then tty and pty.getSlaveName() is sent as parameters and libpty.so comes into action. If pty = null , then tty and pty.getSlaveName() is not available as parameters and libpty.so does not come into action. When I encountered this "Target not responding" exception, I drilled down that this happens because of the two arguments tty and pty.getSlaveName() and then commented them out from the code. The debugger worked perflectly fine. Now I got confused , if the debugger works perfectly fine without these tty options then why should we have this code. I am sure I am missing something. Can you set me the right context? I perfectly understand that by setting the "tty", we redirect our gdb output to Eclipse console rather than the pseudo terminal or standart input/output. Well this problem occurs even in Eclipse 3.0 + CDT 2.0.
Created attachment 13556 [details] Attachment for comment 10
> if the debugger works perfectly fine without these tty options > then why should we have this code. I am sure I am missing something. Can you > set me the right context? As you pointed out, the PTY support is to redirect the output to the console(Eclipse) and also some applications __need__ a TTY stream to work/behave etc ... Some platforms do not have PTY(See org.eclipse.cdt.core.win32) and do not provide a libpty.so. It looks like the pty handling is not working for HP. We could fix the code or remove the pty.so completely. Doug/vlad what do you think ? Unfortunately we do not have HP machines here to commit to fix this code, somebody else will have to step in.
> Attached are the patch and the GDB trace output of successful debugging > session. The patch is applicable to both HEAD and the branch. Thanks Vlad, another PR was created to track this down: https://bugs.eclipse.org/bugs/show_bug.cgi?id=70820
Is there any progress done with this PR. Ragav, was saying that the PTY handling code is buggy, We don't have HP here, so it will be up the folks having HP boxes to provide a fix for this .
I'm pretty sure HP has a lot of HP machines around :-). Guys, please feel free to send in patches to make the CDT work better on your platforms. We'll be happy to review them and apply them as necessary.
Just for the record, there is no HP version of libpty.so because there is no org.eclipse.cdt.core.hpux fragment. Therefore pty is always equal to null so tty and pty.getSlaveName() never make it to the argument list. I am not quite clear why it was necessary to remove them from the code. Still I was able to debug an application (even without HP-UX binary parser) using GDB Debugger (not Server) launch configuration.
> Just for the record, there is no HP version of libpty.so because there is no > org.eclipse.cdt.core.hpux fragment. Therefore pty is always equal to null so > tty and pty.getSlaveName() never make it to the argument list. I am not quite > clear why it was necessary to remove them from the code. Agreed. > Still I was able to debug an application (even without HP-UX binary parser) > using GDB Debugger (not Server) launch configuration. Allright cool! Thanks vlad.
No feedback for the reporter, unblocking and moving to future
No one is currently looking at HP/UX support.
(this is part of a batch change) The CDI debug implementation has been removed in CDT 9.0. Please see bug 484900 and the entry on the New and Noteworthy page https://wiki.eclipse.org/CDT/User/NewIn90#API_modifications
