SerialPort Bindings Version

12.0.1

Node Version

v21.2.0

Electron Version

No response

Platform

Linux opi5b 5.10.110-rockchip-rk3588 #1.0.2 SMP Thu Apr 13 16:55:55 CST 2023 aarch64 GNU/Linux

Architecture

arm64

Hardware or chipset of serialport

16550A

What steps will reproduce the bug?

Simply opening /dev/ttyS9 on this hardware using the code below:

const debug=require('debug')
debug.enable('*')
const { SerialPort } = require('serialport')
const port = new SerialPort({
path: '/dev/ttyS9',
baudRate: 57600,
})

port.on('data', function (data) {
console.log('Data:', data)
})

What happens?

initial unixRead() that is called on port open is trapped into recursive call to itself, because readAsync() always returns { bytesRead:0 }, see https://github.com/serialport/bindings-cpp/blob/39fd4be0904434a0ec72ee88e04d54bfa1645667/lib/unix-read.ts#L41C1-L44C1

The debug log confirms the said:

2023-11-26T14:55:04.624Z serialport/bindings-cpp loading LinuxBinding
2023-11-26T14:55:04.626Z serialport/stream opening path: /dev/ttyS9
2023-11-26T14:55:04.626Z serialport/bindings-cpp open
2023-11-26T14:55:04.628Z serialport/stream _read queueing _read for after open
2023-11-26T14:55:04.629Z serialport/bindings-cpp/poller Creating poller
2023-11-26T14:55:04.629Z serialport/stream opened path: /dev/ttyS9
2023-11-26T14:55:04.629Z serialport/stream _read reading { start: 0, toRead: 65536 }
2023-11-26T14:55:04.631Z serialport/bindings-cpp read
2023-11-26T14:55:04.631Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.632Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.632Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.632Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.632Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read

... and continues indefinitely

What should have happened?

unixRead() should return normally or throw

Additional information

I realize this is probably buggy hardware, but is it possible to work around this by implementing a simple recursion counter and throw if recursion deph exceeds 10 or so, for example?

We can't seem to build from source with the default github runner anymore on windows-latest. We've pinned back to windows-2019

references

• release notes actions/runner-images#4856
• failed build https://github.com/serialport/bindings-cpp/runs/5342599111?check_suite_focus=true

SerialPort Bindings Version

v10.5.0/v11.0.1

Node Version

v12.22.12/v14.15.4/v18.14.2

Electron Version

No response

Platform

Linux 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64 GNU/Linux

Architecture

x64

Hardware or chipset of serialport

Arduino

What steps will reproduce the bug?

SerialPort = require('serialport').SerialPort;
SerialPort.binding.list().then(console.log)

What happens?

  [
    {
      path: '/dev/ttyACM1',
      manufacturer: undefined,
      serialNumber: undefined,
      pnpId: undefined,
      locationId: undefined,
      vendorId: '8086',
      productId: 'a12f'
    },
    {
      path: '/dev/ttyACM0',
      manufacturer: undefined,
      serialNumber: undefined,
      pnpId: undefined,
      locationId: undefined,
      vendorId: '8086',
      productId: 'a12f'
    }
  ]

What should have happened?

  [
    {
      path: '/dev/ttyACM0',
      manufacturer: 'Arduino\x20\x28www.arduino.cc\x29',
      serialNumber: '952383433343518101E1',
      pnpId: '/dev/serial/by-path/pci-0000:00:14.0-usb-0:2:1.0',
      locationId: undefined,
      vendorId: '8086',
      productId: 'a12f'
    },
    {
      path: '/dev/ttyACM1',
      manufacturer: 'Arduino\x20\x28www.arduino.cc\x29',
      serialNumber: '751313138323515011A0',
      pnpId: '/dev/serial/by-path/pci-0000:00:14.0-usb-0:11:1.0',
      locationId: undefined,
      vendorId: '8086',
      productId: 'a12f'
    }
  ]

Additional information

