Transport error 202: connect failed: Connection refused


I installed openrndr yesterday but i had no luck so far and did not succeed to run the template program. :face_with_diagonal_mouth:

The debug message is the following :

Connected to the target VM, address: '', transport: 'socket'
Warning: Running on macOS without -XstartOnFirstThread JVM argument. Restarting JVM with -XstartOnFirstThread.
ERROR: transport error 202: connect failed: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:734]
Disconnected from the target VM, address: '', transport: 'socket'
Process finished with exit code 0

I am on mac 12.3, M1 chip. The version of intellij Idea is 2022.2.1. Corretto version is
The localhost address is correct and seems to work. I also tried to run a basic kotlin program on the IDE and it worked.

Do you have any indications to troubleshoot this?

Thanks for your help!

Hi @francois :slight_smile: Sorry I didn’t see your message earlier: somehow it was marked as spam.

Did you follow Set up your first program - OPENRNDR GUIDE ? Or what steps did you take?


Hello @abe !
Thanks for your reply. Yes, I followed this setup guide using and did a reinstall when I saw it didn’t work the first time.

In the meantime, I read the should I use OPENRNDR? section, where it is indicated :

For macOS, we support versions 10.10 to 10.14. Older versions may work, but this is hard to verify in a structural fashion.

Is it still true?

I know several people are using M1 based computers. Is that what you would like to know? Or for older OSes?

I’ll ask in Slack see if anyone knows why this happens.

@francois Could you try to add -XstartOnFirstThread to VM parameters when starting your program. It is required when running OPENRNDR as a java process on Mac OS, so as a workaround, if it is not specified, OPENRNDR will restart the whole JVM spawning the new java process with this parameter added. But it brakes debugging, as the internal IntelliJ debugging parameters are not passed to underlying process. Is it possible that you started your program in debug instead of run mode? When -XstartOnFirstThread is added straight ahead, no JVM relaunching happens.

True… I only see the “connecting to” when debugging, not when running the program.


Hi @abe and @kazik

Thanks for your help and sorry for the misleading information of my first post : I should have posted the information I got from running the program.

Here is the information I get from the run console (after adding -XstartOnFirstThread to VM parameters, as @kazik suggested) :

Connected to the target VM, address: '', transport: 'socket'
[LWJGL] Platform/architecture mismatch detected for module: org.lwjgl
	JVM platform:
		macOS aarch64
		OpenJDK 64-Bit Server VM v17.0.4.1+9-LTS by Inc.
	Platform available on classpath:
[LWJGL] Failed to load a library. Possible solutions:
	a) Add the directory that contains the shared library to -Djava.library.path or -Dorg.lwjgl.librarypath.
	b) Add the JAR that contains the shared library to the classpath.
[LWJGL] Enable debug mode with -Dorg.lwjgl.util.Debug=true for better diagnostics.
[LWJGL] Enable the SharedLibraryLoader debug mode with -Dorg.lwjgl.util.DebugLoader=true for better diagnostics.
 INFO [main]                                 ↘ Set -Dorg.openrndr.exceptions=JVM for conventional exception-handling

│  TemplateProgramKt.main(TemplateProgram.kt:-1)
├─ TemplateProgramKt.main(TemplateProgram.kt:9)
│  org.openrndr.ApplicationBuilderKt.application(ApplicationBuilder.kt:82)
│  org.openrndr.ApplicationBuilder.<init>(ApplicationBuilder.kt:102)
│  org.openrndr.ApplicationBase.Companion.initialize(ApplicationBase.kt:22)
├─ java.lang.reflect.Constructor.newInstance(
├─ java.lang.reflect.Constructor.newInstanceWithCaller(
├─ jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(
├─ jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(
│  jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(
↑ null (InvocationTargetException) 
├─ org.lwjgl.system.Library.loadSystem(
Disconnected from the target VM, address: '', transport: 'socket'

Process finished with exit code 1

I am not using Mac OS on daily basis, but from your log it seems that you have a difference between JVM platform used by OPENRNDR libraries, and the one used by macOS by default. You can make sure to download IntelliJ version for M1:

There is a drop down, to pick “Apple Silicon”, because it’s “Intel” by default. I believe that Intel will still work with Roseta on M1, but it will be a suboptimal experience - for example I remember that GPU acceleration was super sluggish when scrolling text in editor. IntelliJ comes with JVM compiled for Apple Silicon, so you should be able to pick it as a JVM for running your program. I hope it would solve the issue. You can also download such a JVM separately. The latest JDK 18 for applie silicon is here (called “arm 64” to make it even more confusing):

I checked : I have the right version of IntelliJ IDEA installed on my machine.
I also tried to run the template modifying the run configuration and indicating the last JRE you link. It unfortunately did not work.

Do I need to modify/add paths in the classpath to link to one of the JVM platform installed on my computer?

@antdegouv mentioned in Slack

no sure it’s related at all but, i have an M1, and sense one of the updates of the RnDR template, that it refuses to use the arm64 version of lwjgl. i need to copy one of my older projects to work.

None of the core members have an M1 as main computer to test, but someone will very soon :slight_smile: Maybe I can try next Sunday.

ok, I will wait for your feedback then! :slight_smile:

Hi there! Does changing this line


"arm-v8","aarch64" -> "macos-arm64"

help in your case? @antdegouv was also having issues on M1 and doing remote debugging @edwin figured out Gradle probably changed something that broke M1 detection.

Update: another thing that can help is adding -XstartOnFirstThread to the VM Options in the Run Configuration of your program. Latest openrndr from git has a fix for this.

Hello @abe,
Sorry for the late answer, I was abroad and away for my computer.

Adding "aarch64" makes things work! Thank you very much for the help!!
It also worked without -XstartOnFirstThread as a VM Options. The main issue was in the build.gradle.kts file.