Segfaults during list() that crashes Node when encountering certain types of serial ports

[petertorelli]

Summary of Problem

(Please answer all 3)

• What are you trying to do? Query the serial ports.
• What happens? I get a segmentation fault when I plug in a particular device.
• What should have happened? I should have seen the new device added.

Code to Reproduce the Issue

const serialport = require("serialport");
serialport.list().then(currentPorts => {
	console.log(currentPorts);
});

Versions, Operating System and Hardware

• SerialPort@? 9.0.2
• Node.js v? 12.18.0
• Windows? Linux? Mac? Windows 10
• Hardware and chipset? Dialog DA16200 debug port

The DA16200 appears to create a SerialPort device that windows cannot assign to a COM port. Unfortunately, the node-serialport module segfaults with no indication of an error when it encounters this device: I can't even catch() it and recover, the process just ends. Even when I run with DEBUG=* I see no other messages. Windows Command Prompt prints nothing but Cygwin offers a clue:

Peter@CAPYBARA /cygdrive/c/Users/Peter/serialtmp
$ DEBUG=* node test-serial.js
  serialport/bindings loading WindowsBinding +0ms
  serialport/stream .list +0ms
Segmentation fault

Here is a picture of the orphan Serial Port appearing in Device Manager:

How do I enable better error handling so that my application doesn't segfault due to serialport?

[gniezen]

I can confirm that the same issue is happening for our users (at least 5) who have devices listed under "Ports (COM & LPT)" without a COM port number. In one specific instance, the device without COM port number is a Brother HL-L2350DW printer.

Serialport 9.0.2
Node 12.13.0
Windows 10

Ours is an Electron app, so when the segfault occurs the entire window just goes blank, without any error messages. It took us forever to figure out what was going on, so thank you so much for reporting this @petertorelli !

Any workarounds for this one, @reconbot ?

[petertorelli]

@gniezen FYI: I am also using this under an ElectronJS application, but it also happens under a plain NodeJS process as well.

[reconbot]

Well this doesn't happen for everyone, and without segfault information I can't tell you what's going on. I've seen a lot of issues with bad serial drivers responding to the registry queries poorly or just crashing but it could also be data in a format we don't expect. I'd need more info to make a diagnosis, if you look at the source you can see what registry paths we're looking at.

[petertorelli]

Hi @reconbot,
My apologies if my filing text sounds glib, I've been using serialport for 5 years and I appreciate the work you do keeping it healthy (I, too, support github projects and waking up to new Issues from strangers comes with a certain amount of dread b/c the response can potentially crater my schedule for the week!).

I'd like to provide more information, what would help? A core dump from the cygwin session? I don't debug windows very often (except inside VStudio) so tell me what you need and I'll get it.

Thanks,
Peter

[Ivanrodpar]

I have this issue too and I searched into the source code of this library and I think that the error comes with the call asyncList() function in the following file ~\ @serialport\bindings\lib\win32.js

[reconbot]

That is the function that does the listing, we'd need some c++ debugging to find out what it's doing wrong.

[reconbot]

@petertorelli

I'd like to provide more information, what would help? A core dump from the cygwin session? I don't debug windows very often (except inside VStudio) so tell me what you need and I'll get it.

I don't know much about debugging c++ on windows either, a core dump is probably the place to start. Building with debug mode (prebuild --debug) will probably give the most info, but I'm not actually sure what to do with a core dump from windows, but we can figure that out 😅

[petertorelli]

Hi @reconbot,

I finally carved out some time this weekend to dive back into this, and the hardware that routinely caused this problem...... no longer creates an un-associated COM port. Would you prefer I close this until I can reproduce the fail again and collect core-dump data, or should I leave it open for the other folks on the list?

Thanks,
Peter

[reconbot]

Let's leave it open. We can let stale bot close it if nobody else pipes up.

[gniezen]

I'm trying to think of the easiest way to have non-techie users send us details on this error. It should be able to be reproducible with the SerialPort List command-line tool, right? So I'm thinking to ask them to:

• Install Node.js
• Run npm install -g @serialport/list
• Run set set DEBUG=serialport/* & serialport-list

Could that get you what you need @reconbot ? Or does serialport-list not have debug mode turned on by default? Or is there a way for me to build serialport-list as a stand-alone binary with debug mode turned on?

[petertorelli]

@gniezen

Printing the NodeJS debug messages like that should help assuming they are used. Can you post that output?

This is a rather convoluted way to get a core dump, but do you have Cygwin installed? If you can run the serialport-list function and cause a segfault, it should create a *.stackdump file that prints the stack. Although it is kind of hard to align the addresses with the serialport code... I'm not quite sure how NodeJS talks to native bindings, or if there was a way to launch gdb after building with debug information we could back-trace directly from the stopped process.

Peter

[gniezen]

@petertorelli I'm sorry if I wasn't clear - I cannot reproduce it myself, but we've identified users of our software that want to help out to get this resolved. Unfortunately they don't have the technical know-how to set up Cygwin, so I was wondering how we can set up a minimal example that they could run to generate what is needed to investigate this further.

[reconbot]

I suppose you can put a bunch of print statements in the c++ code and compile it and run it. It's not a stack trace but it will absolutely point us the right direction.

[hisasan]

Hi there,
Isn't there something wrong with the isCom variable in the EIO_List function of serialport_win.cpp?
isCom is not initialized in the while loop.
When there is no COM port, isCom does not become false.

[gniezen]

This appears to be related to #1830, as we've also had a report of a Brother printer not being assigned a COM port by Windows.

[petertorelli]

@hisasan
Good point. If it is set true in a previous loop, and SetupDiOpenDevRegKey fails, it remains true. Hmm...

Unfortunately I do not have a reliable test case device that fails to obtain a COM port from windows. @gniezen do you have access to the bad printer for debug?

[gniezen]

@petertorelli No, I've been trying to create a test build with an initialized isCom that I can ship to an affected user, but no luck yet.

[reconbot]

You can stick a bunch of fprintf(stdout, "starting list!\n"); in EIO_List and see where it dies.

[GazHank]

Has anyone managed to replicate this issue without access to the particular hardware in question?

I've tried in mapping, remapping or generally messing up the com port mapping in windows and I just can't seem to replicate the issue. I have a suspicion that we could change the windows APIs that we use to bypass this issue, but without being able to replicate the issue I don't know how much progress can be made

[petertorelli]

@GazHank,
I think that's the reason why this issue is stalled. How about we close it until someone encounters a way to reproduce it?

[caffeinatedbits]

@petertorelli @GazHank @hisasan see #2325

Thank you @hisasan for #2155 (comment) and @petertorelli for #2155 (comment) – you guys hit the nail on the head!