Debugging problems in 6.2.1a

bridged with qdn.public.devtools
Jack Rosenbloom

Re: Debugging problems in 6.2.1a

Post by Jack Rosenbloom » Thu Aug 14, 2003 4:37 pm

Hi Alex,

I gave up on 6.2.1b over a month ago so I don't remember the exact
error. When I enter the debug perspective, my program is successfully
transferred from my win2k development system to the QNX system. Then I
get an error in eclipse that the temp directory doesn't exist and so no
debugging session is created. I noticed there are some new
configuration options in 6.2.1B for this so I tried every possible
option. I also provided read/write access to all direectories on the
QNX system, but nothing help. I duplicated the same problem on another
development environment.

I also made a list of problems which I sent to my saleperson who said he
was forwarding it to the manager of tools development. Below is a copy
of the problems I am living with with 6.2.1A.

Alex, thanks for the response!
Jack


BUGS
1) Attempting to suspend a thread which is not thread #1 yields this error:

Suspend Failed
Reason:
Exceptions occurred attempting to suspend

org.eclipse.cdt.debug.mi.core.cdi.MI2CDIExection: Target running

2) "Run to C/C++" menu command doesn't work if the selected source line
is not in the file at which execution is currently suspended

3) detail pane in the variables window doesn't work at all.

4) there is no way to view static variables.

5) Communication between the windows based debugger and the QNX target
is very un-reliable. "Can't get stack frame" errors are common,
expecially if there is more than one thread or process being debugged.
After this error, I need to log onto the QNX6 system and slay my
applications which the debugger left running before I can start a new
session. The processes left running can't be successfully slayed from
the QNX system info perspective. If my application tasks have a
priority greater than 10, I can no longer access the QNX system so I
re-boot QNX. I also need to exit and re-invoke eclipse to recover after
this occurs to debug anything.

6) After editting and saving a header file, the build menu doesn't
always compile the dependent Cpp files.

7) With 3 threads in a process, the debugger gets very confused which
thread is which and usually displays the wrong thread after a
breakpoint. If thread 2 breaks, thread 3 might be displayed even though
it didn't hit a breakpoint.

NUISANCES
1) when debugging 2 processes, setting a breakpoint in one process
suspends the other running processes. In a process with multiple
threads, suspending one thread suspends all threads. Debugging anything
other than a single thread in a single process is very difficult.

3) terminate takes too long

4) If you have a pointer to an array, there is no way in the debugger to
symbolically view the contents of the array pointed to..

5) The project window needs to allow nesting of projects and shouldn't
require all projects to be in the same directory path.

--


Alex Chapiro wrote:
Could you please provide more details about your problem?

"Jack Rosenbloom" <jrosenbloom@vertisinc.com> wrote in message
news:3F3B7A8E.4070103@vertisinc.com...

for all this talk about patch B solving problems, I have been unable to
debug any program with it. Constant errors opening temp directory.
This occurs on 2 different win2K development systems and two different
qnx targets. I find the bugs in 6.2.1a easier to deal with so I rolled
back and reported the mess to QNX waiting for them to get their act
together.

I have been an QNX4 user for a long time. Am I the only one who feels
that QNX has lost their ability to create quality SW?

Jack

Bill Caroselli wrote:

Is this patch B available to an evaluation copy of PE?
I have to admit, for the amount of extra cost of PE over SE,
so far I am NOT impressed!

David Gibbs

Re: Debugging problems in 6.2.1a

Post by David Gibbs » Thu Aug 14, 2003 5:35 pm

Jack Rosenbloom <jrosenbloom@vertisinc.com> wrote:
for all this talk about patch B solving problems, I have been unable to
debug any program with it. Constant errors opening temp directory.
This occurs on 2 different win2K development systems and two different
qnx targets. I find the bugs in 6.2.1a easier to deal with so I rolled
back and reported the mess to QNX waiting for them to get their act
together.
In the launch config, turn-off the option to strip the executable
when uploading -- something building the pathname of the stripped
executable is doing it wrong. Its on the "upload" tab.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Jack Rosenbloom

