Crash at startup when using shared (main) interpreter and more than 1 instance of the Z4D plugin

[pipiche38]

With recent Version of domoticz and if shared=true in plugin.py definition we have a systematic crash when launching 2 or more instances of the plugin 'at the same tim'.
It looks like the problem do not occured, when creating the Hardware and so the instances are not started at the same time

domoticz    | 2026-03-29 16:15:59.450  Debug: ZNP: (Zigate) using shared (main) interpreter (0x7ffec836fee8).
domoticz    | 2026-03-29 16:15:59.452  Debug: EZSP: (Zigate) using shared (main) interpreter (0x7ffec836fee8).
domoticz    | 2026-03-29 16:15:59.474  Error: Domoticz(pid:1, tid:39('EZSP')) received fatal signal 11 (Segmentation fault)
domoticz    | 2026-03-29 16:15:59.474  Error: siginfo address=(nil), address=0x7ffec7e84064
domoticz    | 2026-03-29 16:15:59.479  Error: Failed to start gdb, will use backtrace() for printing stack frame
domoticz    |
domoticz    | 2026-03-29 16:15:59.482  Error: #0  /opt/domoticz/domoticz :  + 0x37e6e4 [0x5555f4b4e6e4]
domoticz    | 2026-03-29 16:15:59.482  Error: #1  /opt/domoticz/domoticz : signal_handler(int, siginfo_t*, void*) + 0x23c [0x5555f4b4f130]
domoticz    | 2026-03-29 16:15:59.482  Error: #2  linux-vdso.so.1 : __kernel_rt_sigreturn + 0 [0x7ffec9bcc820]
domoticz    | 2026-03-29 16:15:59.482  Error: #3  /lib/aarch64-linux-gnu/libpython3.11.so :  + 0x28247c [0x7ffec7ea247c]
domoticz    | 2026-03-29 16:15:59.482  Error: #4  /lib/aarch64-linux-gnu/libpython3.11.so :  + 0x264064 [0x7ffec7e84064]
domoticz    | 2026-03-29 16:15:59.482  Error: #5  /lib/aarch64-linux-gnu/libpython3.11.so :  + 0x17a868 [0x7ffec7d9a868]
domoticz    | 2026-03-29 16:15:59.482  Error: #6  /lib/aarch64-linux-gnu/libpython3.11.so : _PyEval_EvalFrameDefault + 0x5178 [0x7ffec7d2adf8]
domoticz    | 2026-03-29 16:15:59.482  Error: #7  /lib/aarch64-linux-gnu/libpython3.11.so :  + 0x2640fc [0x7ffec7e840fc]
domoticz    | 2026-03-29 16:15:59.482  Error: #8  /lib/aarch64-linux-gnu/libpython3.11.so :  + 0x1796b4 [0x7ffec7d996b4]
domoticz    | 2026-03-29 16:15:59.482  Error: #9  /lib/aarch64-linux-gnu/libpython3.11.so : PyObject_CallMethodObjArgs + 0xa4 [0x7ffec7d998c8]
domoticz    | 2026-03-29 16:15:59.482  Error: #10 /lib/aarch64-linux-gnu/libpython3.11.so : PyImport_ImportModuleLevelObject + 0x344 [0x7ffec7eaefb4]
domoticz    | 2026-03-29 16:15:59.482  Error: #11 /lib/aarch64-linux-gnu/libpython3.11.so :  + 0x25b05c [0x7ffec7e7b05c]
domoticz    | 2026-03-29 16:15:59.482  Error: #12 /lib/aarch64-linux-gnu/libpython3.11.so :  + 0x1c6324 [0x7ffec7de6324]
domoticz    | 2026-03-29 16:15:59.482  Error: #13 /lib/aarch64-linux-gnu/libpython3.11.so :  + 0x17891c [0x7ffec7d9891c]
domoticz    | 2026-03-29 16:15:59.482  Error: #14 /lib/aarch64-linux-gnu/libpython3.11.so : PyObject_CallFunction + 0x80 [0x7ffec7d98b50]
domoticz    | 2026-03-29 16:15:59.482  Error: #15 /lib/aarch64-linux-gnu/libpython3.11.so : PyImport_Import + 0xb4 [0x7ffec7eaf874]
domoticz    | 2026-03-29 16:15:59.482  Error: #16 /lib/aarch64-linux-gnu/libpython3.11.so : PyImport_ImportModule + 0x1c [0x7ffec7eafa6c]
domoticz    | 2026-03-29 16:15:59.482  Error: #17 /opt/domoticz/domoticz : Plugins::CPlugin::Initialise() + 0x518 [0x5555f504f5ec]
domoticz    | 2026-03-29 16:15:59.482  Error: #18 /opt/domoticz/domoticz : Plugins::CPlugin::Do_Work() + 0x1ec [0x5555f5051d4c]
domoticz    | 2026-03-29 16:15:59.482  Error: #19 /opt/domoticz/domoticz :  + 0xb47bdc [0x5555f5317bdc]
domoticz    | 2026-03-29 16:15:59.482  Error: #20 /lib/aarch64-linux-gnu/libc.so.6 :  + 0x82030 [0x7ffec9182030]
domoticz    | 2026-03-29 16:15:59.482  Error: #21 /lib/aarch64-linux-gnu/libc.so.6 :  + 0xebf1c [0x7ffec91ebf1c]

