Getting Started Debug Using Eclipse error

Using Colibri VF61 and Colibri evaluation board I am following the Getting Started Guide. I am having trouble in the section Debug Using Eclipse. I have written and compiled the hello-world example, and gone through all the steps to configure debugging in Eclipse. When I get to step 19 to launch my application for debugging, I click the down-arrow to the right of the debug icon and select hello-world Debug, and Eclipse gives me the following error:

‘Launching hello-world Debug’ has encountered a problem.
Error during file upload.

Clicking on Details gives the following:

Error during file upload.
Could not write file: /home/keith/eclipse-workspace/hello-world/Debug/hello-world.
Failure
Could not write file: /home/keith/eclipse-workspace/hello-world/Debug/hello-world.
Could not write file: /home/keith/eclipse-workspace/hello-world/Debug/hello-world.
Failure

I am running Ubuntu 18.04.1 64 bit under VirtualBox on a Windows 10 computer. My Eclipse is Photon Release 4.8.0. My target system in connected to my LAN. On the target system ifconfig reports the eth0 IP address as 192.168.1.15. I can ping the target system from a terminal in my virtual Ubuntu system. I did set the environment variables using . /usr/local/oecore-x86_64/environment-setup-armv7at2hf-neon-angstrom-linux-gnueabi in the terminal before launching eclipse from the same terminal.

I’m kind of stuck at this point. Any suggestions?

More information. I found out that /home/root/hello-world-debug already existed on my target system (must have been successfully uploaded after all). So I deleted it from the target system and tried to launch the application for debugging in Eclipse again. This time I get a different error. Eclipse says:

‘Launching hello-world Debug’ has encountered a problem. Could not start gdbserver on the remote host. See console output for more details.

The console output has the following:

gdbserver :2345 /home/root/hello-world-debug;exit

Last login: Tue sep 25 20:14:21 2018 from 192.168.1.11

root@colibri-vf:~# gdbserver :2345 /home/root/hello-world-debug;exit

Can’t bind address: Address already in use.

Exiting

Logout

Looks like gdbserver is already running. What does ps ax say? You may e.g. power cycle your board and try again.

Tried again today. Launched Eclipse. It notified me that some software updates were available, so I decided I may as well be running the latest and greatest. So I installed the Eclipse updates, then exited Eclipse and launched it again. I then powered up my target system, and selected Debug hello-world Debug in Eclipse. It seemed to be taking longer that it did yesterday, which I thought might be a good sign. Then it popped up an error dialog which said:

'Launching hello-world Debug' has encountered a problem.
Error during file upload.
Clicking Details shows the following:
Error during file upload.

org.eclipse.remote.core.exception.RemoteConnectionException: sh: locale: command not found
org.eclipse.remote.core.exception.RemoteConnectionException: sh: locale: command not found
org.eclipse.remote.core.exception.RemoteConnectionException: sh: locale: command not found
org.eclipse.remote.core.exception.RemoteConnectionException: sh: locale: command not found
org.eclipse.remote.core.exception.RemoteConnectionException: sh: locale: command not found

It’s different than yesterday. Don’t know if that is because I installed updates, or because I had just powered up the target system. I noticed that the hello-world-debug application had NOT been uploaded to my target system. So I decided to try to launch Debug hello-world Debug again. This time I got some different messages in the console window, ending with “Process /home/root/hello-world-debug created; pid = 447 Listening on port 2345” That sounds very good! But… in the Eclipse status bar it says “Launching hello-world Debug: (57%)”, and it has been stuck at 57% for over 10 minutes now. No notification about switching to the the debug perspective. It just seems to be stuck here. Meanwhile, ps ax at the target debug terminal does show both pid 474 /home/root/hello-world-debug and pid 444 gdbserver :2345 /home/root/hello-world-debug. It seems like the right stuff is running on the target system, but Eclipse seems to be stuck!

Any more suggestions?

hi

Error during file upload
org.eclipse.remote.core.exception.RemoteConnectionException: sh: locale: command not found

I have found the answer of this problem here. It seems, there is no locale support installed on the module. Which Bsp version are you using exactly? Could you install locale support on the module using the command opkg install glibc-utils?

Additionally could you also check the ports needed for the communication with the module are not blocked by the windows firewall.

Best regards, Jaski

I am using the Linux image recommended in the getting started guide, Colibri-VF_LXDE-Image_2.8.3, so whatever board support package was used by Toradex to build that image is the BSP being used. I agree that locale does not appear to be part of that LXDE Linux image. I attempted to install locale using opkg install glibc-utils as was suggested, but opkg reports “opkg_prepare_url_for_install: Couldn’t find anything to satisfy ‘glibc-utils’”. Also opkg list shows no such package.