Re: Debugging problems in 6.2.1a

Post by Jack Rosenbloom » Thu Aug 14, 2003 7:11 pm

Thanks for the response. I have 2 questions.

1) I don't see an upload tab in version 6.2.1a. Should I, or is it only
in 6.2.1B?

2) How sure are you that this solution will work. Switching between the
A and B versions and back again is hours of work? By the way, what is a
stripped executable?

Jack


David Gibbs wrote:
Jack Rosenbloom <jrosenbloom@vertisinc.com> wrote:

for all this talk about patch B solving problems, I have been unable to
debug any program with it. Constant errors opening temp directory.
This occurs on 2 different win2K development systems and two different
qnx targets. I find the bugs in 6.2.1a easier to deal with so I rolled
back and reported the mess to QNX waiting for them to get their act
together.


In the launch config, turn-off the option to strip the executable
when uploading -- something building the pathname of the stripped
executable is doing it wrong. Its on the "upload" tab.

-David

David Gibbs

Re: Debugging problems in 6.2.1a

Post by David Gibbs » Fri Aug 15, 2003 4:36 pm

Jack Rosenbloom <jrosenbloom@vertisinc.com> wrote:
Thanks for the response. I have 2 questions.

1) I don't see an upload tab in version 6.2.1a. Should I, or is it only
in 6.2.1B?
No, I don't think that tab existed in 6.2.1A. Part of the changes in
B was in the launch mechanism.
2) How sure are you that this solution will work. Switching between the
A and B versions and back again is hours of work? By the way, what is a
stripped executable?
When you build a debug executable, it includes lots of debug information
in the program as it resides on disk. This information is only needed
by the debugger on the host side, and is not needed to execute the program
on the target. And, it can more than double the size of the executable.
For small programs, not much of an issue...but if you're program is 1M,
then ending up with 3M because of debug... is an issue. The "strip"
strips out (removes) the debug information from the executable, and
only uploads the stuff actually needed to run the executable.

As to how sure am I this will work? Do you get an error dialog
saying that is is unable to open some (strange) pathname, with
a C: part way through the path? If that was your error, this
fixed it for me.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Jack Rosenbloom

Re: Debugging problems in 6.2.1a

Post by Jack Rosenbloom » Fri Aug 15, 2003 5:36 pm

The error I get complains about a path in the QNX system and doesn't
contain any microsoft drive references. If I remember correctly, the
default path was /tmp. When that didn't work, I unchecked the default
box and tried /home/jack which also didn't work.

The reason for my question about how sure you were about the fix is that
once I switch to 6.2.1b, I can no longer do any development until this
problem is resolved. From your description, it doesn't sound like the
striped executables are the problem.

The middle of next week, I will be leaving for vacation. I think I will
upgrade my system to 6.2.1B and try to get some one else to followup
with the hope of solving this before I get back. Otherwise once I'm
back from vacation, I'll spend my 1st few hours rolling back to 6.2.1A
AGAIN.

Jack


It's hard to believe that my two development stations here are the only
one's with this problem. I don't know how to proceed past this. Given
all the problems with 6.2.1A, staying with it is certain not reasonable.


David Gibbs wrote:
Jack Rosenbloom <jrosenbloom@vertisinc.com> wrote:

Thanks for the response. I have 2 questions.


1) I don't see an upload tab in version 6.2.1a. Should I, or is it only
in 6.2.1B?


No, I don't think that tab existed in 6.2.1A. Part of the changes in
B was in the launch mechanism.


2) How sure are you that this solution will work. Switching between the
A and B versions and back again is hours of work? By the way, what is a
stripped executable?


When you build a debug executable, it includes lots of debug information
in the program as it resides on disk. This information is only needed
by the debugger on the host side, and is not needed to execute the program
on the target. And, it can more than double the size of the executable.
For small programs, not much of an issue...but if you're program is 1M,
then ending up with 3M because of debug... is an issue. The "strip"
strips out (removes) the debug information from the executable, and
only uploads the stuff actually needed to run the executable.

