Hallo zusammen,
ich habe seit längerem das Problem, dass mir Symcon abstürzt, sobald die Kachelvisualisierung mit Kamerastreams offen ist. Heute Morgen habe ich das mal systematisch gemessen und bin auf einen Stacktrace gekommen, der die Stelle recht eindeutig benennt.
System: Symcon 9.0, Rev. f2880badc0d6f6c75e5c235662467bac7b94b4f8, Build 06/15/26, Professional, Ubuntu 24.04 in einer Proxmox-VM
Aufbau: 4 RTSP-Streams als Medien-Objekte in der Kachelvisu, davon 2 von derselben Kamera. Zugriff lokal im LAN, Chrome.
Das Verhalten: Nach einiger Zeit friert ein Stream ein, danach hängen die übrigen Kacheln bei „Wird verbunden (ICE)“, und irgendwann ist der Dienst weg. Heute Morgen drei Abstürze innerhalb von 40 Minuten:
Sun 2026-09-13 07:17:18 CEST PID 17391 SIGSEGV /usr/bin/symcon
Sun 2026-09-13 07:28:13 CEST PID 17604 SIGSEGV /usr/bin/symcon
Sun 2026-09-13 07:55:01 CEST PID 18914 SIGSEGV /usr/bin/symcon
Das Entscheidende: Dieselben vier Streams laufen im WebFront dauerhaft stabil. Nur mit der Kachelvisu stürzt es ab. Das Symptom kenne ich schon aus 8.x, damals allerdings ohne Trace.
Funktionsnamen aus dem Stacktrace des abstürzenden Threads (coredumpctl, vollständige Fassung im Anhang):
#0 icem_comp_find
#1 icem_selected_lcand
#2 icem_selected_laddr
#3 conncheck_handler
#4 icem_checklist_update
#5 pace_next
#6 stunc_resp_handler
#7 completed
#8 timeout_handler
#9 tmr_poll
#10 re_main
#11 IPSVideoServer (Thread-Lambda, Name gemangelt)
Sieht für mich nach einem Use-after-free aus: Der Timeout-Handler verarbeitet noch eine STUN-Antwort, nachdem die ICE-Komponente schon weg ist.
Dazu passt eine Beobachtung aus dem Browser. Ich habe über die Entwicklerkonsole mitgeschrieben, wann RTCPeerConnections erzeugt, verbunden und geschlossen werden: Beim Laden einer Visu-Session werden in 60 Sekunden 18 PeerConnections auf- und wieder abgebaut, bevor sich vier stabile einpendeln. ICE erreichte dabei jedes Mal in unter einer Sekunde „connected“, keine der beobachteten Verbindungen ging jemals auf „failed“ oder „disconnected“. Sie werden also aktiv geschlossen und neu erzeugt. Je öfter das passiert, desto wahrscheinlicher der Absturz, das würde die unregelmäßigen Abstände erklären.
Was ich ausschließen kann: Speicher (9,7 GB, davon 1,2 belegt, kein OOM), Plattenplatz (49 % belegt), Eingriffe vom Proxmox-Host. Auch der Spezialschalter ProxyRTSPEnforceTCP spielt keine Rolle, der Absturz um 07:55 war bereits mit deaktiviertem Schalter und nach Neustart.
Eine der Kameras liefert unregelmäßig, laut getStats 4 bzw. 15 fps bei 11 Freezes pro Minute und einem Keyframe alle vier Bilder, dabei aber praktisch null Paketverlust. Das ist ein Thema an der Kamera selbst, das ich unabhängig davon angehe. Ich erwähne es nur, weil eine unzuverlässige Quelle vermutlich die Zahl der Verbindungsabbrüche und damit die Häufigkeit des Absturzes erhöht. Die beiden anderen Kameras laufen sauber durch, und der Absturz betrifft ja den ICE-Pfad, nicht die RTSP-Seite.
Der symcon_monitor hat die Minidumps hochgeladen, completed enthält alle drei, pending ist leer. Die Event-IDs:
07:17 f43f71fc-da4d-49e6-82d3-fb574fef296a
07:28 5b3b42c0-cd74-488d-9128-def725ee5264
07:54 6172e8c6-856f-450d-b768-715f3b860bfc
Eine aufbereitete Zusammenfassung mit allen Daten und dem vollständigen Trace des betroffenen Threads hänge ich an.
symcon_crash_report.txt (7,2 KB)
Das Thema scheint nicht neu zu sein, es gibt zwei ältere Threads mit demselben Symptom, allerdings ohne Trace:
https://community.symcon.de/t/streams-in-ips-7-2-bringen-ips-wieder-zum-absturz/138294
https://community.symcon.de/t/kamera-streams-im-webfront-ips-view/143017
Gibt es eine Möglichkeit, den ICE-Aushandlungsaufwand zu reduzieren, wenn ohnehin nur lokal zugegriffen wird? Auffällig ist ja weniger der Absturz an sich als die Zahl der Verbindungsaufbauten, die ihn wahrscheinlich macht. Falls die 18 PeerConnections pro Minute nicht so gedacht sind, wäre das vermutlich der Hebel.
Viele Grüße