Skip to content

Fix: Error [ERR_DLOPEN_FAILED] #1546

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

CaffeeLake
Copy link

@CaffeeLake CaffeeLake commented Aug 2, 2025

Fix: Error [ERR_DLOPEN_FAILED]

Error [ERR_DLOPEN_FAILED]: /tmp/.3bd968e1bc3ef7f7-00000001.node: cannot open shared object file: No such file or directory
  • This is likely a compatibility issue on the library side, so this patch temporarily avoids the error by skipping the use of the library and reverting to the previous behavior in environments where tree-sitter does not work Fix: Error [ERR_DLOPEN_FAILED] #1546 (comment) .

  • Since opencode is completely unusable in environments where this problem occurs and the urgency is high, I am submitting a PR in this format, but if you know of a better solution I would appreciate your information.

@hawkaii
Copy link

hawkaii commented Aug 2, 2025

image bun still gives error in arm64

@CaffeeLake CaffeeLake force-pushed the fix-err_dlopen_failed branch from 9a42a44 to ecb7eba Compare August 3, 2025 01:55
@CaffeeLake
Copy link
Author

@hawkaii thank you for reporting.
I fixed this issue, try this fix and see if it works.

@hawkaii
Copy link

hawkaii commented Aug 3, 2025

it works

teamgroove pushed a commit to teamgroove/opencode that referenced this pull request Aug 3, 2025
Merged from: sst#1546
Author: @CaffeeLake
Auto-merged by opencode-fork integration system
@thdxr
Copy link
Collaborator

thdxr commented Aug 3, 2025

could you fix the conflicts?

also can you describe what environment this is?

@CaffeeLake
Copy link
Author

CaffeeLake commented Aug 4, 2025

also can you describe what environment this is?

  • I had this issue on Debian 12.11, Linux 6.12.34, aarch64.
  • I don't know the exact circumstances that cause this issue.

@Frick
Copy link

Frick commented Aug 4, 2025

can you describe what environment this is?

I am also seeing this in a Linux 6.10.14 aarch64 container running in Docker Desktop on an M1 Max MBP, in either the Docker VMM or Apple Virtualization framework. This did not occur when using an amd64 version of the same container, though the TUI slowed to an absolute crawl when running in that manner (with or without using Rosetta on Apple Virtualization as well). So it seems like just generally Linux aarch64 was the cause, but only after v0.3.101 as mentioned here.

@CaffeeLake
Copy link
Author

CaffeeLake commented Aug 4, 2025

This may be related to the following Node.js behavior:

  • linux-x64
~/opencode % ls ./node_modules/tree-sitter-bash/prebuilds/linux-x64/
tree-sitter-bash.node
~/opencode % node ./node_modules/tree-sitter-bash/prebuilds/linux-x64/tree-sitter-bash.node
~/opencode %
  • linux-arm64