As to how sure am I this will work? Do you get an error dialog
saying that is is unable to open some (strange) pathname, with
a C: part way through the path? If that was your error, this
fixed it for me.

-David

Jack Rosenbloom

Re: Debugging problems in 6.2.1a

Post by Jack Rosenbloom » Fri Aug 15, 2003 6:03 pm

Hi David,

I just re-installed 6.2.1B. The exact ewrror I get is

Can't launch file for Appl:target launcher@<localhost:8000>: error
invalid argument setting working dir /tmp/qconnCAAb63864/

Jack


David Gibbs wrote:
Jack Rosenbloom <jrosenbloom@vertisinc.com> wrote:

Thanks for the response. I have 2 questions.


1) I don't see an upload tab in version 6.2.1a. Should I, or is it only
in 6.2.1B?


No, I don't think that tab existed in 6.2.1A. Part of the changes in
B was in the launch mechanism.


2) How sure are you that this solution will work. Switching between the
A and B versions and back again is hours of work? By the way, what is a
stripped executable?


When you build a debug executable, it includes lots of debug information
in the program as it resides on disk. This information is only needed
by the debugger on the host side, and is not needed to execute the program
on the target. And, it can more than double the size of the executable.
For small programs, not much of an issue...but if you're program is 1M,
then ending up with 3M because of debug... is an issue. The "strip"
strips out (removes) the debug information from the executable, and
only uploads the stuff actually needed to run the executable.

As to how sure am I this will work? Do you get an error dialog
saying that is is unable to open some (strange) pathname, with
a C: part way through the path? If that was your error, this
fixed it for me.

-David

David Gibbs

Re: Debugging problems in 6.2.1a

Post by David Gibbs » Fri Aug 15, 2003 7:15 pm

Jack Rosenbloom <jrosenbloom@vertisinc.com> wrote:
Hi David,

I just re-installed 6.2.1B. The exact ewrror I get is

Can't launch file for Appl:target launcher@<localhost:8000>: error
invalid argument setting working dir /tmp/qconnCAAb63864/
That's a new one on me.

Is this a launch that was configured under 6.2.1A? Or have you created
a brand-new launch configuration?

The /tmp/qconn* directory is a temporary directory used for uploads, but
I don't think that 6.2.1B uses that anymore -- it seems to either upload
everything to /tmp. Now, if you had an old launch config trying to use
that (temporary) directory, and it no longer exists...

Hm...tested it by setting the upload dir to something non-existent, that
didn't fail properly (different error).

Hm...also tried explicitly setting the working dir to /tmp/xxxx, which
didn't exist, and got a different error for that too.

So, I don't know. (And, since most of the company isn't around today,
I can't help you much further. Oh, as to why we're not around today...
www.cnn.com should answer that one. :)

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Jack Rosenbloom

Re: Debugging problems in 6.2.1a

Post by Jack Rosenbloom » Fri Aug 15, 2003 7:45 pm

Thanks for trying. Before your candle burns out, here's some additional
info.

I re-tried this a number of times. The first 4 or so times yielded the
same error message except for variations in the suffix to
/tmp/qconn????????. The balance of the tries resulted in a path of /tmp
in the error message.

THis config was create under 6.2.1a. I created a new config under
6.2.1B with the same result ( directory in error message was /tmp).

Thanks for the help!
Jack


David Gibbs wrote:
Jack Rosenbloom <jrosenbloom@vertisinc.com> wrote:

Hi David,


I just re-installed 6.2.1B. The exact ewrror I get is


Can't launch file for Appl:target launcher@<localhost:8000>: error
invalid argument setting working dir /tmp/qconnCAAb63864/


That's a new one on me.

Is this a launch that was configured under 6.2.1A? Or have you created
a brand-new launch configuration?

The /tmp/qconn* directory is a temporary directory used for uploads, but
I don't think that 6.2.1B uses that anymore -- it seems to either upload
everything to /tmp. Now, if you had an old launch config trying to use
that (temporary) directory, and it no longer exists...

Hm...tested it by setting the upload dir to something non-existent, that
didn't fail properly (different error).