So here is what is happening. The first time I attempt to launch hello-word Debug I get the “sh: locale: command not found error”, and the hello-world-debug app is NOT uploaded to the target system. So I try it a second time, and I don’t get any error, I find the hello-world-debug file IS uploaded to my target system, and in the Eclipse console window I see “Process /home/root/hello-world-debug created; pid = 446” and “Listening on port 2345”. At the debug terminal on the target system I can verify that hello-world-debug has been uploaded, and “/home/root/hello-world-debug” and “gdbserver :2345 /home-root/hello-world-debug” are both running per ps ax. BUT the status bar in Eclipse says “Launching hello-world Debug (57%)”, and it just stays at 57% forever. I never get to the debug perspective.

So all I am trying to do is follow the steps in the getting started guide, and it just doesn’t work. Where do I go from here?

I should have also noted that this does not appear to be a Windows firewall issue. I disabled Windows Firewall entirely, and my symptoms did not change at all. I’ll re-enable the firewall again now because I can’t afford to have my Windows 10 system unprotected!

I believe your issue(s) may stem from you using both a newer than recommended Ubuntu version as well as a newer Eclipse version. Unfortunately, depending on the exact Linux distribution used as well as the exact Eclipse version used certain things may definitely behave slightly differently. While we keep looking into the exact issue at hand you may have more success using the recommended 64-bit installation of Ubuntu 16.04 LTS together with Eclipse Neon.

@irbsd: Did you try to use Ubuntu 16.04?
best regards, Jaski

It has taken me a few days, but I was finally able to download Ubuntu 16.04 and Eclipse Neon and put together another Virtualbox VM with all the required tools. I could not find an Eclipse Neon installer as described in the Getting Started guide, so had to download Eclipse Neon CDT as an archive which I extracted into /home/root/eclipse. Then I created my “hello-world” sample program in eclipse and configured everything for debugging per the Getting Started guide.

Using Ubuntu 16.04 and Eclipse Neon, the first time I attempt to launch the debugger I get the error “org.eclipse.remote.core.exception.RemoteConnectionException: sh: locale: command not found”.

The second time I attempt to launch the debugger the Eclipse status bar indicates “Launching hello-world Debug (57%)”, and it just stays at 57% forever. After about a half hour I finally clicked the square red stop button in the Eclipse console window, and got an error message “Could not start gdbserver on the remote host”. I found this strange, because I had verified that gdbserver WAS running on the remote host, and had been listening on port 2345 for the entire half hour.

So I tried a third time to launch the debugger, and the third time everything launched with no error messages, and Eclipse switched to the debug perspective, and I was able to debut the hello-world application.

I should note that I had increased the RAM allocated to my Linux virtual machine from 1.5GB up to 2.0GB. So I decided to increase the RAM on my Ubuntu 18.04 VM to 2.0GB as well, and repeat the same test.

First time I attempted to launch the debugger, “org.eclipse.remote.core.exception.RemoteConnectionException: sh: locale: command not found”.

Second time, stuck at 57%. Waited. Clicked square red stop button. Got an error message “Could not start gdbserver on the remote host”. But it had been running!

Third time, debugger launched OK.

So Ubuntu 16.04/Eclipse Neon did not work any better than Ubuntu 18.04/Eclipse Photon. They both give me the same crazy and inconsistent error messages.

Is running gdb remotely under Eclipse supposed to be so unreliable? Am I really supposed to just keep trying to launch the debugger over and over again until it finally succeeds? Or do I simply need to allocate more memory to the VM? I really can’t allocate any more memory to the VM until I upgrade the RAM in my Windows 10 computer. RAM is on order.

Is this development software even supposed to work at all under a Virtualbox virtual Linux system?

@irbsd: Usually this should work. However we will look into this issue and will come back soon to you.

Today I was able to install a RAM upgrade into my Windows 10 computer hosting the Ubuntu 16.04 VM running under Virtualbox. I was able configure the VM to use 4GB (4096MB) of RAM. So I launched the Ubuntu 16.04 VM, set the environment variables, and launched Eclipse Neon with the hello-world test application. Then I tried to launch the debugger from within Eclipse.

The first time I launched the debugger, I got the error message “org.eclipse.remote.core.exception.RemoteConnectionException: sh: locale: command not found”.

The second time I launched the debugger, it hung at 56%. After waiting a while I clicked the square red stop button the the console window and got “Could not start gdbserver on the remote host”. But of course I had confirmed that gdbserver had been running on the target system and had been listening on port 2345 the whole time.

The third time I launched the debugger it launched just fine and switched to the debug perspective.

So adding RAM to the virtual Ubuntu system did not help at all. I should note that the Ubuntu System Monitor indicated memory usage of only 40.2% after my debugging session was over (with Eclipse still running), so I believe memory is not an issue.

