I just upgraded my raspberry setup from the very old debian 10 to the latest debian 13.
With Debain 13 und deconz I was able to setup deconz again. However, I have my switch (whichs support was added in Tuya 4 Gang Remote TS0044 _TZ3000_j61x9rxn) and setup everything the same as before, but now the deconz service crashes once I click any button on the remote.
In jouralctl I only see a segmentation fault but I’ve no idea how to debug that further.
Nov 17 17:36:42 raspberrypi systemd[1]: deconz.service: Main process exited, code=killed, status=11/SEGV
Nov 17 17:36:42 raspberrypi systemd[1]: deconz.service: Failed with result 'signal'.
Nov 17 17:36:42 raspberrypi systemd[1]: deconz.service: Consumed 16.104s CPU time.
Nov 17 17:37:13 raspberrypi systemd[1]: deconz.service: Scheduled restart job, restart counter is at 5.
All other devices usually lights work just as before and I can control them through the phoscon web interface.
Any ideas on that?
Yes, on debian 10 everything was working. But through the upgrade I had to switch from the deconz to the deconz-qt6 package instead.
I think everything is the latest version. And no I’ve freshly set up everything, no custom files.
I’ve tried the core dump, but this didn’t work. Although I’ve created all files and restarted, no dump files were created.
Debugging showed me this
20:01:05:531 ZCL attribute report 0xF0D1B80000125DFE for cluster: 0x0006, ep: 0x01, frame control: 0x08, mfcode: 0x0000
Thread 1 "deCONZ" received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x6c22af84 in QArrayDataPointer<QString>::reallocateAndGrow(QArrayData::GrowthPosition, int, QArrayDataPointer<QString>*) () from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#1 0x6c469548 in DeRestPluginPrivate::triggerRule(Rule&) () from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#2 0x6c46a4f8 in DeRestPluginPrivate::handleRuleEvent(Event const&) () from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#3 0x75adf810 in ?? () from /lib/arm-linux-gnueabihf/libQt6Core.so.6
#4 0x6c20d140 in EventEmitter::eventNotify(Event const&) () from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#5 0x6c36db0c in EventEmitter::process() () from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#6 0x6c359868 in DeRestPluginPrivate::apsdeDataIndication(deCONZ::ApsDataIndication const&) () from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#7 0x75adfa20 in ?? () from /lib/arm-linux-gnueabihf/libQt6Core.so.6
#8 0x765af4e4 in deCONZ::ApsController::apsdeDataIndication(deCONZ::ApsDataIndication const&) () from /usr/bin/../lib/libdeCONZ.so.1
#9 0x000a7144 in zmController::onApsdeDataIndication(deCONZ::ApsDataIndication const&) ()
#10 0x000ce1c8 in zmMaster::processPacked(zm_command const*) ()
#11 0x000d00f8 in SER_Packet(unsigned char*, unsigned short) ()
#12 0x00045284 in protocol_receive ()
#13 0x000d0cec in SerialCom::readyRead() ()
#14 0x000d11e4 in SerialCom::processTh0Events() ()
#15 0x75ac6750 in QMetaCallEvent::placeMetaCall(QObject*) () from /lib/arm-linux-gnueabihf/libQt6Core.so.6
#16 0x75aceabc in QObject::event(QEvent*) () from /lib/arm-linux-gnueabihf/libQt6Core.so.6
#17 0x769f3eb0 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/arm-linux-gnueabihf/libQt6Widgets.so.6
#18 0x75a80714 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/arm-linux-gnueabihf/libQt6Core.so.6
#19 0x75a80a20 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/arm-linux-gnueabihf/libQt6Core.so.6
#20 0x75cbd660 in ?? () from /lib/arm-linux-gnueabihf/libQt6Core.so.6
#21 0x7518b148 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
As the stacktrace notes Qt6, it could be that this is really related to the newer unstable package.
I think it’s fine, I will share the link with others devs.
I don’t know this logs but if I m right the problem is from triggerRule() fonction, have you tried to remove the rule used ?
I have a similar problem.
Ubuntu 24.04
Deconz 2.32.1 headless
Conbee I firmware 26400500
When deconz is running for more than 30 or 45 minutes and I issue a command via Alexa, deconz crashes and restarts but with another exit code
Nov 23 19:08:02 nuc-desktop deCONZ[1205]: *** bit out of range 0 - FD_SETSIZE on fd_set ***: terminated
Nov 23 19:08:02 nuc-desktop systemd[1]: deconz.service: Main process exited, code=dumped, status=6/ABRT
Nov 23 19:08:02 nuc-desktop systemd[1]: deconz.service: Failed with result ‘core-dump’.
Nov 23 19:08:02 nuc-desktop systemd[1]: deconz.service: Consumed 2min 16.534s CPU time, 113.3M memory peak, 0B memory swap peak.
Nov 23 19:08:32 nuc-desktop systemd[1]: deconz.service: Scheduled restart job, restart counter is at 1.
Nov 23 19:08:32 nuc-desktop systemd[1]: Started deconz.service - deCONZ: ZigBee gateway – REST API.
Nov 23 19:08:32 nuc-desktop deCONZ[4483]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-nuc’
Nov 23 19:08:32 nuc-desktop deCONZ[4483]: libpng warning: iCCP: known incorrect sRGB profile
Nov 23 19:08:32 nuc-desktop deCONZ[4483]: This plugin does not support propagateSizeHints()
Nov 23 19:08:32 nuc-desktop deCONZ[4483]: This plugin does not support propagateSizeHints()
Nov 23 19:08:32 nuc-desktop deCONZ[4483]: This plugin does not support propagateSizeHints()
Nov 23 19:08:35 nuc-desktop deCONZ[4483]: This plugin does not support propagateSizeHints()
Previously I had another problem with the number of file descriptors apparently but my ulimit -n is 4096 now.
I should have mentioned I only use also a headless raspberry OS installation.
I access everything through the phoscon web portal. There is no other third party app involved I think.
Thanks for the report and gdb backtrace, not sure yet what is triggering this and it’s weird that it wasn’t a problem with qt5. But the triggerRule() place is a good hint. I’ll have a look.
@derferd1 I’ve found a unguarded access to the rules URL path, but am not sure if this is the problem which triggers the crash in your case. Could you please send me the zll.db database file for testing it in my setup? mpi@dresden-elektronik.de
@derferd1 thanks for the database. I’ve reworked the HTTP handler to catch a few blocking errors and ensure connections aren’t staying open forever, your case wasn’t affected by the rules but some bugs in the HTTP code.