Hm...also tried explicitly setting the working dir to /tmp/xxxx, which
didn't exist, and got a different error for that too.

So, I don't know. (And, since most of the company isn't around today,
I can't help you much further. Oh, as to why we're not around today...
www.cnn.com should answer that one. :)

-David

Rüdiger Loos

Re: Debugging problems in 6.2.1a

Post by Rüdiger Loos » Mon Aug 18, 2003 10:57 am

Hallo Mikhail,

the core of my problem is that I use 6.2.1B on my host and 6.2.0 on my
target.
First I have to update my target now, then I'll tell you whwther my problem
still exists.

kind regards
Rüdiger

"Mikhail Khodjaiants" <mikhailk@qnx.com> schrieb im Newsbeitrag
news:bhg86b$pnj$1@nntp.qnx.com...
Could you please try the following:
Add the following command line entries (which must be before the -vmargs
options):

-debug <optionsfilename

where <optionsfilesname> is the URL to the options file (i.e.
file:///temp/myfile) and <optionsfilename> would contain:

org.eclipse.cdt.debug.mi.core/debug=true

i.e.

C:\QNXsdk\host\win32\x86\usr\qde\eclipse\qde.exe -feature

com.qnx.tools.ide -debug "file:///temp/myfile.debug -vmargs

-Xms128m -Xmx256m

and the c:/temp/myfile.debug file would contain:

org.eclipse.cdt.debug.mi.core/debug=true

This will trace the raw commands from a session with the debugger to the
console.

Send me this output.

Thanks,

Mikhail

"Rüdiger Loos" <Ruediger.Loos@3SOFT.de> wrote in message
news:bhg21e$rqi$1@inn.qnx.com...
That was exactly my idea too. I increased timeout up to 30000ms. But, no
way.
By the way, the log I sent is the log-file of a test with 30000ms.

"Alex Chapiro" <achapiro@qnx.com> schrieb im Newsbeitrag
news:bhfsvc$o45$1@inn.qnx.com...
Could you please try to increase debugger timeout (see
Window/Preferences/C\C++/Debug/GDB MI) ?

"Rüdiger Loos" <Ruediger.Loos@3SOFT.de> wrote in message
news:bhfs3u$ngt$1@inn.qnx.com...
Now I got PatchB and I've installed it immediately.
But, no way again :-((
now I get the following timeout message while trying to attatch to
debugger:
-----------------------------
java.version=1.3.1_04
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Command-line arguments: -os win32 -ws win32 -arch x86 -feature
com.qnx.tools.ide -install
file:C:/QNXsdk/host/win32/x86/usr/qde/eclipse/
!ENTRY org.eclipse.jdt.launching 4 4 Aug 14, 2003 13:24:34.841
!MESSAGE VM type element with unknown id
!ENTRY org.eclipse.debug.ui 4 120 Aug 14, 2003 13:38:23.186
!MESSAGE Error logged from Debug UI:
!STACK 1
org.eclipse.core.runtime.CoreException[150]:
org.eclipse.cdt.debug.core.cdi.CDIException: Error initializing:
Timedout
at




com.qnx.tools.ide.qde.debug.internal.core.CGDBDebugger.createAttachSession(C
GDBDebugger.java:136)
at




com.qnx.tools.ide.qde.internal.ui.launch.LaunchConfigurationDelegate.startDe
bugger(LaunchConfigurationDelegate.java:422)
at




com.qnx.tools.ide.qde.internal.ui.launch.LaunchConfigurationDelegate.launch(
LaunchConfigurationDelegate.java:316)
at




org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfigurati
on.java:136)
at




org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationDialog
$10.run(LaunchConfigurationDialog.java:2299)
at




org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext
.java:98)
!ENTRY org.eclipse.cdt.launch 4 150 Aug 14, 2003 13:38:23.186
!MESSAGE CDI Error: Error initializing: Timedout
!STACK 0
org.eclipse.cdt.debug.core.cdi.CDIException: Error initializing:
Timedout
at




com.qnx.tools.ide.qde.debug.internal.core.CGDBDebugger.createAttachSession(C
GDBDebugger.java:136)
at




com.qnx.tools.ide.qde.internal.ui.launch.LaunchConfigurationDelegate.startDe
bugger(LaunchConfigurationDelegate.java:422)
at




com.qnx.tools.ide.qde.internal.ui.launch.LaunchConfigurationDelegate.launch(
LaunchConfigurationDelegate.java:316)
at




org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfigurati
on.java:136)
at




