bun
bun copied to clipboard
Node Serialport crashes
What version of Bun is running?
1.0.0+822a00c4d508b54f650933a73ca5f4a3af9a7983 (congrats btw!)
What platform is your computer?
Darwin 21.6.0 arm64 arm
What steps can reproduce the bug?
bun install @serialport/bindings-cpp- try to use serial port bindings, eg:
import { autoDetect } from "@serialport/bindings-cpp";
const Binding = autoDetect();
Binding.list();
This crashes with:
dyld[30366]: missing symbol called
What is the expected behavior?
The Node Serialport packages work as expected, the list command lists available serial ports etc.
What do you see instead?
Crash:
dyld[30366]: missing symbol called
Additional information
This package is the low-level interface for Node Serialport so I expect if this works the whole thing should. I suspect this issue has something to do with napi usage but I have 0 experience in this area.
+1
It crashes with SIGSEGV when doing something like this:
import { SerialPort } from "serialport";
const sp = new SerialPort({
path: "/dev/ttyUSB0",
baudRate: 9600,
autoOpen: true,
});
output: Job 1, 'bun src/index.ts' terminated by signal SIGSEGV (Address boundary error)
EDIT: using serialport version 12.0.0 (works with node on version 20)
This works for me in Bun 1.0.2:
$ bun install @serialport/bindings-cpp
import { autoDetect } from "@serialport/bindings-cpp"
const Binding = autoDetect()
console.log(await Binding.list())
// see a list correctly
But this doesn't (serialport is v12.0.0):
$ bun install serialport
import { SerialPort } from 'serialport'
const serial = new SerialPort({ path: '/dev/ttyACM0', baudRate: 115200, autoOpen: false })
serial.open((err) => console.log(err || 'success'))
Error shows as follows:
374 | writable: !1,
375 | configurable: !0
376 | }), fn;
377 | }
378 |
379 | function fn() {
^
error: Error
at fn (node:util:379:26)
at /mnt/c/code/node_modules/@serialport/bindings-cpp/dist/linux.js:31:19
at open (/mnt/c/code/node_modules/@serialport/bindings-cpp/dist/linux.js:19:15)
at open (/mnt/c/code/node_modules/@serialport/stream/dist/index.js:107:8)
at /mnt/c/code/test.js:3:0
at processTicksAndRejections (:55:76)
Is this related to trustedDependencies somehow?
Interested in this
This works for me in Bun
1.0.2:$ bun install @serialport/bindings-cppimport { autoDetect } from "@serialport/bindings-cpp" const Binding = autoDetect() console.log(await Binding.list()) // see a list correctly
I've tried this but it didn't work for me when running the script with bun. It will work if you run with node so it's the runtime that is failing (not the install). It's been a while but I suspect you accidentally ran it with node. I can't make bun work with any permutation of the serialport libraries.
@Jarred-Sumner in #5452 you mention "serialport no longer crashes" but it does, the same reproduction applies. It might be worth mentioning that I'm running this on modern MBPs, I haven't checked whether Linux / Windows would run.
Thanks for looking into it so far!
Got no luck too
Bun is just quitting on me using the latest win 11 build.
Hey @Jarred-Sumner - not to be entitled to a fix here but to understand where it stands: how does an issue like this rank on the priorities? Bun / Oven has a lot going on but according to the pinned priorities and docs an incompatibility with Node would be pretty high up. "drop in replacement" is mentioned many times on the website/docs.
So, that said, are we waiting for someone from the community to send in a PR or is the Bun team itself actively trying to close that gap? Because if it's the former I don't see how the stated goal is attainable, if it's the latter I don't understand why an issue like this is left to flounder.
Taking this issue as an example; I am invested enough to burn some time testing it out and providing feedback but if it doesn't work it's really not worth my time diving deep to fix a niche case to save myself a few seconds on a side-project. And if the "new shiny thing" doesn't work in that context I'm really not likely to spend my paid time on it either (where, granted, it might work because it's more standard use, but hitting this wall there will be much more painful). IMO not providing clarity here really hampers the potential adoption.
So, TLDR; is this issue likely to get more attention any time soon or should I just let it go?
Do you have any updates on this? I'm trying to use bun for a typescript project that works with some mechanical displays and all my code works except for the serial port library crashes it.
Nope. I stopped tracking whether this might be fixed passively and am not trying to fix it actively (see above).
debugger brought me to ; symbol stub for: uv_mutex_init
interested in this
I ended up using Python. It just works. And with UV the setup for venv is pretty easy.
I ended up using Python. It just works. And with UV the setup for venv is pretty easy.
Hard solution, you can just rely on using nodejs 🤣
yeah... I immediately missed Bun. Bun is a great package management tool, I should have just kept in JS world and used both Node and Bun but oh well. It's a 50 line server so maybe one day I'll rewrite it.
Hello @Jarred-Sumner, can we get an update on this? Thank you!
Updating to bun 1.2.8 getting this
const SerialPort = require('serialport').SerialPort;
const portPath = '/dev/cu.usbserial-0001';
const baudRate = 115200;
const port = new SerialPort({ path: portPath, baudRate: baudRate });
victor@Victors-MacBook-Pro-3 node_bitmap % bun .
============================================================
Bun v1.2.8 (adab0f64) macOS Silicon
macOS v15.1
CPU: neon fp aes crc32 atomics
Args: "bun" "."
Features: Bun.stderr(2) jsc transpiler_cache(4) process_dlopen(2) unsupported_uv_function
Builtins: "bun:main" "node:child_process" "node:events" "node:fs" "node:net" "node:os" "node:path" "node:stream" "node:tty" "node:util"
Elapsed: 1156ms | User: 87ms | Sys: 27ms
RSS: 58.87MB | Peak: 58.87MB | Commit: 1.05GB | Faults: 102
Bun encountered a crash when running a NAPI module that tried to call
the uv_default_loop libuv function.
Bun is actively working on supporting all libuv functions for POSIX
systems, please see this issue to track our progress:
https://github.com/oven-sh/bun/issues/4290
panic(main thread): unsupported uv function: uv_default_loop
oh no: Bun encountered a crash when running a NAPI module that tried to call
the uv_default_loop libuv function.
Bun is actively working on supporting all libuv functions for POSIX
systems, please see this issue to track our progress:
https://github.com/oven-sh/bun/issues/4290
https://bun.report/1.2.8/Ma1adab0f6ioIiggQ+mxsV2i0piB___+rh4hB_2nh23C2nh23C2nh23CA0eNorzSsuLSjILypJTVEoLVNIK81LLsnMz7NSKC2LT0lNSyzNKYnPyc8vAABJMg/9
zsh: trace trap bun .
victor@Victors-MacBook-Pro-3 node_bitmap %
I can tell it almost works as it sends a DTR and makes the serial peripheral to reboot (as intended)
It now can open without crashing but can't read data for whatever reason
asyncRead function in node_modules\@serialport\bindings-cpp\dist\load-bindings.js doesn't call callback
asyncReadfunction innode_modules\@serialport\bindings-cpp\dist\load-bindings.jsdoesn't call callback
asyncRead in the bindings, for darwin, would go down to unixRead is that right? Its all promisy in there, what callback are you looking at?
Don't know if this helps, but with latest version still have issue (not sure why it references other issue)
============================================================
Bun v1.2.15 (df017990) macOS Silicon
macOS v15.5
CPU: fp aes crc32 atomics
Args: "bun" "run" "index.ts"
Features: Bun.stderr(2) jsc tsconfig process_dlopen unsupported_uv_function
Builtins: "bun:main" "node:child_process" "node:events" "node:fs" "node:os" "node:path" "node:stream" "node:tty" "node:util"
Elapsed: 259ms | User: 29ms | Sys: 35ms
RSS: 40.11MB | Peak: 40.11MB | Commit: 1.07GB | Faults: 1280
Bun encountered a crash when running a NAPI module that tried to call
the uv_default_loop libuv function.
Bun is actively working on supporting all libuv functions for POSIX
systems, please see this issue to track our progress:
https://github.com/oven-sh/bun/issues/18546
panic(main thread): unsupported uv function: uv_default_loop
https://bun.report/1.2.15/Mr1df01799koQiggQmnwgLm/hue___m652hB_2o5i6C2o5i6C2o5i6CA0eNorzSsuLSjILypJTVEoLVNIK81LLsnMz7NSKC2LT0lNSyzNKYnPyc8vAABJMg/9
fish: Job 1, 'bun run index.ts' terminated by signal SIGTRAP (Trace or breakpoint trap)
asyncReadfunction innode_modules\@serialport\bindings-cpp\dist\load-bindings.jsdoesn't call callbackasyncRead in the bindings, for darwin, would go down to unixRead is that right? Its all promisy in there, what callback are you looking at?
I did go-to-definition and the file I linked is the binding before it gets promisified It doesn't seem to call callback, that's why promise never resolves, see https://github.com/oven-sh/bun/issues/19727
code
import { autoDetect } from '@serialport/bindings-cpp'
import { binding } from '@serialport/bindings-cpp/dist/serialport-bindings.js'
let auto = autoDetect()
const port1 = await auto.open({
path: 'COM6',
baudRate: 115200,
})
const port2 = await auto.open({
path: 'COM7',
baudRate: 115200,
})
binding.write(port1.fd, Buffer.from('Hello World'),
(...a) => console.log('write callback', a)) // never gets called in Bun
let buf = Buffer.alloc(1024)
binding.read(port2.fd, buf, 0, buf.length,
(...a) => console.log('read callback', a)) // never gets called in Bun
await new Promise(resolve => setTimeout(resolve, 10))
console.log(buf.toString()) // "Hello World"
any news on this?
I have a working fork of @serialport/bindings-cpp published, you may try it meanwhile
"overrides": {
"@serialport/bindings-cpp": "npm:@dimava/serialport-bindings-cpp@latest"
},
(do note it has binaries so you may want to patch it or build it from https://github.com/Dimava/node-serialport yourself)
fix commit: https://github.com/Dimava/node-serialport/commit/779d9dd48752555b20924c98e42251c2fd7f22be Bun issue: https://github.com/oven-sh/bun/issues/23192
right now this will ask sometimes for uv functions and can be tracked at https://github.com/oven-sh/bun/issues/18546