$ udevadm info -n /dev/ttyACM1
P: /devices/pci0000:00/0000:00:14.0/usb1/1-11/1-11:1.0/tty/ttyACM1
N: ttyACM1
L: 0
S: serial/by-path/pci-0000:00:14.0-usb-0:11:1.0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-11/1-11:1.0/tty/ttyACM1
E: DEVNAME=/dev/ttyACM1
E: MAJOR=166
E: MINOR=1
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=437935568319
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0xa12f
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
E: ID_PCI_INTERFACE_FROM_DATABASE=XHCI
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller
E: ID_PATH=pci-0000:00:14.0-usb-0:11:1.0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_11_1_0
E: ID_USB_MODEL=0043
E: ID_USB_MODEL_ENC=0043
E: ID_USB_MODEL_ID=0043
E: ID_USB_SERIAL=Arduino__www.arduino.cc__0043_751313138323515011A0
E: ID_USB_SERIAL_SHORT=751313138323515011A0
E: ID_USB_VENDOR=Arduino__www.arduino.cc_
E: ID_USB_VENDOR_ENC=Arduino\x20\x28www.arduino.cc\x29
E: ID_USB_VENDOR_ID=2341
E: ID_USB_REVISION=0001
E: ID_USB_TYPE=generic
E: ID_USB_INTERFACES=:020201:0a0000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=cdc_acm
E: ID_MM_CANDIDATE=1
E: ID_FOR_SEAT=tty-pci-0000_00_14_0-usb-0_11_1_0
E: DEVLINKS=/dev/serial/by-path/pci-0000:00:14.0-usb-0:11:1.0
E: TAGS=:systemd:seat:uaccess:
E: CURRENT_TAGS=:systemd:seat:uaccess:

$ udevadm info -n /dev/ttyACM0
P: /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/tty/ttyACM0
N: ttyACM0
L: 0
S: serial/by-path/pci-0000:00:14.0-usb-0:2:1.0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/tty/ttyACM0
E: DEVNAME=/dev/ttyACM0
E: MAJOR=166
E: MINOR=0
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=17488184319
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0xa12f
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
E: ID_PCI_INTERFACE_FROM_DATABASE=XHCI
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller
E: ID_PATH=pci-0000:00:14.0-usb-0:2:1.0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_2_1_0
E: ID_USB_MODEL=0043
E: ID_USB_MODEL_ENC=0043
E: ID_USB_MODEL_ID=0043
E: ID_USB_SERIAL=Arduino__www.arduino.cc__0043_952383433343518101E1
E: ID_USB_SERIAL_SHORT=952383433343518101E1
E: ID_USB_VENDOR=Arduino__www.arduino.cc_
E: ID_USB_VENDOR_ENC=Arduino\x20\x28www.arduino.cc\x29
E: ID_USB_VENDOR_ID=2341
E: ID_USB_REVISION=0001
E: ID_USB_TYPE=generic
E: ID_USB_INTERFACES=:020201:0a0000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=cdc_acm
E: ID_MM_CANDIDATE=1
E: ID_FOR_SEAT=tty-pci-0000_00_14_0-usb-0_2_1_0
E: DEVLINKS=/dev/serial/by-path/pci-0000:00:14.0-usb-0:2:1.0
E: TAGS=:seat:uaccess:systemd:
E: CURRENT_TAGS=:seat:uaccess:systemd:

The first reply here is quite useful: https://www.reddit.com/r/debian/comments/1331wlr/devserialbyid_suddenly_missing/

SerialPort Bindings Version

10.7.0

Node Version

16.5.0

Electron Version

No response

Platform

Microsoft Windows NT 10.0.22000.0 x64

Architecture

No response

Hardware or chipset of serialport

No response

What steps will reproduce the bug?

Simply running SerialPort.list() on a Windows system with the language set to one that has accents (diacritics). The list of ports will contain � characters in ports' properties instead of the accents.

What happens?

Ports' list parameters encoding is broken for Unicode accents:

What should have happened?

The ports list should properly encode all port parameters:

Additional information