org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationDialog
$10.run(LaunchConfigurationDialog.java:2299)
at




org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext
.java:98)

-----------------------------
I can try to debug the app on my host or on the target, same result.
Do you have any idea? Perhaps I have to update same programs on my
target?

regards
Rüdiger


"Rüdiger Loos" <Ruediger.Loos@3SOFT.de> schrieb im Newsbeitrag
news:bhdcp2$stl$1@inn.qnx.com...
I've been trying to get patchB for at least two weeks over myQNX
but
I
didn't succeed :-(
QNX support promised me now that they'll send me the patch til
Friday
10
o'
clock.

Thank you for your support til now Alex. When I have the patch
installed
and
run my program I'll tell you whether I was successful or not.

Thanks a lot
Rüdiger

"Alex Chapiro" <achapiro@qnx.com> schrieb im Newsbeitrag
news:bhd8o3$po6$1@inn.qnx.com...
I'm sorry, but the version you tested was barely later than
early
release
of
Patch A candidate (tagget 11/03/03). I can see it from the
supplemented
trace log. It doesn't make sence to play with it. Could you
please
do
the
same using Patch B installation?

Alex

"Rüdiger Loos" <Ruediger.Loos@3SOFT.de> wrote in message
news:bhd4tk$n9m$1@inn.qnx.com...
Ok, now I performed the following steps:
1. I deleted all debug targets
2. I closed the IDE
3. I removed my .log file
4. I started the IDE
5. I tried to debug my app as a "local application

the result was the error message box in locApp.bmp and the log
file
locApp.log

The I performed the following steps:
1. I removed my .log file
2. I started the IDE
5. I created a new "launch configuration" QNX QConn (IP); the
only
change
I
did was to specify my target
6. I pressed the debug button

the result was the error message box in qconnApp.bmp and the
log
file
qconnApp.log

The problem is the second "tabletest_mb" directory.
The real path is "E:\Pro\MED_ETX1\code\tabletest_mb\x86\o-g"
and NOT
"E:\Pro\MED_ETX1\code\tabletest_mb\tabletest_mb\x86\o-g"
but who made a mistake and how can I correct the mistake?


"Alex Chapiro" <achapiro@qnx.com> schrieb im Newsbeitrag
news:bhb66r$ajt$1@inn.qnx.com...
I don't think it is a good idea. This is the first case we
run
into
this
problem.
Unfortunately the log you send me does not correspond the
described
problem.
If you installed Patch B, please remove .log, start IDE, try
operation
you
cannot perform, close IDE and send me .log together with
snapshot
of
the
error message box. I helps to identify the problem.

Thanks,

Alex
"Rüdiger Loos" <Ruediger.Loos@3SOFT.de> wrote in message
news:bhb0u0$750$1@inn.qnx.com...
Having heard the patchB to 6.2.1b shall solve my problem
I've
installed
the
patch. But, no way, I still have the same problem.
By the way, the Build ID is Build id: 200304070109
the date of build for /usr/sbin/qconn is 12th Aug 2003 - I
believe
it's
the
installation date.
The size of qconn on my target is 70708 Bytes.
The file attached contains the content of my .log file
after
having
tried
to
debug my application.

