Creation of Hello World RISC-V xPack Project hangs

The process of creating Hello World RISC-V QEMU xPack C/C++ Project hangs indefinitely after displaying "xpm init --template...." dialog.

Environment:

Debian 12 x86-64 with XFCE desktop
Eclipse IDE for Embedded C/C++ Developers unpacked from version 2024-12-R-linux-gtk-x86_64 archive without modifications
npm 9.2.0 (from Debian repo)
xpm 0.20.8
Prerequisite xPacks: see xpm-list.txt

The last message in Eclipse console log is !MESSAGE > /bin/bash -i -c xpm init --template @micro-os-plus/hello-world-qemu-template@1.4.1 --property target=riscv-rv32imac --property language=cpp --property buildGenerator=cmake. If started from shell, the listed xpm init command completes in seconds.

The new project's directory is created, but contains only common Eclipse-related files:

$ ls -la ~/eclipse-workspace/hello/
total 40
drwxr-xr-x 3 mvm mvm  4096 Mar 10 22:51 .
drwxr-xr-x 4 mvm mvm  4096 Mar 10 22:51 ..
-rw-r--r-- 1 mvm mvm 21558 Mar 10 22:51 .cproject
-rw-r--r-- 1 mvm mvm   806 Mar 10 22:51 .project
drwxr-xr-x 2 mvm mvm  4096 Mar 10 22:51 .settings

I've set up a clean VM to reproduce the issue and would be happy to provide any additional details.

After playing a bit with the workbench UI I've finished with Progress tab visible:

Hope the visible messages are helpful.

I did a first test on macOS and the project was created successfully. Probably the issue is specific to Linux; more tests are needed.

I did a second test on a Raspberry Pi5; the project was created successfully, the xpm install satisfied all dependencies, the build passed and I was able to run step-by-step in a debug session with QEMU.

So the issue is either specific to x64 Linux or to your distribution.

I've been able to reproduce this on Zorin OS 17.2 Core (a x86_64 Ubuntu derivative distro).

I did another test on a fresh Ubuntu 24 LTS, with Eclipse 2024-12, and the project was created as expected. So it is not specific to x64.

Please note that at the first run the xpm install step takes a few minutes, since it must download the large toolchain.

I did another test on a fresh Ubuntu 24 LTS, with Eclipse 2024-12, and the project was created as expected. So it is not specific to x64.

Are you definitely using the specific versions of the xPacks mentioned in the original post and not, say, the latest versions? Just in case it makes any difference?

Please note that at the first run the xpm install step takes a few minutes, since it must download the large toolchain.

I left my test running for a few hours and it remained "stuck".

In case it matters I installed all of the xPacks using xpm install ... --global.

specific versions of the xPacks

The Ubuntu 24 machine is freshly installed, with xpm 0.20.8 and npm 11.2.0.

The xpm init command explicitly refers to the template, and xpm install downloads the versions mentioned in the generated package.json.

If xpm init --template ... hangs, I guess there is a problem downloading the template, problem that does not occur when running manually in a terminal. One such common problem is the proxy configuration.

I left my test running for a few hours and it remained "stuck".

It is not very clear in your comment, did it hang during init or install? If you run the init command by hand, does it work?

It is not very clear in your comment, did it hang during init or install?

I reproduced the problem as described here using the Eclipse IDE:

Creation of Hello World RISC-V xPack Project hangs #626 (comment)

It's stuck on this:

If you run the init command by hand, does it work?

You mean this command?

xpm init --template @micro-os-plus/hello-world-qemu-template@1.4.1 --property target=riscv-rv32imac --property language=cpp --property buildGenerator=cmake

That completes successfully when run from the terminal command line.

One such common problem is the proxy configuration.

I don't have any proxy configuration and all other internet/connected activity works fine.

I've thought about network issues and performed the following to rule them out:

