pre-built binaries crashing on Alpine ARM 32bit

[hardillb]

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)

[GazHank]

hi @hardillb are you getting accidentally updated to a version that is incompatible with your version of node?

As far as I understand you should be able to continue with the older version of the package until you are able to update node from version 14. Other than losing support I don't think there are any known issues which should impact you in the short term if you need to stick on node 14 for a short while

[hardillb]

@GazHank

I'm testing (and the supplied test case uses) NodeJS 16 and installing serialport v11.0.1 (bindings-cpp v11.0.3) which was tagged on github 3 days ago, that version should be good, but I've just tested with version v12.0.0 (bindings-cpp v12.0.1) tagged at the same time and it fails the same way

For v12.0.0 package.json says

"engines": {
    "node": ">=16.0.0"
  },

for v11.0.1

"engines": {
    "node": ">=12.0.0"
  },

So both versions should work on Node 16

[GazHank]

doh! <I've only been able to review this on my mobile, so sorry if I'm mistaken>

The alpine binaries are built using prebuildify (which only uses LTS releases), so it looks like any binaries will drop support soon as a node version leaves LTS, even if the underlying code is still compatible and can be build from source.

@hardillb I think your analysis is correct and it is an issue with the pre-build binaries. For now you can either pin an earlier binary version, or build from source

@reconbot keen to get your thoughts... it looks like holding out support for older versions of nodejs is getting harder, perhaps we need to pencil in a release for around 2023-09-11 to drop node 16, to avoid similar issues?

[hardillb]

One other note, the current system doesn't appear to support npm rebuild which should normally rebuild any binary components, where as for @serialport/bindings-cpp you have to run npm run rebuild actually in it's directory (where as npm rebuild can do all modules in the node_modules dir). This is a break from expected normal behaviour for nodes with binary components.

[alexojegu]

Same trouble here.

Hi @GazHank, from prebuildify usage:

It's possible to use custom images with e.g. -i my-namespace/my-image.

And for ARM they are using images from dockcross where I can see dockcross/linux-armv7l-musl. Could this image be added to the GitHub Actions workflow?

If I understood it correctly it would simply change:

- name: linux-arm
     os: ubuntu-latest
     command: prebuildify-cross
     args: -i linux-arm64-lts -i linux-armv7 -i linux-armv6

By:

- name: linux-arm
     os: ubuntu-latest
     command: prebuildify-cross
     args: -i linux-arm64-lts -i linux-armv7 -i linux-armv6 -i dockcross/linux-armv7l-musl

For me this would be enough, but there is also an image for armv6-musl if anyone might be interested.

PS: Okay, I guess based on that image you would have to make a Dockerfile with the configuration used by prebuildify.

[SamuelToh]

@hardillb your workaround works for me.

I have a similar setup doing,

• node 16,
• pi on arm architecture
• running Buster linux
• application sits in an alphine docker container.
• my application uses the 12.0.0 package and it was seg faulting on me during init/port open stage.

running npm run rebuild seems to work for me!

@hardillb how did you found out? Keen to learn.

[alexojegu]

#166 should fix it, but I guess we need to wait for the next release.