Meanwhile I think it would be the best to reinstall
Momentics
version
6.2.0,
where this problem did not exist :-(

regards
Rüdiger Loos


"Alex Chapiro" <achapiro@qnx.com> schrieb im Newsbeitrag
news:bhak3c$r98$1@inn.qnx.com...
At least let me know Build ID from the About QNX
Momentics
IDE
dialog.
For target please check the date of build for
/usr/sbin/qconn.

"Rüdiger Loos" <Ruediger.Loos@3SOFT.de> wrote in message
news:bha8mq$je7$1@inn.qnx.com...
We definitely have version 6.2.1a installed on out
host.
As I've heard from our customer, his/our target uses
version
6.2.1,
but
we
don't know whether it is 6.2.1 or 6.2.1a.
When I have the target connected to my host, how can I
determine
the
version
of the os installed on my target?

Thanks in advance
Rüdiger Loos

"Alex Chapiro" <achapiro@qnx.com> schrieb im
Newsbeitrag
news:bh8ic0$ck9$1@inn.qnx.com...
Things keep getting to be more and more weird.:-))).
I
guess
before
continuing of this issue investigation it is a good
time
to
ask
you
which
version are you using on your host and on your
target?
Host
build
version
you can find in about dialog. As far as I remember,
we
never
shipped
6.2.1A.
This is important to know in order to look at
correct
code.

Alex Chapiro


"Rüdiger Loos" <Ruediger.Loos@3SOFT.de> wrote in
message
news:bh7mhp$mpr$1@inn.qnx.com...
I have no problem transfering the file from host
to
target
using
file
system
navigator. Even larger files (10MB instead of
470kB)
can
be
transfered
without any problem.

"Alex Chapiro" <achapiro@qnx.com> schrieb im
Newsbeitrag
news:bh0edt$g2t$1@inn.qnx.com...
According to your log report, exception occurs
while
transferring
file
from
host to target. Exception message is just an
errno
description.
Could
you
please try to copy the same file from host to
/tmp
on
target,
using
File
System Navigator?

"Rüdiger Loos" <Ruediger.Loos@3SOFT.de> wrote in
message
news:bh0cdg$el9$1@inn.qnx.com...
Hi Alex,

yes I've linked /tmp to /dev/shmem. But the
space
used
does
not
exceed
128kB.

Rüdiger

"Alex Chapiro" <achapiro@qnx.com> schrieb im
Newsbeitrag
news:bh0bkt$e1p$1@inn.qnx.com...
Do you have /tmp linked to /dev/shmem? If
so,
how
much
space
it
uses
currently? It can easily exhaust your target
memory.

Alex Chapiro

"Rüdiger Loos" <Ruediger.Loos@3SOFT.de
wrote
in
message
news:bgvo77$9m$1@inn.qnx.com...
No Mikhail, it does not.
This happens with every single application
trying
to
debug.
I have 128MB RAM on my target and I can't
debug
a
"hello
world"
program
:-(

Rüdiger

"Mikhail Khodjaiants" <mikhailk@qnx.com
schrieb
im
Newsbeitrag
news:bgtqdo$je3$1@nntp.qnx.com...
It seems that your target is running out
of
memory.

Mikhail

"Rüdiger Loos" <Ruediger.Loos@3SOFT.de
wrote
in
message
news:bgt56j$3o5$1@inn.qnx.com...
Hallo David,

I think the important entries are:

--------------------------
!ENTRY org.eclipse.debug.ui 4 120 Jun
17,
2003
12:47:13.220
!MESSAGE Error logged from Debug UI:
!STACK 1

org.eclipse.core.runtime.CoreException[503]:
java.io.IOException:
Open
Not
enough memory
at



















com.qnx.tools.utils.target.TargetServiceFile.connect(TargetServiceFile.java:
347)
at



















com.qnx.tools.utils.target.TargetServiceFile.creat(TargetServiceFile.java:24
3)
at



















com.qnx.tools.utils.target.TargetFileDownload.download(TargetFileDownload.ja
va:54)
at



















com.qnx.tools.ide.qde.internal.ui.launch.LaunchConfigurationDelegate.perform

FileTransfer(LaunchConfigurationDelegate.java:443)
at



















com.qnx.tools.ide.qde.internal.ui.launch.LaunchConfigurationDelegate.launch(
LaunchConfigurationDelegate.java:144)
at



















org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfigurati
on.java:136)
at



















org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationDialog

$10.run(LaunchConfigurationDialog.java:2299)
at



