Seems like the serialport_win implementation uses chars, which do not encode Unicode characters on Windows. Instead, the implementation should use wchar_ts, which is the preferred way to store such data on Windows, substitute std::string with std::wstring and use the Napi::String::New(Env, const char16_t*) (since wchar_t is essentially a 16-bit wide Unicode character) signature over Napi::String::New(Env, const char*) when passing these values to interpreted code.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore(deps): update dependency prebuildify-cross to v5.1.0
• fix(deps): update dependency node-addon-api to v7.1.0
• chore(deps): update codecov/codecov-action action to v4
• chore(deps): update dependency chai to v5
• chore(deps): update dependency eslint to v9
• chore(deps): update dependency prebuildify to v6
• chore(deps): update dependency sinon to v18
• chore(deps): update github artifact actions to v4 (major) (actions/download-artifact, actions/upload-artifact)
• chore(deps): update typescript-eslint monorepo to v7 (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• fix(deps): update dependency node-addon-api to v8
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency @types/chai-subset to v1.3.5
• chore(deps): update dependency @types/debug to v4.1.12
• chore(deps): update dependency node-gyp to v9.4.1
• chore(deps): update dependency semantic-release to v21.1.2
• fix(deps): update dependency @serialport/parser-readline to v11.0.1
• chore(deps): update dependency chai to v4.4.1 (chai, @types/chai)
• chore(deps): update dependency esbuild to v0.21.3
• chore(deps): update dependency eslint to v8.57.0
• chore(deps): update dependency mocha to v10.4.0 (mocha, @types/mocha)
• chore(deps): update dependency node to v18.20.2 (node, @types/node)
• chore(deps): update dependency node-abi to v3.62.0
• chore(deps): update dependency typescript to v5.4.5
• chore(deps): update typescript-eslint monorepo to v6.21.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• fix(deps): update dependency node-gyp-build to v4.8.1
• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update dependency node to v20 (node, @types/node)
• chore(deps): update dependency node-gyp to v10
• chore(deps): update dependency semantic-release to v23
• fix(deps): update dependency @serialport/parser-readline to v12
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

SerialPort Bindings Version

latest

Node Version

No response

Electron Version

No response

Platform

No response

Architecture

No response

Hardware or chipset of serialport

No response

What steps will reproduce the bug?

N/A

What happens?

N/A

What should have happened?

N/A

Additional information

This module is not correctly node version safe. While it does use Node-API, it is also including uv.h which is listed as not being included in the stability guarantees https://nodejs.org/api/n-api.html#implications-of-abi-stability.

This is likely not a problem for a while, but there is some risk of builds not being compatible depending on the libuv changes between node versions

SerialPort Bindings Version

12.0.1

Node Version

18.20.2

Platform

Microsoft Windows NT 10.0.22631.0 x64

Architecture

x64

What steps will reproduce the bug?

$Env:npm_config_arch="arm" ; $Env:npm_config_platform="linux" ; yarn install --inline-builds

sqlite3 or canvas in package.json

What happens?

This file contains the result of Yarn building a package (@serialport/bindings-cpp@npm:12.0.1)

Script name: install

node:internal/child_process:414
    throw errnoException(err, 'spawn');
    ^

Error: spawn EINVAL
    at ChildProcess.spawn (node:internal/child_process:414:11)
    at Object.spawn (node:child_process:761:9)
    at build (G:\Roboqbo\qbo-5\server\node_modules\@serialport\bindings-cpp\node_modules\node-gyp-build\bin.js:29:8)
    at preinstall (G:\Roboqbo\qbo-5\server\node_modules\@serialport\bindings-cpp\node_modules\node-gyp-build\bin.js:38:32)
    at G:\Roboqbo\qbo-5\server\node_modules\@serialport\bindings-cpp\node_modules\node-gyp-build\bin.js:11:7
    at ChildProcess.exithandler (node:child_process:430:5)
    at ChildProcess.emit (node:events:517:28)
    at maybeClose (node:internal/child_process:1098:16)
    at Socket.<anonymous> (node:internal/child_process:450:11)
    at Socket.emit (node:events:517:28) {
  errno: -4071,
  code: 'EINVAL',
  syscall: 'spawn'
}

Node.js v18.20.2

Additional information

Look at this: nodejs/node#52681

SerialPort Bindings Version

10.7.0

Node Version

16.15.0

Electron Version

19.0.12

Platform

Linux raspberrypi 5.15.61-v7l+ #1579 SMP Fri Aug 26 11:13:03 BST 2022 armv7l GNU/Linux

Architecture

ARM

Hardware or chipset of serialport

Etc

What steps will reproduce the bug?

Run a VSCode extension with serialport on a raspberry pi with the 32-bit Raspberry Pi OS.

What happens?

At runtime node-gyp-build gets "default" as the value for "armv". But actually the armv on a 32-bit Raspberry Pi 4b is 7. So the result is that it compares 6 and 7 (the two prebuild arm version) agains "default" which will of course fail! The reason for that is following line https://github.com/prebuild/node-gyp-build/blob/0078d7884dfeb0e708477b3e20bfc4f520c1e2f8/index.js#L16

var vars = (process.config && process.config.variables) || {}
.
.
.
var armv = process.env.ARM_VERSION || (arch === 'arm64' ? '8' : vars.arm_version) || ''

What should have happened?

That the arm version is correctly detected so it can detect which prebuild is the right.

Additional information

You either have to set process.env.ARM_VERSION or ensure that process.config.variables.arm_version get overwritten to "default".

SerialPort Bindings Version

10.8.0

Node Version

v16.14.2

Electron Version

No response

Platform

Darwin 18.5.0 /RELEASE_X86_64 x86_64

Architecture

No response

Hardware or chipset of serialport

No response

What steps will reproduce the bug?

I tried to build my own build of bindings cpp with:

npm run rebuild

What happens?

Fatal error during build fatal error: too many errors emitted, stopping now

gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
  CXX(target) Release/obj.target/bindings/src/serialport.o
In file included from ../src/serialport.cpp:1:
In file included from ../src/./serialport.h:11:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/stdio.h:108:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/stdio.h:64:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:68:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:784:2: error:
      Unsupported architecture
#error Unsupported architecture

/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:784:2 :

/*
 * Architecture validation for current SDK
 */
#if !defined(__sys_cdefs_arch_unknown__) && defined(__i386__)
#elif !defined(__sys_cdefs_arch_unknown__) && defined(__x86_64__)
#else
#error Unsupported architecture // <=== line 784
#endif

It seems that miss some flag.

What should have happened?

Build should be done

Additional information

I was able to fix it and correctly build, when I change 'OTHER_CFLAGS' to 'CFLAGS' and I do the same for OTHER_LDFLAGS. I was asking my self it is really 'OTHER_CFLAGS' that you want to do ?

💥 Proposal

What feature you'd like to see

I need to control dcb.fOutxCtsFlow (https://github.com/serialport/bindings-cpp/blob/main/src/serialport_win.cpp#L160) value with flag from serial port configuration. Now it's linked directly to rtscts configuration, so it can't be set to false in any way.

Pitch

I have some kind of very exotic serial device that requires dcb.fOutxCtsFlow to be set to false while dcb.fRtsControl is set to RTS_CONTROL_ENABLE. There are the only DCB parameters that works with my device:

dcb.BaudRate = CBR_9600;
dcb.ByteSize = 8;
dcb.StopBits = TWOSTOPBITS;

dcb.Parity = EVENPARITY;
dcb.fDtrControl = DTR_CONTROL_ENABLE;
dcb.fRtsControl = RTS_CONTROL_ENABLE;

dcb.EofChar = 0x0;
dcb.ErrorChar = 0x0;
    
dcb.fErrorChar = 0x0;
dcb.EvtChar = 0x0;
    
dcb.XonChar = 0x11;
dcb.XoffChar = 0x13;

dcb.fOutxCtsFlow = FALSE; // Can't be set to FALSE using serialport library
dcb.fOutX = FALSE;
dcb.XonLim = 2048;
dcb.XoffLim = 512;

So I'm getting the following packet when setting up serial communication:

IOCTL_SERIAL_SET_HANDFLOW: Set handshake information
  ControlHandShake=1
  FlowReplace=64
  XonLimit=2048
  XoffLimit=512

Is it possible to change the Node dependency from 12.17.0 to 12.14.1?

Currently we can't get the bindings to work in Atom because Atom bundles with 12.14.1. We can get it working by running npm install manually in the package folder, but that's not something we can ask our users to do.

Half of the prebuildify-cross images use python 2 prebuild/docker-images#15 so we can't build on them. I'm not sure why however.

SerialPort Bindings Version

11.0.3 & 12.0.1

Node Version

16.20.1

Electron Version

No response

Platform

Alpine Docker container on Rasperry Pi Buster

Architecture

ARM

Hardware or chipset of serialport

NA

What steps will reproduce the bug?

• clone this repo (Docker file and minimal testcase) https://github.com/hardillb/node-serial-docker-test
• build docker container on Arm Linux (e.g. raspberry pi) docker build -t node-serial-docker-test
• create virtual serial port with socat sudo socat -d -d pty,rawer,echo=0,link=/dev/ttyUSB0 pty,rawer,echo=0,link=/dev/ttyUSB1
• start a shell in the container with docker run -v /dev:/dev -it --entrypoint /bin/sh --ulimit core=-1 --privileged node-serial-docker-test
• run node index.js will generate core file

Sample core file provided

core.gz

What happens?

Crashes on startup

What should have happened?

Not crash trying to open a port

Additional information

running npm run rebuild in the node_modules/@serialport/bindings-cpp fixes the problem which implies it's the pre-built binaries that are the problem.

re: node-red/node-red-nodes#1027

We need to run on 11.0.x as we need to maintain NodeJS 14 support (for a little while longer)

📚 Documentation

I couldn't find any info if this is compatible with the Memory Cage of Electron 21+. Is it? I just don't want to risk that it works on my machine and users of my application are doing something differently and it crashes for them.

By the way, when searching for "electron" in the Docs, it redirects to the 9.x.x versions of the documentation, which is a bit confusing. I just don't have time right now to open a separate issue for that.

Have you read the Contributing Guidelines on docs?

Yes