| ERR[1]: GdbPicl [message #26568] |
Thu, 25 April 2002 10:19  |
Eclipse User |
|
|
|
Originally posted by: masen.de.ibm.com
Meanwhile I work with Linux WSAD 4.0.3 based on Eclipse 1.0 and the CDT
Rel1
and it works fine.
But if I set a breakpoint and try to debug the demo payroll application
about
Debug->Start a C/C++ Application I get the following messages in the Output
window.
java -cp
/opt/wsappdev/plugins/com.ibm.debug:/opt/wsappdev/plugins/co m.ibm.debug/ibm_debug.jar:/opt/wsappdev/plugins/org.eclipse. cdt.debug.gdbPicl:/opt/wsappdev/plugins/org.eclipse.cdt.debu g.gdbPicl/debug_gdbPicl.jar
GdbPicl (02/04/25)
Copyright ...
GDB Waiting for connection on port 32800.
ERR[1]: GdbPicl: An attempr to connect to the UI Deamon failed. Check the
host name and port.
Command completed (exit code = 255)
Any idea ?
Regards,
Volker
|
|
|
|
|
| Re: ERR[1]: GdbPicl [message #26661 is a reply to message #26568] |
Thu, 25 April 2002 15:43  |
| Eclipse User |
|
|
|
Hi,
I agree with Brian. Users shouldn't need to explicitly start the daemon
when
they try to start a debug session.
To help me diagnose this problem, could you please do the following and
provide me with the trace file created:
1. Extract cpp_minerssrc.zip file from
...plugins/org.eclipse.cdt.cpp.miners.
2. Go into directory,
..plugins/org.eclipse.cdt.cpp.miners/org/eclipse/cdt/cpp/min ers/debug.
3. Inside this directory, there is a file named DebugMiner.properties.
Open the file and append these options to debug_options: -DJT_EVT=1
-DJT_DBG=1 > picltrace.txt 2>&1
4. Restart Eclipse and launch the same debug session.
There should be a trace file created in your project's directory. The
name of the trace file is picltrace.txt.
Please provide me with this trace file.
Also please check the following for me:
1. The invocation line you posted from Output window is truncated. Could
you please try getting the entire line that starts with "java -cp /opt/
...".
I need this to find out what options were passed to the picl when it was
started.
1. When the debug session is started, did you see the daemon being
started in your Debug window? If the daemon is started, you should see
the following lines:
- payroll [Start a C/C++ Application]
-> Debug UI daemon listening on 8001
2. If your daemon is started properly, your machine needs to know what
localhost mean. To check if this is true, try pinging localhost from a
command line window. If you are able to ping, then you are ok with this
setting.
Hope this helps.
Samantha
Volker Masen wrote:
> Meanwhile I work with Linux WSAD 4.0.3 based on Eclipse 1.0 and the CDT
> Rel1
> and it works fine.
> But if I set a breakpoint and try to debug the demo payroll application
> about
> Debug->Start a C/C++ Application I get the following messages in the Output
> window.
> java -cp
>
/opt/wsappdev/plugins/com.ibm.debug:/opt/wsappdev/plugins/co m.ibm.debug/ibm_debug.jar:/opt/wsappdev/plugins/org.eclipse. cdt.debug.gdbPicl:/opt/wsappdev/plugins/org.eclipse.cdt.debu g.gdbPicl/debug_gdbPicl.jar
> GdbPicl (02/04/25)
> Copyright ...
> GDB Waiting for connection on port 32800.
> ERR[1]: GdbPicl: An attempr to connect to the UI Deamon failed. Check the
> host name and port.
> Command completed (exit code = 255)
> Any idea ?
> Regards,
> Volker
|
|
|
| Re: ERR[1]: GdbPicl [message #26902 is a reply to message #26661] |
Fri, 26 April 2002 10:28 |
| Eclipse User |
|
|
|
Originally posted by: masen.de.ibm.com
Samantha,
see my remarks.
Samantha Chan wrote:
> 1. Extract cpp_minerssrc.zip file from
> ...plugins/org.eclipse.cdt.cpp.miners.
> 2. Go into directory,
> ..plugins/org.eclipse.cdt.cpp.miners/org/eclipse/cdt/cpp/min ers/debug.
> 3. Inside this directory, there is a file named DebugMiner.properties.
> Open the file and append these options to debug_options: -DJT_EVT=1
> -DJT_DBG=1 > picltrace.txt 2>&1
> 4. Restart Eclipse and launch the same debug session.
> There should be a trace file created in your project's directory. The
> name of the trace file is picltrace.txt.
> Please provide me with this trace file.
The contents of the picltrace.txt is:
GdbPicl (02/04/26)
Copyright (c) 1995, 2001, 2002 International Business Machines Corporation.
All rights reserved.
This program and the accompanying materials are made available
under the terms of the Common Public License which accompanies
this distribution.
GDB Waiting for connection on port 32848.
ERR[1]: GdbPicl: An attempt to connect to the UI Daemon failed. Check the
host name and port.
> Also please check the following for me:
> 1. The invocation line you posted from Output window is truncated. Could
> you please try getting the entire line that starts with "java -cp /opt/
> ...".
> I need this to find out what options were passed to the picl when it was
> started.
java -cp
/opt/wsappdev/plugins/com.ibm.debug:/opt/wsappdev/plugins/co m.ibm.debug/ibm_debug.jar:/opt/wsappdev/plugins/org.eclipse. cdt.debug.gdbPicl:/opt/wsappdev/plugins/org.eclipse.cdt.debu g.gdbPicl/debug_gdbPicl.jar
-DJT_EVT=1 -DJT_DBG=1 > picltrace.txt 2>&1
> 1. When the debug session is started, did you see the daemon being
> started in your Debug window? If the daemon is started, you should see
> the following lines:
> - payroll [Start a C/C++ Application]
> -> Debug UI daemon listening on 8001
Yes, I see this lines but I'm not able to select the resume button > in
the
Debug View.
> 2. If your daemon is started properly, your machine needs to know what
> localhost mean. To check if this is true, try pinging localhost from a
> command line window. If you are able to ping, then you are ok with this
> setting.
ping localhost shows following information:
PING localhost.localdomain (127.0.0.1) from 127.0.0.1 : 56(84) bytes of
data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=255
time=562
usec
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=255
time=35
usec
Regards,
Volker
|
|
|
| Re: ERR[1]: GdbPicl [message #26942 is a reply to message #26902] |
Fri, 26 April 2002 10:59 |
| Eclipse User |
|
|
|
I know that the com.ibm.debug jar at some point changed it's name from ibm_debug.jar to ibmdebug.jar. This might be the case here. Check inside your com.ibm.debug plugin directory to make sure it's the same
as the one that get's passed into the classpath when launching gdb_Picl.
Dave
Volker Masen wrote:
> Samantha,
> see my remarks.
>
> Samantha Chan wrote:
>
> > 1. Extract cpp_minerssrc.zip file from
> > ...plugins/org.eclipse.cdt.cpp.miners.
> > 2. Go into directory,
> > ..plugins/org.eclipse.cdt.cpp.miners/org/eclipse/cdt/cpp/min ers/debug.
> > 3. Inside this directory, there is a file named DebugMiner.properties.
> > Open the file and append these options to debug_options: -DJT_EVT=1
> > -DJT_DBG=1 > picltrace.txt 2>&1
> > 4. Restart Eclipse and launch the same debug session.
>
> > There should be a trace file created in your project's directory. The
> > name of the trace file is picltrace.txt.
>
> > Please provide me with this trace file.
>
> The contents of the picltrace.txt is:
> GdbPicl (02/04/26)
> Copyright (c) 1995, 2001, 2002 International Business Machines Corporation.
> All rights reserved.
> This program and the accompanying materials are made available
> under the terms of the Common Public License which accompanies
> this distribution.
>
> GDB Waiting for connection on port 32848.
> ERR[1]: GdbPicl: An attempt to connect to the UI Daemon failed. Check the
> host name and port.
>
> > Also please check the following for me:
> > 1. The invocation line you posted from Output window is truncated. Could
> > you please try getting the entire line that starts with "java -cp /opt/
> > ...".
> > I need this to find out what options were passed to the picl when it was
> > started.
> java -cp
> /opt/wsappdev/plugins/com.ibm.debug:/opt/wsappdev/plugins/co m.ibm.debug/ibm_debug.jar:/opt/wsappdev/plugins/org.eclipse. cdt.debug.gdbPicl:/opt/wsappdev/plugins/org.eclipse.cdt.debu g.gdbPicl/debug_gdbPicl.jar
> -DJT_EVT=1 -DJT_DBG=1 > picltrace.txt 2>&1
>
> > 1. When the debug session is started, did you see the daemon being
> > started in your Debug window? If the daemon is started, you should see
> > the following lines:
>
> > - payroll [Start a C/C++ Application]
> > -> Debug UI daemon listening on 8001
> Yes, I see this lines but I'm not able to select the resume button > in
> the
> Debug View.
>
> > 2. If your daemon is started properly, your machine needs to know what
> > localhost mean. To check if this is true, try pinging localhost from a
> > command line window. If you are able to ping, then you are ok with this
> > setting.
> ping localhost shows following information:
> PING localhost.localdomain (127.0.0.1) from 127.0.0.1 : 56(84) bytes of
> data.
> 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=255
> time=562
> usec
> 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=255
> time=35
> usec
>
> Regards,
> Volker
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: ERR[1]: GdbPicl [message #29349 is a reply to message #29157] |
Fri, 03 May 2002 17:27 |
| Eclipse User |
|
|
|
Brian Thomson wrote:
> Robert wrote:
> > Can one see a problem if we were to use -qhost=111.222.333.444
> > where that number is the actual ip address of the computer?
> > It would avoid the problem experienced by Volker, and any DNS
> > unavailability.
> The question then becomes where do you get that number?
The call I was thinking was: InetAddress.getLocalHost().getHostAddress()
instead of the current InetAddress.getLocalHost().getHostName() .
> Not by resolving the hostname on the UI client, that wouldn\'t have
> helped Volker, his hostname couldn\'t be resolved.
You are right, that caused an exception in either case.
A further problem was in gdbPicl, which was causing its own exception
skipping the connection altogether.
> Not by enumerating the machine\'s network addresses either,
> in the case of a machine with multiple IPs (common in servers,
> but also happens in clients using VPN) you won\'t know which one
> to pick. And if there is an address-translating firewall between
> the client and server then the \"correct\" choice won\'t even be in
> that list.
There was one case where an ip address worked while the hostname didn\'t:
on a
remote scenario, where the remote target machine was setup correctly on DNS
while the local machine running the Eclipse UI wasn\'t.
In that case giving the remote the hostname didn\'t help, while if giving
the ip address, it managed to connect back to the UI.
|
|
|
Powered by
FUDForum. Page generated in 0.07010 seconds
Home