org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext
.java:98)
!ENTRY com.qnx.tools.ide.qde.ui 4 503
Jun
17,
2003
12:47:13.220
!MESSAGE Can't transfer file for etx :
Open
Not
enough
memory
!STACK 0
java.io.IOException: Open Not enough
memory
at



















com.qnx.tools.utils.target.TargetServiceFile.connect(TargetServiceFile.java:
347)
at



















com.qnx.tools.utils.target.TargetServiceFile.creat(TargetServiceFile.java:24
3)
at



















com.qnx.tools.utils.target.TargetFileDownload.download(TargetFileDownload.ja
va:54)
at



















com.qnx.tools.ide.qde.internal.ui.launch.LaunchConfigurationDelegate.perform

FileTransfer(LaunchConfigurationDelegate.java:443)
at



















com.qnx.tools.ide.qde.internal.ui.launch.LaunchConfigurationDelegate.launch(
LaunchConfigurationDelegate.java:144)
at



















org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfigurati
on.java:136)
at



















org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationDialog

$10.run(LaunchConfigurationDialog.java:2299)
at



















org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext
.java:98)
-------

and

-------
!ENTRY org.eclipse.debug.ui 4 120 Apr
07,
2003
15:13:49.875
!MESSAGE Error logged from Debug UI:
!STACK 1

org.eclipse.core.runtime.CoreException[150]:
java.io.IOException:
Exec
error:Launching failed
at

org.eclipse.cdt.utils.spawner.Spawner.exec(Spawner.java:215)
at

org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:48)
at









org.eclipse.cdt.utils.spawner.ProcessFactory.exec(ProcessFactory.java:70)
at



















org.eclipse.cdt.launch.internal.LocalCLaunchConfigurationDelegate.exec(Local
CLaunchConfigurationDelegate.java:213)
at



















org.eclipse.cdt.launch.internal.LocalCLaunchConfigurationDelegate.launch(Loc

alCLaunchConfigurationDelegate.java:138)
at



















org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfigurati
on.java:136)
at



















org.eclipse.debug.internal.ui.actions.RelaunchActionDelegate.relaunch(Relaun
chActionDelegate.java:56)
at



















org.eclipse.debug.internal.ui.actions.RelaunchActionDelegate.relaunch(Relaun
chActionDelegate.java:32)
at



















org.eclipse.debug.internal.ui.actions.RelaunchHistoryLaunchAction$1.run(Rela
unchHistoryLaunchAction.java:59)
at




org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:66)
at



















org.eclipse.debug.internal.ui.actions.RelaunchHistoryLaunchAction.run(Relaun
chHistoryLaunchAction.java:57)
at

org.eclipse.jface.action.Action.runWithEvent(Action.java:749)
at



















org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(Action
ContributionItem.java:407)
at



















org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent(ActionCont
ributionItem.java:361)
at



















org.eclipse.jface.action.ActionContributionItem.access$0(ActionContributionI
tem.java:352)
at



















org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(A
ctionContributionItem.java:47)
at


org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77)
at

org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:827)
at



org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1529)
at


org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1291)
at



org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1343)
at

org.eclipse.ui.internal.Workbench.run(Workbench.java:1326)
at



















org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.jav
a:831)
at

org.eclipse.core.boot.BootLoader.run(BootLoader.java:462)
at
java.lang.reflect.Method.invoke(Native
Method)
at
org.eclipse.core.launcher.Main.basicRun(Main.java:247)
at
org.eclipse.core.launcher.Main.run(Main.java:703)
at
org.eclipse.core.launcher.Main.main(Main.java:539)
-----

My momentics is running on a Windows
XP
PC
an
connected
via
Ethernet
with
my
X86 target.

The type of project is a "QNX C
Application
Project".

Regards

Rüdiger

P.S. I've heard of a patchB for
Momentics
6.2.1
that
should
solve
the
problem?!?


"David Gibbs" <dagibbs@qnx.com
schrieb
im
Newsbeitrag
news:bgrblu$j0n$2@nntp.qnx.com...
"Ruediger Loos"
Ruediger.Loos@3soft.de
wrote:
Hallo,