~/opencode % ls ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/
tree-sitter-bash.node
~/opencode % node ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node
node:internal/modules/cjs/loader:1846
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: ~/opencode/node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node: cannot open shared object file: No such file or directory
    at Object..node (node:internal/modules/cjs/loader:1846:18)
    at Module.load (node:internal/modules/cjs/loader:1423:32)
    at Function._load (node:internal/modules/cjs/loader:1246:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
    at node:internal/main/run_main_module:36:49 {
  code: 'ERR_DLOPEN_FAILED'
}

Node.js v22.18.0
~/opencode %

I couldn't find a command to call .node directly by bun, so I haven't been able to confirm the behavior by bun, but I think something similar will probably happen.

@lsj5031
Copy link

lsj5031 commented Aug 4, 2025

I'm running Debian Bullseye on WSL2 and experiencing the same issue. It's been unusable for a few days now. I’d appreciate a fix—thank you!

@Mahamed-Belkheir
Copy link
Contributor

@lsj5031 you can rollback to v0.3.101 and set autoupdate false in the global config until it's fixed, thats what I did

@CaffeeLake
Copy link
Author

CaffeeLake commented Aug 4, 2025

I've identified the exact cause.
This is because the tree-sitter-bash library contains ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node and ./node_modules/tree-sitter-bash/prebuilds/linux-x64/tree-sitter-bash.node, both of which are files built for linux-x64.

  • on linux-arm64
~/opencode %  ldd ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node
        not a dynamic executable
~/opencode %  ldd ./node_modules/tree-sitter-bash/prebuilds/linux-x64/tree-sitter-bash.node
        not a dynamic executable
~/opencode %
  • on linux-x64
~/opencode %  ldd ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node
        linux-vdso.so.1 (0x00007ffc25d73000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8871bc8000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8871b9c000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8871b98000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f88719a6000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f88718b8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8871f98000)
~/opencode %  ldd ./node_modules/tree-sitter-bash/prebuilds/linux-x64/tree-sitter-bash.node
        linux-vdso.so.1 (0x00007ffe2a794000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f5e05969000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5e0593d000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5e05939000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5e05747000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f5e05659000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5e05d39000)
~/opencode %

@achembarpu
Copy link

I've been facing this same blocking issue on a raspberry pi 5 running bullseye as well. Happy to test the fix once it's ready!

@CaffeeLake CaffeeLake force-pushed the fix-err_dlopen_failed branch 2 times, most recently from d355987 to d26b139 Compare August 4, 2025 12:59
@CaffeeLake
Copy link
Author

CaffeeLake commented Aug 4, 2025

This tree-sitter-bash issue occurs in v0.23.2 and later.
Downgrading tree-sitter-bash to v0.23.1 worked fine.
It works with tree-sitter-bash v0.25.0, but in that case type errors and build errors occur on the tree-sitter side.
It only worked fine with the combination of tree-sitter v0.23.3 + tree-sitter-bash v0.23.1.
Therefore, in this PR I have changed it to use that version combination.
This should allow it to work properly on arm64 without skipping features.
I cannot test whether it works in other environments such as macOS, and there is a possibility that other errors may occur in the library, so I left the skip function in case of an error as it is just in case.

@hawkaii
Copy link

hawkaii commented Aug 4, 2025

it's working but the packages/sdk/js is not built when i run bun run packages/opencode/src/index.ts
it gives the following error

  ┃  error: Cannot find module '@opencode-ai/sdk' from                                     ┃
  ┃  '/home/hawkaii/code/git/opencode/packages/op                                          ┃
  ┃  encode/src/plugin/index.ts'                                                           ┃
  ┃                                                                                        ┃
  ┃  Bun v1.2.19 (Linux arm64)                                                             ┃
  ┃  hawkaii (03:46 PM)                      

i had to build it by running cd packages/sdk/js && bun run tsc
and then run the command

@CaffeeLake
Copy link
Author

CaffeeLake commented Aug 4, 2025

it's working but the packages/sdk/js is not built when i run bun run packages/opencode/src/index.ts

@hawkaii This error also occurs in the latest dev branch.
It is unrelated to this change.
Maybe bun dev or bun run --conditions=development packages/opencode/src/index.ts works.
#1567

@CaffeeLake
Copy link
Author

@thdxr @adamdotdevin This PR is ready. 🙏

@Frick
Copy link

Frick commented Aug 5, 2025

I can confirm that in my previously mentioned aarch64 container, without this patch on the dev branch at b459055 just now, I still see this error.

Screenshot 2025-08-05 at 09 23 35

After applying this patch, bash commands work as expected again.

Screenshot 2025-08-05 at 09 24 23

@CaffeeLake CaffeeLake force-pushed the fix-err_dlopen_failed branch from b9e0178 to 2ad722f Compare August 6, 2025 14:10
@germanilia
Copy link

when is this fixed expected to be merged?

@Frick
Copy link

Frick commented Aug 7, 2025

@thdxr or @adamdotdevin - @CaffeeLake has graciously been keeping this PR up to date and it would fix a serious issue facing arm64 users. Unfortunately it doesn't seem that the node-tree-sitter dependency is nearly as active as you two so unlikely to be fixed forward over there anytime soon. 🙏

@u011
Copy link

u011 commented Aug 7, 2025

getting the same issue, but only with certain models. ie Qwen in LMStudio via proxy
Fedora VM in MacOS, both arm
Error [ERR_DLOPEN_FAILED]: /tmp/.3bd968e1bc3ef7f7-00000001.node: cannot open shared object file: No such file or directory

@thdxr
Copy link
Collaborator

thdxr commented Aug 7, 2025

the fix here seems to skip permissions check if treesitter doesn't load? just making sure i'm understanding that right

i don't think we want to implement this fix, i'd rather fix the static binaries for treesitter

i will fix this - but to confirm the treesitter bash binary for arm64 is not built correctly?

@thdxr
Copy link
Collaborator

thdxr commented Aug 7, 2025

oh looks like you did figure out that an earlier version works! thank you - can you remove the try catch that skips it though? i want it to fail loudly so people continue to complain if it breaks

@CaffeeLake CaffeeLake force-pushed the fix-err_dlopen_failed branch from 2ad722f to cf370fe Compare August 7, 2025 23:03
@CaffeeLake
Copy link
Author

CaffeeLake commented Aug 7, 2025

@thdxr Thank you for checking.
It's certainly better to have an error.
I just removed the try catch that skips.
I updated the latest dev branch and it stopped working, so I'll check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

failing to run command on new update
9 participants