So why can’t I get the debugger to work reliably in Eclipse Neon running on Ubuntu 16.04 in a Virtualbox VM. Is this thing supposed to work in a virtual machine? Have you even tested this? What am I supposed to do now?

hi @irbsd

We used Ubuntu 16.04 on VirtualBox on Windows 10 and did the debugging. It works without any issues.

It is difficult to see what is not working. Which Toolchain are you using? Please make sure to use the correct toolchain for your image. The images for regular demo bsp can be found here.

I installed the toolchain by very carefully following the instructions in the Getting Started guide. It states:

Download the 64-bit SDK from here.

It includes the cross toolchain for building applications on the host machine, as well as the target root filesystem with development headers.

“here” is a link to the following url:
https://developer1.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/SDKs/2.8/colibri-vf/console-tdx-image/angstrom-glibc-x86_64-armv7at2hf-neon-v2017.12-toolchain.sh

I downloaded that file (size 319204339 bytes) and ran it to install the toolchain.

However, when I follow the link to the toolchain in your post, I find there are two different toolchains available for the colibri-vf SOM. One is for the angstrom-lxde-image, and is called angstrom-glibc-x86_64-armv7at2hf-neon-v2017.12-toolchain.sh, with a size of 436M. The other is for the console-tdx-image, and is called angstrom-glibc-x86_64-armv7at2hf-neon-v2017.12-toolchain.sh, with a size of 304M. Yes, the file name is exactly the same, but the file size is different! At this point I don’t know if the toolchain that I downloaded and installed matches either one of these, since you apparently have different toolchains with different file sizes with exactly the same file name!

I simply tried to follow the Getting Started guide exactly. I should note that when I installed the Linux image on the VF61 module I carefully followed the instructions in the Getting Started guide, which states:

Download the pre-built Linux image. Find the latest Toradex pre-built image for your module here.

Note: Due to the limited amount of RAM available on Colibri VF50, the full LXDE demo image simply won’t fit. Please use the console-tdx-image aka Colibri-VF_Console-Image instead.

“here” is a link to the following url:
https://developer.toradex.com/software/linux/linux-software#Binary_Images

I followed that link, and downloaded and installed a Linux image called Colibri-VF_LXDE-image_2.8b3.111-20180626.tar.bz2, with a size of 80582109 bytes, since I am using a VF61 with more memory then the VF50.

Note that my application does NOT require a GUI desktop interface at all. It will use a web interface accessed via a browser, and a simple keypad and character based LCD display.

So I now have several questions.

  1. Are there really different toolchains I need to use depending on whether I have installed the LXDE or the console based Linux image?

  2. Given that I do not need a GUI desktop environment, can you please give me links to both the Linux image that I should install, and the proper COMPATIBLE toolchain that I should install?

Perhaps if I install all the right things, everything might work better. But honestly, I did try to follow the Getting Started guide very precisely, and things simply did not work as expected.

Dear @irbsd,

Thanks for the feedback. I have improved the Eclipse install and debug lessons since your first contact and will further keep improving the guide as a whole.

Below are my comments to your points:

However, when I follow the link to the toolchain in your post, I find there are two different toolchains available for the colibri-vf SOM. One is for the angstrom-lxde-image, and is called angstrom-glibc-x86_64-armv7at2hf-neon-v2017.12-toolchain.sh, with a size of 436M. The other is for the console-tdx-image, and is called angstrom-glibc-x86_64-armv7at2hf-neon-v2017.12-toolchain.sh, with a size of 304M. Yes, the file name is exactly the same, but the file size is different! At this point I don’t know if the toolchain that I downloaded and installed matches either one of these, since you apparently have different toolchains with different file sizes with exactly the same file name!

The provided SDKs are meant only to be used with the Getting Started Guide.

They are provided as-is, which is stated in the SDKs directory: https://developer1.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/SDKs/ReadMe.txt

I will further add a note in the Getting Started Guide highlighting this specific points. Pardon for your trouble. That being said, to build the Getting Started Guide examples, choosing either the angstrom-lxde-image or console-tdx-image SDKs/toolchains will provide the same results.

Regarding the naming, the deafult name is the same as generated from an OpenEmbedded build. I may rename the SDKs to prevent this confusion.

I followed that link, and downloaded and installed a Linux image called Colibri-VF_LXDE-image_2.8b3.111-20180626.tar.bz2, with a size of 80582109 bytes, since I am using a VF61 with more memory then the VF50.

You are correct, that is appropriate.

Note that my application does NOT require a GUI desktop interface at all. It will use a web interface accessed via a browser, and a simple keypad and character based LCD display.

