FATAL ERROR: Polling is not active

Hello,

How to support device hot unplug ? As soon as I use the startPoll() function, the application crashes with the error indicated in the title. The endpoint used in the code is an Interrupt IN endpoint of a Cdc Acm communication interface.

Code

const usb = require('usb')
const dev = usb.findByIds(0x05f9, 0x4204)

dev.open()

const _if = dev.interface(0)
if (_if.isKernelDriverActive()) _if.detachKernelDriver()
_if.claim()

const _ci = _if.endpoint(0x81)

_ci.startPoll()

_ci.on('data',  (...args) => console.log('data',  ...args))
_ci.on('end',   (...args) => console.log('end',   ...args))
_ci.on('error', (...args) => console.log('error', ...args))

Steps to Reproduce:

1. Plug device
2. Start program
3. Unplug device

Output

error [Error: LIBUSB_TRANSFER_NO_DEVICE] { errno: 5 }
error [Error: LIBUSB_TRANSFER_NO_DEVICE] { errno: 5 }
FATAL ERROR:  Polling is not active.
 1: 0xb09c10 node::Abort() [node]
 2: 0xa1c193 node::FatalError(char const*, char const*) [node]
 3: 0xa1c19c  [node]
 4: 0xad1abb napi_fatal_error [node]
 5: 0x7f28c8213006  [/home/[...]/node_modules/usb/prebuilds/linux-x64/node.napi.glibc.node]
 6: 0x7f28c822193b handleCompletion(Transfer*) [/home/[...]/node_modules/usb/prebuilds/linux-x64/node.napi.glibc.node]
 7: 0x7f28c821333d Napi::ThreadSafeFunction::CallJS(napi_env__*, napi_value__*, void*, void*) [/home/[...]/node_modules/usb/prebuilds/linux-x64/node.napi.glibc.node]
 8: 0xacfc61  [node]
 9: 0x1564956  [node]
10: 0x1577084  [node]
11: 0x15652a8 uv_run [node]
12: 0xa43dd5 node::SpinEventLoop(node::Environment*) [node]
13: 0xb4bdb6 node::NodeMainInstance::Run(node::EnvSerializeInfo const*) [node]
14: 0xacd592 node::Start(int, char**) [node]
15: 0x7f28cad542d0  [/usr/lib/libc.so.6]
16: 0x7f28cad5438a __libc_start_main [/usr/lib/libc.so.6]
17: 0xa4067c  [node]
Abandon (core dumped)

Additional Information

• Operating System: Archlinux
• Runtime v16.15.1
• Node USB Version 2.5.1

[thegecko]

@thegecko Can you please publish a release containing this fix?

@PatrickHallek this is now in the v2.6.0 release.

Apologies this took a while, I had to upgrade the CI pipeline

[strazzere]

The error leads to a fatal error because there is no one expecting it or catching it, so it bubbles up to the main thread. It is being raised via transferDone as a callback.

You are correct that something was wrong, though it is now fixed and the error would not be thrown anymore as this case can no longer occur.

Maybe this is just an opinion though, no idea what you are expecting the library to do. If it has another bug like this, then yes, it would throw an error erroneously again like it did. 🤷