SOLVED SIGSEGV div. Adapter scheinbar ohne Grund

[Matthias Laumer]

Hallo zusammen,

ich habe iobroker bereits auf dem Raspberry 2B+ betrieben und bin aufgrund des limitierten Arbeitsspeichers (da das System immer wieder mal ins swappen kam) auf den Rock64 mit 4GB Arbeitsspeicher umgestiegen.

Nach anfänglichen, "konfusen" Problemen, dachte ich mir, dass ich es mal mit einem vorgefertigten Image probiere. Allerdings habe ich das Problem, dass ich etwas 3-4 mal am Tag einen Seg-Fault aus div. unterschiedlichen Adaptern bekomme??

Das sieht dann etwa so aus:

2020-01-13 18:27:12.760  - info: admin.0 (1601) Repository received successfully.
2020-01-13 19:41:54.570  - warn: host.rock64 instance system.adapter.enigma2.0 terminated due to SIGSEGV
2020-01-13 21:16:32.228  - warn: host.rock64 instance system.adapter.shelly.0 terminated due to SIGSEGV
2020-01-13 21:17:05.575  - info: shelly.0 (25269) starting. Version 3.1.6 in /opt/iobroker/node_modules/iobroker.shelly, node: v10.18.1
2020-01-13 21:17:05.674  - info: shelly.0 (25269) Starting Shelly adapter in CoAP modus.
2020-01-13 21:17:05.844  - info: shelly.0 (25269) Listening for Shelly packets in the network

Ich habe auch bereits auf "verdacht" ein npm rebuild ausgeführt, das auch ohne Fehlermeldung abgeschlossen wurde.