I have a big problem in debugging
my
QNX
application.
I build my apps without any error
and
warning.
But when I start to debug my apps,
I
get
a
"Launch
Configuration
Error"
with
one of the following informations:
"Exception occured processing
launch
configuration.
Reason:
Failed
Launching
CDI Debugger: Error initializing:
Exec
error:Launching
failed"
or
"Exception occured : Not enough
memory"

Can anybody help me.

There's probably a .log file
generated
in
workspace/.metadata,
can
you
post the corresponding entry?

Also, what host are you running on?

Are you out of/low on system memory?

What type of project is it? (QNX
C/C++?
Standard
Make?)

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if
you
have
further
questions.








































Peter Graves

Re: Debugging problems in 6.2.1a

Post by Peter Graves » Mon Aug 18, 2003 1:26 pm

It sounds like the target machine is not running the new qconn in
6.2.1B. If you replace qconn on the target machine with the one from
6.2.1B it should work better.
-Peter

Jack Rosenbloom wrote:
Hi David,

I just re-installed 6.2.1B. The exact ewrror I get is

Can't launch file for Appl:target launcher@<localhost:8000>: error
invalid argument setting working dir /tmp/qconnCAAb63864/

Jack


David Gibbs wrote:

Jack Rosenbloom <jrosenbloom@vertisinc.com> wrote:

Thanks for the response. I have 2 questions.



1) I don't see an upload tab in version 6.2.1a. Should I, or is it
only in 6.2.1B?



No, I don't think that tab existed in 6.2.1A. Part of the changes in
B was in the launch mechanism.


2) How sure are you that this solution will work. Switching between
the A and B versions and back again is hours of work? By the way,
what is a stripped executable?



When you build a debug executable, it includes lots of debug information
in the program as it resides on disk. This information is only needed
by the debugger on the host side, and is not needed to execute the
program
on the target. And, it can more than double the size of the executable.
For small programs, not much of an issue...but if you're program is 1M,
then ending up with 3M because of debug... is an issue. The "strip"
strips out (removes) the debug information from the executable, and
only uploads the stuff actually needed to run the executable.

As to how sure am I this will work? Do you get an error dialog
saying that is is unable to open some (strange) pathname, with
a C: part way through the path? If that was your error, this
fixed it for me.

-David

Rüdiger Loos

Re: Debugging problems in 6.2.1a

Post by Rüdiger Loos » Tue Aug 19, 2003 5:21 pm

Please check whether you have the right version of "qconn" as Peter says,
and additionally you need the "pdebug" file in your /usr/bin directory

Rüdiger

"Jack Rosenbloom" <jrosenbloom@vertisinc.com> schrieb im Newsbeitrag
news:3F3D207F.1020909@vertisinc.com...
Hi David,

I just re-installed 6.2.1B. The exact ewrror I get is

Can't launch file for Appl:target launcher@<localhost:8000>: error
invalid argument setting working dir /tmp/qconnCAAb63864/

Jack


David Gibbs wrote:
Jack Rosenbloom <jrosenbloom@vertisinc.com> wrote:

Thanks for the response. I have 2 questions.


1) I don't see an upload tab in version 6.2.1a. Should I, or is it only
in 6.2.1B?


No, I don't think that tab existed in 6.2.1A. Part of the changes in
B was in the launch mechanism.


2) How sure are you that this solution will work. Switching between the
A and B versions and back again is hours of work? By the way, what is a
stripped executable?


When you build a debug executable, it includes lots of debug information
in the program as it resides on disk. This information is only needed
by the debugger on the host side, and is not needed to execute the
program
on the target. And, it can more than double the size of the executable.
For small programs, not much of an issue...but if you're program is 1M,
then ending up with 3M because of debug... is an issue. The "strip"
strips out (removes) the debug information from the executable, and
only uploads the stuff actually needed to run the executable.

As to how sure am I this will work? Do you get an error dialog
saying that is is unable to open some (strange) pathname, with
a C: part way through the path? If that was your error, this
fixed it for me.

-David

Post Reply

Return to “qdn.public.devtools”