install everything (including xpm install'ing --global for all of the eleven required xPacks)
disable networking on the VM
(network disabled) manually run xpm init+xpm install to set up a test helloworld project, completes successfully within seconds
(network disabled) attempt to create Hello world in Eclipse - no luck, hangs indefinitely.

The successful second manual run with network disabled confirms that xpm keeps a cache.

So the problem is not caused by xpm hanging during download.

It remains to be seen why Eclipse hangs when invoking xpm. Do you see the xpm init process running?

If not, it means Eclipse is not able to create the xpm process. If yes, it would be useful to enable a kernel trace on that process, perhaps we can identify why it hangs.

When Eclipse is stuck on xpm init ... I see this in htop:

/bin/bash -i -c xpm init ... means Eclipse created the bash process.

xpm is a node script that starts with #!/usr/bin/env node, which means to run the script via node.

Do you also see the node process?

Do you also see the node process?

No.

ps -ax | grep -i node
   2512 ?        Ss     0:00 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/1000/doc
   6648 pts/0    S+     0:00 grep --color=auto -i node

huh, that's weird! When Eclipse hangs process list lists the bash process but not xpm started by that bash:

$ ps ax | grep xpm
   2055 ?        Sl     0:02 geany /home/mvm/Downloads/xpm-list.txt
   2829 pts/1    T      0:00 /bin/bash -i -c xpm init --template @micro-os-plus/hello-world-qemu-template@1.4.1 --property target=riscv-rv32imac --property language=cpp --property buildGenerator=cmake
   2842 pts/2    S+     0:00 grep xpm

Wait, shouldn't the command given to bash -c be quoted? And I believe -i means 'interactive', why should background-run command be interactive?

PS If started manually, xpm install is listed as 'xpm' in process list.

shouldn't the command given to bash -c be quoted?

It is, but the quotes are not shown.

Background processes are started via org.eclipse.cdt.utils.spawner.ProcessFactory, not by the plug-ins.

Avoid hanging on Linux when launch xpm

Great! Let me know when you have a binary that I can test on my mac.

Do you want me to merge #649 so you can test from develop (or master) build, or would you like to test https://download.eclipse.org/embed-cdt/builds/fix-spawn/p2/ before I merge.

LMK - I want to get this into master and close off 6.7.0 by EOD Wednesday 18th Feb.

I tried it on my Raspberry Pi5 test machine running RPi OS, and, when Eclipse is started from the file manager, it performs as expected, the Arm xPack project is created, dependencies are installed and the build passes.

However, when Eclipse is started from a terminal, it no longer hangs as it did before but... it fails without any error, the logs are clean, just some template steps but no exceptions. :-(

To my surprise, xpm runs correctly, I can see the output in the console where Eclipse is started, but apparently the xpm process is disconnected from Eclipse.

Did this version behaved correctly on your Linux test machines?

It seems to have worked when running in my dev environment, but when I ran in a dedicated install, the xpm init stopped my IDE process:

$ ./eclipse/eclipse -data data -consoleLog
Feb 11, 2026 12:12:13 PM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider org.slf4j.simple.SimpleServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle slf4j.simple
--- snip ---
!ENTRY org.eclipse.embedcdt.managedbuild.cross.riscv.ui 4 1 2026-02-11 12:12:34.805
!MESSAGE > /bin/bash -i -c xpm install

[1]+  Stopped                 ./eclipse/eclipse -data data -consoleLog

If I do fg in the terminal, eclipse continues to run. What in the world is happening here.

I thought this was going to be easy to workaround because of my previous comment:

I have identified the problem - but not why it is a new problem. It looks like a bug in the Spawner, but after hours of looking into it I can't tell the difference. I have raised eclipse-cdt/cdt#1151 and here is a workaround to avoid using the Spawner because, at least on Linux, this works and this use case doesn't really need the extra features of the Spawner.

But not so much. I may spend a bit more time on this, but I'm not sure.

Anyway, without knowing the details of this patch, I would say that it slightly improved things, at least Eclipse no longer hangs. :-)

I also tested on my old Intel Mac, where I never had problems, and it is still functional.

If you confirm that on Windows it is also functional, you can merge this for now, and possibly look for a better solution later.

With the conversation starting here, I think we should remove the -i use on bash in embed-cdt here:

eclipse-plugins/plugins/org.eclipse.embedcdt.templates.core/src/org/eclipse/embedcdt/templates/core/processes/ConditionalRunCommand.java

Line 119 in 7f6f4ab

cmdArray[1] = "-i"; // To read .zshrc, where nvm is configured.

eclipse-plugins/plugins/org.eclipse.embedcdt.ui/src/org/eclipse/embedcdt/ui/templates/core/processes/ConditionalRunCommandUi.java

Line 108 in 87aaefc

cmdArray[1] = "-i"; // To read .zshrc, where nvm is configured.

eclipse-plugins/plugins/org.eclipse.embedcdt.core/src/org/eclipse/embedcdt/core/EclipseUtils.java

Line 511 in 91369c6

cmdArray[1] = "-i";

Because the comment in the code says to ensure .zshrc is read, then starting with -l instead of -i may be the "correct" thing to do here.

I'm not sure that -l will read the .*rc files, the documentation that I checked mentions only the .*profile files.

The environment for nvm/npm/xpm is configured in the .bashrc or .zshrc, thus the need tor -i.

Since this mechanism works when Eclipse is started via the file manager, I think a possible path to pursue is to try to identify the environment differences between this method and when starting Eclipse via a terminal.

Could you somehow run env in an Eclipse started in those two cases and do a diff on the results?

Launch xpm in a PTY

Launch xpm in a PTY (#650)

Navigation Menu

Repository navigation

Creation of Hello World RISC-V xPack Project hangs #626

77 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Creation of Hello World RISC-V xPack Project hangs #626

Description

Activity

mvm-mike commented on Mar 10, 2025

ilg-ul commented on Mar 10, 2025

ilg-ul commented on Mar 10, 2025

TommyMurphyTM1234 commented on Mar 10, 2025

ilg-ul commented on Mar 11, 2025

TommyMurphyTM1234 commented on Mar 11, 2025

ilg-ul commented on Mar 11, 2025

TommyMurphyTM1234 commented on Mar 11, 2025

mvm-mike commented on Mar 11, 2025

ilg-ul commented on Mar 11, 2025

TommyMurphyTM1234 commented on Mar 11, 2025

ilg-ul commented on Mar 11, 2025

TommyMurphyTM1234 commented on Mar 11, 2025

mvm-mike commented on Mar 11, 2025

ilg-ul commented on Mar 11, 2025

77 remaining items

jonahgraham commented on Feb 11, 2026

ilg-ul commented on Feb 11, 2026

jonahgraham commented on Feb 11, 2026

jonahgraham commented on Feb 11, 2026

ilg-ul commented on Feb 11, 2026

jonahgraham commented on Feb 11, 2026

ilg-ul commented on Feb 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions