segfault in getDriverStatistics() when connect() has not been called

nouknouk commented 3 years ago

Hi,

I face a segfault, apparently when using getDriverStatistics in my node application too early, when driver has not yet been connected.

To reproduce:

The driver has been initialized with a let driver = new OpenZwave(driverConfig);
At this point the driver.connect(...) has not been called yet.
Here, a call to let statistics = driver.getDriverStatistics(); makes a segfault.

To my mind:

this is not a big deal, a call to getDriverStatistics() makes no sense before a (successfull) call to connect(). I should (and I will) rather fix the logic in my application to prevent calls to driver before the call to connect
on the other hand:
- maybe the node-openzwave-shared should fail gracefully rather than causing a segfault.
- it is probably the same for several other functions.

The stack trace:

(grabbed with package segfault-handler)

PID 8530 received SIGSEGV for address: 0x40
/home/nouknouk/git/domonode/core/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x3341)[0x7f5a2df7c341]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f5a330903c0]
/usr/lib/x86_64-linux-gnu/libopenzwave.so.1.6(_ZN9OpenZWave7Manager9GetDriverEj+0x22)[0x7f5a2c41d152]
/usr/lib/x86_64-linux-gnu/libopenzwave.so.1.6(_ZN9OpenZWave7Manager19GetDriverStatisticsEjPNS_6Driver10DriverDataE+0xd)[0x7f5a2c42066d]
/home/nouknouk/git/domonode/plugins/zwave/node_modules/openzwave-shared/build/Release/openzwave_shared.node(_ZN3OZW3OZW19GetDriverStatisticsERKN3Nan20FunctionCallbackInfoIN2v85ValueEEE+0x64)[0x7f5a2c53f9a4]
/home/nouknouk/git/domonode/plugins/zwave/node_modules/openzwave-shared/build/Release/openzwave_shared.node(+0x1e2bc)[0x7f5a2c5342bc]
/usr/lib/x86_64-linux-gnu/libnode.so.64(_ZN2v88internal25FunctionCallbackArguments4CallEPNS0_15CallHandlerInfoE+0x1ba)[0x7f5a3387f2da]
/usr/lib/x86_64-linux-gnu/libnode.so.64(+0x7e17f0)[0x7f5a3387f7f0]
/usr/lib/x86_64-linux-gnu/libnode.so.64(+0x7e24ca)[0x7f5a338804ca]
[0x26d4602d452b]
Segmentation fault (core dumped)

My env:

x86 platforms (debian: 10.6, or debian based distributions: bullseye/sid),
custom build of (recent) liopenzwave 1.6.1548
latest version of openzwave-shared: 1.7.2 (was also the same with an earlier version of openzwave-shared).

Best regards,

And, btw, thanks again for this marvelous work :+1:

robertsLando commented 3 years ago

I suggest you to switch to https://github.com/zwave-js

nouknouk commented 3 years ago

Hi @robertsLando

I'm not sure an issue report is the right place to advertise for another project.

robertsLando commented 3 years ago

@nouknouk I'm the only one maintainer of this project right now (from about a year or so), mine is a suggestion, I will not maintain this project anymore.

If you wonder why: https://github.com/zwave-js/zwavejs2mqtt#why-zwavejs

nouknouk commented 3 years ago

Ok, my bad, I didn't understood that. Thanks for the clarification.

Maybe a statement in readme.md could help other développers understand this project reached its end of life ?

robertsLando commented 3 years ago

@nouknouk I know lot of users are still using ozw, so maybe one day someone will ask to maintain this, the switch to zwavejs is easy but there will be breaking changes for sure in the switch. IMO it is worth, but someone could don't agree with me

nouknouk commented 3 years ago

Yes, I'm one of them too.

openzwave is 'de facto' the reference in term of devices database, and even if the concept of 'pure js' library sounds very well to me at first sight, I have several reason for the moment to not switch to zwave-js:

device database isn't as large as ozw one, at least until a re-use of ozw db is fully in place
'pure js' concept remains partial as the lib is relying on node-serial
switching to a new lib involves time spent for adapting my software, for what actual gain ?
even if I love zwave (i have more than 80 devices), which is far better than zigbee to my mind, I'm afraid there are good chances that home automation ecosystem will rather move to zigbee in coming years (chip project, etc...).

In this context, the maintenance of zwave opensource software will become harder and harder because the number of développers interested will become low. Thus, focusing efforts on only one project (the biggest, ozw) makes more sense to my mind.

Just my little opinion of a lonesome coder of its little homemade app, probably far from the point of view of other apps (hass, jeedom, domoticz, gladys, etc...) used by a large community of users.

robertsLando commented 3 years ago

device database isn't as large as ozw one, at least until a re-use of ozw db is fully in place

This is not really a problem right now, there is an open PR for this waiting to be approved

'pure js' concept remains partial as the lib is relying on node-serial

node serial is just a really tiny layer compared to zwave-shared, now you can debug everything at low level with a nodejs debugger. Much easier to integrate and find what's going on

I'm afraid there are good chances that home automation ecosystem will rather move to zigbee in coming years

That's an opinion, I respect it but sincerly I dunno, could happen the opposite too :)

focusing efforts on only one project (the biggest, ozw) makes more sense to my mind.

If you check OZW development you will notice that the main (and only) author is disappiared from more then 4 months. Also if you open an issue or ask for support there even when he is active you will never get an answer (maybe after some months if you are lucky).

In this situation I cannot use OZW anymore, there are also some other reasons behind my choice but I think this is enought

OpenZWave / node-openzwave-shared