deCONZ crashes on startup

[kcdr]

deConz crashes on startup for every version greater than 2.05.15 (2.05.16 - 2.05.19).
The gui starts but instantly crashes when it connects to raspBee.
On the command Line only these Messages appear:

libEGL warning: DRI2: failed to authenticate
libpng warning: iCCP: known incorrect sRGB profile
08:11:45:357 failed to start websocket server on port 443. error: The bound address is already in use
08:11:45:359 failed to start websocket server on port 443. error: The bound address is already in use
08:11:58:018 UPNP socket not bound, state: 0
08:11:58:059 UPNP socket not bound, state: 0
Speicherzugriffsfehler

If I downgrade to 2.05.15 everything works again.

What can I do to give more information to you?

[manup]

Can you provide a coredump file then the crash happens?

[kcdr]

Does this help?

(gdb) backtrace
#0  0xb60b94e0 in QString::indexOf(QLatin1String, int, Qt::CaseSensitivity) const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#1  0xad3fc100 in DeRestPluginPrivate::checkFirmwareDevices() () from /usr/share/deCONZ/plugins/libde_rest_plugin.so_20180105
#2  0xad3fc980 in DeRestPluginPrivate::firmwareUpdateTimerFired() () from /usr/share/deCONZ/plugins/libde_rest_plugin.so_20180105
#3  0xad4ff87c in DeRestPluginPrivate::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/share/deCONZ/plugins/libde_rest_plugin.so_20180105
#4  0xb6242524 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#5  0xb624f5dc in QTimer::timerEvent(QTimerEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#6  0xb62432ec in QObject::event(QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#7  0xb6aa1298 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#8  0xb6aa94c4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#9  0x0214c418 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[manup]

There were changes in the method checkFirmwareDevices() in 2.05.16 but I don't see how they cause the crash.

Is this a vanilla installation or is the plugin compiled manually?

[kcdr]

Some time ago i compiled manually but later installed the deb package. Now 2.05.19
Some days ago I moved the deCONZ directory where the SQLite db resides and it did NOT crash. But I don’t see anything in the database which could cause the crash. Maybe one of the devices?
I have hue and ikea bulbs,
xiomi aquara, hue and ikea sensors
and a heiman plug

Yes, the changes only seem to concern conbee.

If it still helps, how can I send you the core dump?

[manup]

Does the version in Phoscon App also show 2.05.19? I'm not sure that the self compiled plugin is replaced by installing a new deCONZ version. A older compiled plugin might crash with current versions since they are not binary compatible.

You can drop the core dump here as zip file, but I already have the required function to look deeper into the issue (in the case your plugin is also the current version).

[kcdr]

Now when I empty .local/share/dresden-elektronik and try to start 2.05.19 it also crashes. Maybe I was mistaken that it did not crash some days ago...
How can I remove the manually compiled plugin?

[kcdr]

ls -la /usr/share/deCONZ/plugins
insgesamt 4448
drwxr-xr-x 2 pi pi    4096 Apr  5 23:17 .
drwxr-xr-x 9 pi pi    4096 Dez  9 09:46 ..
-rwxr-xr-x 1 pi pi 2198836 Apr  4 22:46 libde_rest_plugin.so
-rwxr-xr-x 1 pi pi 2090392 Jan  5 19:46 libde_rest_plugin.so_20180105
-rwxr-xr-x 1 pi pi   60036 Apr  4 22:46 libde_signal_plugin.so
-rwxr-xr-x 1 pi pi  191408 Apr  4 22:46 libstd_otau_plugin.so

[manup]

easiest is to delete the libde_rest_plugin* files and reinstall deCONZ, then there should be only the version from the package. deCONZ should be closed before doing this.

Also only one rest plugin should be in the /usr/share/deCONZ/plugins otherwise they might collide.

[kcdr]

That did the trick. I was not aware, that my backup (libde_rest_plugin.so_20180105) before installing the manually compiled plugin disturbed something.
Thank you very much 👍

[manup]

Cool, ya the plugin manager is very stubborn just iterates over all files in the directory and loads them :)

[jaal2001]

Gee! Someone should put THAT hint on the mainpage. I already considered about reinstalling the Raspberry image before I did found this post (after searching hours on google an the GIT issues here)

I mean: any command line user is trained to keep each old file as backup in a directory, so I just rename the old ones and keep them for backup purposes. That this could kill the whole process... never thought of that :)

[ebaauw]

I agree, it would make much more sense to load only lib*.so files from the plugins directory.

[manup]

I agree, it would make much more sense to load only lib*.so files from the plugins directory.

Agree added to the todo list, albeit the filtering code must be platform agnostic since Windows uses .dll and macOS .dylib.

[ebaauw]

macOS support ?!! Yes, please ;-)

[manup]

I wish there was more time to publish it :) deCONZ was already ported to macOS since 2015. I can't provide an ETA but I hope to get it into the automatic build process for packages and sd-card images — which is currently developed — at some time.

[marthoc]

@manup Hate to bring this issue back from the dead but is there any update on macOS support? Would love to not have to fire up Windows just for deCONZ...

[manup]

The plan is to bring the macOS support back together with the currently in progress rewrite of GCFFlasher. The current GCFFlasher has a pretty challenging code base and requires root privileges which brings some hard to fix platform problems (containers, vm, sudo and all the fun stuff).

Recently my Mac Book Pro (2011) died after an update. Now I need to decide on a replacement Mac for development :)

[justr1]

Any news about macOS support? Would be highly appreciated!