[pipiche38]

Domoticz constraint is simpler — you cannot safely run two instances of the same plugin key in a shared interpreter. The real solution is to rename the second instance with a different plugin key, or use a single instance that monitors multiple things.

[pipiche38]

Can reproduce the issue with 2 instances of https://github.com/pipiche38/Monitoring-Loop-Latency
with a Domoticz 2026.1 or above version, by using the shared="true" mode, which is required if you have to import python 3 modules which are cpython

if you change

<plugin key="AsyncLoopMonitor"
        name="Async Loop Latency Monitor"
        author="pipiche38"
        version="1.0.0"
        externallink="https://github.com/pipiche38/Monitoring-Loop-Latency"
        wikilink=""
        description="Monitors asyncio event-loop latency to detect GIL contention across Domoticz plugins.">
    <params>

by

<plugin key="AsyncLoopMonitor"
        name="Async Loop Latency Monitor"
        author="pipiche38"
        version="1.0.0"
        externallink="https://github.com/pipiche38/Monitoring-Loop-Latency"
        wikilink=""
        shared="true"
        description="Monitors asyncio event-loop latency to detect GIL contention across Domoticz plugins.">
    <params>

cc: @badzz

[claude]

Claude finished @zigbeefordomoticz's task in 43s —— View job

---

Triage: Issue #1928 — Crash with shared interpreter + multiple instances

• Gather context
• Analyze issue

---

Classification: Infrastructure/compatibility — race condition in Python's import system, not a Z4D logic bug.

Good news: The current plugin.py line 14 already has shared="false", so this crash does not affect Z4D users by default.

Likely cause: The segfault at PyImport_ImportModuleLevelObject → CPlugin::Initialise() is a classic import-lock race. When two plugin instances share one Python interpreter and both start simultaneously, both threads execute the massive top-level import block in plugin.py (lines 119–190, 40+ imports) at the same time. Python 3.11's per-module import locks can deadlock or corrupt state when two threads race to initialize overlapping module graphs, resulting in SIGSEGV.

Most relevant file: plugin.py:14 (shared="false") and plugin.py:119–190 (the concurrent import block).

Assessment: This is fundamentally a Domoticz constraint, as the author noted — two instances of the same plugin key cannot safely share one interpreter. The Z4D plugin is already protected by shared="false".

Missing info / open questions:

1. Is there a concrete scenario where Z4D needs shared="true"? (The author mentions CPython module imports require it in newer Domoticz.)
2. If yes, the only safe mitigation at the plugin level would be to serialize imports with a process-level threading.Lock in plugin.py — but this is fragile and depends on Domoticz's threading model.

Recommendation: Keep shared="false" in Z4D and document why changing it to true is unsupported. No code change needed unless there is a confirmed requirement for shared="true".