Auch der tr064-community Adapter macht mir Probleme, die anscheinend niemand anders hat... (wollte nicht gleich ein Issue auf Github erstellen, da ich mir nicht sicher bin, ob das nicht irgendwie mit meinen Seg-Faults zusammenhängen könnte...

2020-01-13 09:37:52.196  - error: tr-064-community.0 (2150) uncaught exception: Cannot read property 's:Envelope' of undefined
2020-01-13 09:37:52.200  - error: tr-064-community.0 (2150) TypeError: Cannot read property 's:Envelope' of undefined
    at /opt/iobroker/node_modules/tr-O64/lib/Service.js:217:33
    at Parser.<anonymous> (/opt/iobroker/node_modules/xml2js/lib/parser.js:308:18)
    at Parser.emit (events.js:198:13)
    at SAXParser.onerror (/opt/iobroker/node_modules/xml2js/lib/parser.js:123:26)
    at emit (/opt/iobroker/node_modules/sax/lib/sax.js:624:35)
    at error (/opt/iobroker/node_modules/sax/lib/sax.js:653:5)
    at strictFail (/opt/iobroker/node_modules/sax/lib/sax.js:677:7)
    at closeTag (/opt/iobroker/node_modules/sax/lib/sax.js:871:9)
    at SAXParser.write (/opt/iobroker/node_modules/sax/lib/sax.js:1436:13)
    at Parser.exports.Parser.Parser.parseString (/opt/iobroker/node_modules/xml2js/lib/parser.js:323:31)

Systemdata
Hardwaresystem:	Rock64
Arbeitsspeicher:	4GB
Festplattenart:	eMMC
Betriebssystem:	Debian Stretch
Node-Version:	10.18.1
Nodejs-Version:	10.18.1
NPM-Version:	6.13.4
Installationsart:	Über Image
Image genutzt:	Ja
Ort/Name der Imagedatei:	ioBroker_Image_Rock64_20190730_stretch
js-controller:	2.1.1

Als State-Verwaltung beutze ich einen Redis Server...

Hat jemand einen Tipp für mich, wie ich dem Ganzen auf den Grund gehen kann?
Ich bin leider kein JavaScript erfahrener Typ und weiß auch nicht, wie ich mir mehr Informationen über die Fehler beschaffen könnte.

Danke schon mal!
Matthias

[Matthias Laumer]

Nur ein kurzes Update, falls jemand mit dem selben Problem diesen Thread findet:
Nach längerer Analyse und rumprobieren, bin ich mittlerweile der Meinung, dass ich einen fehlerhaften RAM verbaut bekommen habe. Tests mit unterschiedlichen Betriebssystemen und dem "memtester" (sudo apt install memtester) ergaben mehrere defekte Blöcke im RAM.
Mehrere manuelle Eingriffe und Limitierungen brachten das Ganze nun zumindest wieder in ein mehr oder weniger stabiles System. (wobei ich das Teil trotzdem aussortieren werden muss...)

Was habe ich alles getan?

Limit des benutzen Speichers:

Die defekten Blöcke befinden sich anscheinend im unteren Adressbereich, allerdings habe ich es einfach nicht hinbekommen den Speicher mit memmap den benutzten Speicherbereich genau zu definieren... daher habe ich letztendlich versucht den RAM einfach zu halbieren. Dies brachte eine messbare Besserung.
(extraargs=mem=2000M)

pi@rock64:~$ cat /boot/armbianEnv.txt
verbosity=1
overlay_prefix=rockchip
rootdev=UUID=aadb45fc-8b8b-4b5b-ad50-7e6416a4e1c5
rootfstype=ext4
extraargs=mem=2000M
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

Limit des Taktes zur eMMC

Anscheinend ist der Clock zum Speichermedium etwas hocj (200 Mhz), was evtl. zu Kommunikationsproblemen führen kann. Ich habe diesen daher in der rc.local limitiert auf 150 Mhz.

pi@rock64:~$ cat /etc/rc.local 
#!/bin/sh -e
#Limit eMMC clock!
echo 150000000 > /sys/kernel/debug/mmc0/clock

Fix redis

Laut Redis-FAQ kann es auf manchen Systemen zu Problemen bzgl. dem Speicherverhalten von Redis geben. (für Details, siehe Link)
Daher dieser Eintrag in die rc.local:

echo 1 > /proc/sys/vm/overcommit_memory
exit 0

Limit CPU clock über System-Config Tool:

sudo armbian-config

System & Security Settings

Set CPU Speed and Guvanour

Nach allen Änderungen gehen die memtester-Runs nun größtenteils ohne Fehler durch. Allerdings muss ich im Nachhinein sagen, dass der Rock64 für mich einfach ein klarer Fehlkauf war.

Ich habe mir nun einen Raspberry Pi4 bestellt. Auch 4GB RAM und preislich auch im selben Bereich. Ich hoffe, dass dieser bald eintrifft und ich die iobroker Installation einigermaßen schmerzfrei umziehen kann.

MFG
Matthias

[Homoran]

@Matthias-Laumer sagte in SIGSEGV div. Adapter scheinbar ohne Grund:

dass der Rock64 für mich einfach ein klarer Fehlkauf war.

das müsste aber ein individuelles Problem sein.
Bei mir laufen zwei Rock64 ohne jegliche Probleme seit Jahren. Mit eMMC und ohne.
Allerdings hatte ich mit
einem eMMC Modul wohl auch Pech

[Matthias Laumer]

@Homoran said in SIGSEGV div. Adapter scheinbar ohne Grund:

das müsste aber ein individuelles Problem sein.

Das glaube ich ehrlich gesagt auch. Allerdings finden sich tatsächlich einige Rock64 User die über ähnliche Probleme klagen.
Zwischenzeitlich ist auch der Pi4 den ich stattdessen bestellt habe eingetroffen und konnte eingerichtet werden. Ich habe die selbe Installation (vom Rock64) umgezogen und nach einigen erfolgreichen memtests nun seit fast 3 Wochen ohne jeglichen Absturz am Laufen.
Es scheint also wirklich ein Hardware-Thema gewesen zu sein...

Mfg
Matthias