The default pre-built evaluation image provided by Toradex may not be a perfect fit for all customers, even though it is a production-ready image. You can use it as-is or customize the image, in which case we recommend the use of OpenEmbedded, and we provide instructions for recreating and customizing the image. Please see https://developer.toradex.com/software/linux/linux-software#Recreate_and_Customize_BSP_with_OpenEmbedded_core

  1. Are there really different toolchains I need to use depending on whether I have installed the LXDE or the console based Linux image?

As mentioned above, for the trivial Getting Started Guide examples, both the angstrom-lxde-image and console-tdx-image toolchains will work. For more complex matters, you are encouraged to create your own toolchain.

The SDKs/toolchains are provided as-is. Same as with the embedded Linux image customization, you can generate an SDK tailored for your custom image using OpenEmbedded: https://developer.toradex.com/knowledge-base/board-support-package/openembedded-(core)#Building

  1. Given that I do not need a GUI desktop environment, can you please give me links to both the Linux image that I should install, and the proper COMPATIBLE toolchain that I should install?

As of now, the official Toradex pre-built evaluation image is an Ångström based image with the LXDE desktop environment. The Linux Console image is an alternative provided for the Colibri VFxx modules, which are on the low end of HW configuration (i.e. RAM size, flash size). Using OpenEmbedded you can also build an image without a desktop environment.

If you choose to use our pre-built image, either Linux LXDE image or Linux Console Image can be chosen.

Perhaps if I install all the right things, everything might work better. But honestly, I did try to follow the Getting Started guide very precisely, and things simply did not work as expected.

Since we are driven towards customer focus, I will use your feedback to improve the documentation in order to provide a better customer experience.

I am still struggling trying to get the debugger to work reliably. I am now running Ubuntu 16.04 with Eclipse Neon in a virtual machine with VirtualBox configured to use 4GB of RAM, running on my Windows 10 machine.

I have downloaded and installed a console based Linux image to my target system from the following:

https://developer1.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Colibri-VF_Console-Image_2.7-20180104.tar.bz2

I have downloaded and installed the toolchain from the following:

https://developer1.toradex.com/files/toradex_dev/uploads/media/Colibri/Linux/SDKs/2.7/console-tdx-image/colibri-vf/angstrom-glibc-x86_64-arm7at2hf-neon-v2016.12.toolchain.sh

I chose the console version for both the Linux image and the toolchain. I stayed away from the version 2.8 versions because they were listed as Beta, and I wanted something that was stable. I hope the versions I chose are compatible with each other, and well tested to work properly.

After installing the Linux Image to the target system and the toolchain to the virtual Ubuntu 16.04 system I set the environment variables, launched Eclipse Neon, and compiled the sample Hello World application. It compiled without any problems. BUT, when I tried to launch the debugger I got the same problems I have been experiencing all along.

The first time I try to launch the debugger I get an error about locale not found.

The second time I try to launch the debugger it hangs at 57%. After waiting a long time I terminate it with the square red button in the Eclipse console window, and it says it could not launch gdbserver on the remote server (but I had verified that it was running on the target system).

The third time I try to launch the debugger it launches just fine, and switches to the debug perspective. I can then debug the application.

But If I shut things down, the next time it will once again fail to launch the debugger on the first two attempts. This is becoming very frustrating. All I am trying to do is follow the Getting Started Guide, and things don’t seem to work very well. This has not been a good experience for me. Please help.

hi @irbsd

It seems to be an eclipse problem as discussed here. Could you share the exact version of eclipse and java you have installed?

Eclipse Help->About reports:

Eclipse IDE for C/C++ Developers
Version: Neon.3 Release (4.6.3)
Build id: 20170314-1500

java -version reports:

openjdk version “1.8.0-181”

Synaptic package manager shown my installed java package as:

openjdk-8-jre 8u181-b13-0ubuntu0.16.04.1

I checked the link you gave for an Eclipse problem that may be related to my problem, and I doubt that it is related at all. The users in that post were using Eclipse Galileo, which is seven major releases older that the Neon which I am using.

So I still cannot reliably launch the debugger. What do I do now?

For me “hangs at 57% sounds very suspicious”. Could you zip your Eclipse Workspace and the Eclipse settings and share them? Thanks.

I have zipped my eclipse workspace. I also did File->Export General->Preferences to get my eclipse preferences, and I zipped that file. I don’t know if that gives you all the eclipse preferences you need. Eclipse has a LOT of settings, and maybe you need some others too, like maybe Run/Debug Launch configurations? Let me know if I left anything out.

You only need to be concerned with the Hello World project in the workspace. The other projects were just some other tests I was trying to run. I hope I did the file attachments correctly.

Zipped files are attached.link text