OSX: Ständige Abstürze

pelota · 30. November 2015 um 22:06

Hallo zusammen

Ich bin leider von allzu often Abstürzen geplagt, unregelmässig, ca. 10 pro Tag.
Dank LaunchDaemon ist der Dienst sogleich wieder da und daher bemerken wir die crashes nicht oft. Aber in der Konsole zu arbeiten…

Die Logfiles zeigen überhaupt keine Anzeichen eines Absturzes, abgesehen dass neue erstellt werden.
Die Crash Reports zeigen ein anderes Bild. Hier ein Beispiel:


Process:               ips [34670]
Path:                  /Applications/Symcon.app/Contents/Service/ips
Identifier:            ips
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
Responsible:           ips [34670]
User ID:               0

Date/Time:             2015-11-30 21:34:03.893 +0100
OS Version:            Mac OS X 10.11.1 (15B42)
Report Version:        11
Anonymous UUID:        C5E63922-1FDC-B21B-AEB2-D7B519D9B15C


Time Awake Since Boot: 1700000 seconds

System Integrity Protection: enabled

Crashed Thread:        26

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       EXC_I386_GPFLT
Exception Note:        EXC_CORPSE_NOTIFY

...

Thread 26 Crashed:
0   ips                           	0x000000010a02e318 zend_get_class_entry + 8
1   ips                           	0x000000010a045a83 zend_exception_error + 35
2   ips                           	0x000000010a02affd zend_error + 365
3   libsystem_platform.dylib      	0x00007fff88a0052a _sigtramp + 26
4   ???                           	000000000000000000 0 + 0
5   libc++.1.dylib                	0x00007fff93b4268f std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 47
6   ips                           	0x0000000109b3567d IPSKernel::dispatchMessages() + 381
7   ips                           	0x0000000109b3db92 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::__bind<std::__1::mem_fun_t<void, IPSKernel>, IPSKernel*> > >(void*) + 114
8   libsystem_pthread.dylib       	0x00007fff8c1bd9b1 _pthread_body + 131
9   libsystem_pthread.dylib       	0x00007fff8c1bd92e _pthread_start + 168
10  libsystem_pthread.dylib       	0x00007fff8c1bb385 thread_start + 13

...

Oder:


...

Thread 26 Crashed:
0   ips                             0x000000010422b318 zend_get_class_entry + 8
1   ips                             0x0000000104242a83 zend_exception_error + 35
2   ips                             0x0000000104227ffd zend_error + 365
3   libsystem_platform.dylib        0x00007fff88a0052a _sigtramp + 26
4   ???                             000000000000000000 0 + 0
5   ips                             0x0000000103d35f4a IPSKernel::SendMessage(IPSMessage const&)::$_0::operator()(IIPSMessageSink*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const + 90
6   ips                             0x0000000103d30ab9 IPSKernel::SendMessage(IPSMessage const&) + 729
7   ips                             0x0000000103d32614 IPSKernel::dispatchMessages() + 276
8   ips                             0x0000000103d3ab92 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::__bind<std::__1::mem_fun_t<void, IPSKernel>, IPSKernel*> > >(void*) + 114
9   libsystem_pthread.dylib         0x00007fff8c1bd9b1 _pthread_body + 131
10  libsystem_pthread.dylib         0x00007fff8c1bd92e _pthread_start + 168
11  libsystem_pthread.dylib         0x00007fff8c1bb385 thread_start + 13

...

Oder:

...

Thread 26 Crashed:
0   ips                           	0x0000000110bdb318 zend_get_class_entry + 8
1   ips                           	0x0000000110bf2a83 zend_exception_error + 35
2   ips                           	0x0000000110bd7ffd zend_error + 365
3   libsystem_platform.dylib      	0x00007fff88a0052a _sigtramp + 26
4   ???                           	000000000000000000 0 + 0
5   ips                           	0x000000010fea3e3b rapidjson::GenericMemberIterator<false, rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> > rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::FindMember<rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> > const&) + 75
6   ips                           	0x0000000110769e6b IPSSettings::MessageSink(IPSMessage const&) + 15931
7   ips                           	0x00000001106e5f4a IPSKernel::SendMessage(IPSMessage const&)::$_0::operator()(IIPSMessageSink*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const + 90
8   ips                           	0x00000001106e0ab9 IPSKernel::SendMessage(IPSMessage const&) + 729
9   ips                           	0x00000001106e2614 IPSKernel::dispatchMessages() + 276
10  ips                           	0x00000001106eab92 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::__bind<std::__1::mem_fun_t<void, IPSKernel>, IPSKernel*> > >(void*) + 114
11  libsystem_pthread.dylib       	0x00007fff8c1bd9b1 _pthread_body + 131
12  libsystem_pthread.dylib       	0x00007fff8c1bd92e _pthread_start + 168
13  libsystem_pthread.dylib       	0x00007fff8c1bb385 thread_start + 13

...

Ich hab nur den gecrachten Thread 26 rein kopiert, das File ist einiges grösser. Es scheint übrigens fast immer Thread 26 zu sein, könnte ein wichtiger Hinweis sein…

Solltet ihr mehr benötigen, ich hab ca. 20 Crashreports, die gehen mir nicht aus

Des weiteren, Ich hab die neueste Version am laufen (9ee68b6cd676), die Crashes gibts aber schon mehrere Monate (Sorry, dass ich es erst jetzt melde :o )
EDIT: Die Abstürze starteten mit Upgrade auf El Capitan, zuvor mit Maverick beendete sich IPS lautlos mit Code 255, das war alles (aber genauso häufig).

Gruss
pelota

paresy · 30. November 2015 um 22:40

Hast du die Möglichkeit deine Konfiguration auf Windows oder Raspberry mit der 4.0 einmal zu testen?
Ich würde gerne herausfinden, ob dies ein OSX Problem ist, oder ob es generell abstürzt.

paresy

pelota · 1. Dezember 2015 um 19:02

Uff, jetzt bringst du mich in Schwierigkeiten
Raspi gibt’s nicht - den einzigen, den ich besitze hab ich verbaut. Windows hab ich mit Freuden aus meinem Haushalt verbannt…

Nun, ich hab jetzt auf dem Mac Mini (derselbe auf dem sonst IPS läuft) Virtualbox und Ubuntu installiert, da läuft jetzt IPS.
Ich habe nicht geschafft, alle Geräte zum laufen zu bringen, die Somfy Steuerung (Serial port) und die Jeenodes (Ebenfalls Serial Port) laufen nicht, die werfen halt sporadisch Fehler.
Sonst läuft das System seit ca. 7h stabil. Scheint doch ein Problem unter OS X zu sein

Werde zurück switchen, damit alle Komponenten wieder laufen…

Gruss
pelota

paresy · 4. Dezember 2015 um 15:06

Ich habe so ähnliche Fehler übrigens schon einmal auf meinem MacBook direkt in XCode beim Testen gesehen gehabt, aber trotz mehreren Stunden debuggen nicht herausfinden können, wann die auftreten. Kannst du vielleicht eingrenzen (wenn du Teile nach und nach abschaltest), woher die Abstürze kommen?

paresy

pelota · 4. Dezember 2015 um 15:42

Ich hab bereits gestern Abend angefangen, die Sonos Timer abzustellen, wegen dem Sys_Ping problem. Kann nicht sagen, ob’s ein Absturz an denen lag. Ich hab eher die Vermutung, dass diese mir ein paar mal die Message queue füllten.

Seitdem ist das system 2x abgestürzt, beide Male war der letzte Log-Eintrag einige Minuten früher.

Ich weiss jetzt nur nicht, wo ich anfangen soll
Ich hatte bei 3 Zwave Instanzen den Timer an, die hab ich jetzt ausgeschaltet (Liefen eh meist auf timeout)
Des Weiteren hatte ich einen WWW reader minütlich am pollen, den hab ich auch ausgeschaltet.

Ist nur dumm, dass die Abstürze nicht voraussehbar sind und Stunden vergehen können.

Gibt es etwas, was ich extra für Debugging starten kann? Oder hast du eine IPS Version mit extra Debug Infos, welche man in den Crash Logs sehen kann? Irgendwas…

Was hats denn mit dem Thread 26 auf sich?

Gruss
pelota

pelota · 4. Dezember 2015 um 16:09

Gerade eben 2x gecrasht, im Anhang die Crash Reports
(die Logs sind zu gross, die werden am Anfang stets mit „Invalid data for aggregation“ gefüllt).

ips_2015-12-04-153610_danae.crash.txt (47.6 KB)

ips_2015-12-04-155957_danae.crash.txt (47.6 KB)

paresy · 4. Dezember 2015 um 16:26

Ich würde dir gerne eine Version mit mehr Debug Infos schicken, aber leider sehe ich bereits an den oberen Stacktraces, dass die vollkommen zerschossen sind. z.B. vom dispatchMessages wird niemals diese dort genannte zend Funktion aufgerufen.

Irgendwas läuft da gehörig falsch und ich weiß einfach nicht was. Das komische ist, dass dies nur auf OS X passiert.

Das es Thread 26 ist, scheint dadurch zu kommen, dass immer in der selben Reihenfolge die Threads erstellt werden und bei dir der Nachrichten Thread an stellt 26 kommt. Dort werden alle internen Nachrichten verarbeitet, sodass der Fehler eigentlich überall herkommen kann.

Die einzige Lösung, die ich mir vorstellen kann, ist, dass du alle I/Os und alle Timer/Ereignisse mal deaktivierst und schaust, ob die Probleme weiter auftreten. Wenn ja, dann müsste ich es theoretisch mit deiner Settings auf meinem OS X nachstellen können. Wenn nein, kann man Stück für Stück die Skripte und I/Os wieder aktivieren. Aber man muss immer im Hinterkopf haben, dass ein I/O von HomeMatic z.B. durch Ändern der Variable wiederum Skripte starten kann, die wiederum was anderes beeinflussen können.

paresy

pelota · 6. Dezember 2015 um 21:34

Hab einen
Hoffentlich der einzige.

Habe gestern einen Seriellen Port und und eine WMRS200 Instanz abgestellt und über 24h keinen Absturz gehabt.
Habe danach den Serial Port wieder eingeschaltet und nach 1h kam der Absturz.

Am seriellen Port hängt einen Jeelink welcher via FTDI Treiber angesprochen wird.
Über den seriellen Port sende ich an meine LedNodes Schalt-Kommandos (je Kommando ca. 4 bytes) und ich empfange auch von denen deren Status (Auch ca. 4 bis 20 bytes).

Durch schnelles Schalten der LedNodes via Webfront kam der Absturz nach ca 10 Minuten.

Ich hab einen Cutter mit Register Variable und zugehörigem Dispatcher Script (siehe Unten). Jetzt hab ich dem Cutter den Serial Port wegkonfiguriert und hatte seit 1h keinen Absturz mehr.

Ich werde dies heut nacht weiter so laufen lassen, danach die WMRS200 IO wieder aktivieren. Mal schauen ob da auch noch ein Problem besteht.

Gruss
pelota

PS: Ich erinnere mich, dass ich bereits einen Verdacht auf RegVar hatte. Ich hatte eine RegVar auf den WMRS200 Receiver gelegt (zusätzlich zu eurem Modul), um die weiteren Daten auszulesen, vor allem den Batteriestatus der Sensoren. Diese RegVar habe ich bereits seit längerem stillgelegt.
Könntet Ihr die Batterie-Daten nicht auch in eurem Modul auslesen? Das wäre sehr hilfreich…

Dispatcher Script:


	IPSUtils_Include ("IPSLogger.inc.php", "IPSLibrary::app::core::IPSLogger");
	
	function to_i($s) {
	   return intval($s);
	}
	
	if (substr($_IPS['VALUE'], 0, 3) != "OK ")
		return; // ignore
	$v = substr($_IPS['VALUE'], 3);
	$data = array_map("intval", explode(" ", $v));
	//IPSLogger_Dbg("RF12", join($data,","));
	
	
	$handlers = array();
	include_once IPS_GetScriptFile(37997 /*[Instanzen\Obergeschoss\Galerie Leselampe\RF12Handler]*/);
	include_once IPS_GetScriptFile(45404 /*[Instanzen\Obergeschoss\Galerie Standlampe\RF12Handler]*/);
	include_once IPS_GetScriptFile(16329 /*[Instanzen\Alarm\Bewegung Küche\RF12Handler]*/);

	foreach($handlers as $handler) {
	   if($handler->respondsTo($data))
	      $handler->handle($data);
	}

Beispiel eines „Handlers“:

	class ReadingLampHandler {
	   function respondsTo($data) {
	      return(count($data) == 5 && $data[0] == 8 && $data[3] == 5);
	   }

	   function handle($data) {
			if($data[1] == 64) // State
			   SetValueBoolean(51791 /*[Instanzen\Obergeschoss\Galerie Leselampe\Status]*/, $data[4] == "1");
			else if($data[1] == 32) //Intensity
			   SetValueInteger(35993 /*[Instanzen\Obergeschoss\Galerie Leselampe\Intensity]*/, $data[4]);
		}
	}

	$handlers[] = new ReadingLampHandler();

pelota · 7. Dezember 2015 um 19:27

OK, hab beide Absturzherde:

So wie ich oben geschrieben habe, die Cutter-RegVar-Script Kombi.
WMRS200, ich hab die IO-Instanz heute Morgen um 8 wieder aktiviert, seit dem 3 Abstürze.

Gruss
pelota

paresy · 11. Dezember 2015 um 13:35

Drei Fragen hab ich noch:

Ich habe noch einen offenen Fehler, dass Abfragen Mittels cURL zu abstürzen führen. Ich vermute deine RegisterVariable nutzt kein cURL, oder ggf die daraus resultieren Ereignisse/Skripte?
Hängt an der Wetterstation, bzw. deren Variablen irgendwelche Ereignisse/Skripte dahinter die Aufgerufen werden?
Das aktuellste Update hat bisher nichts gebracht?

paresy

pelota · 11. Dezember 2015 um 19:52

Nein, keine cURL Skripte, nur Auswerten vom Value und andere Variablen setzen.
Ein einziges, welches die Windrichtung nimmt und sie gem. meiner Sensor-Ausrichtung „dreht“ und in eine andere Variable schreibt. Wie bereits erwähnt, hatte ich früher noch eine extra RegVar am WMRS200, um weitere Daten auszuwerten, aber diese hatte ich bereits im Oktober deaktiviert.
Nein, nichts leider.

PS: Ich hab inzwischen einen Pi2 besorgt, da läuft jetzt die ganze Installation seit 2 Tagen ohne einen einzigen Absturz. Jetzt laufen auch alle IO’s…

Gruss
pelota

paresy · 11. Dezember 2015 um 22:51


PS: Ich hab inzwischen einen Pi2 besorgt, da läuft jetzt die ganze Installation seit 2 Tagen ohne einen einzigen Absturz. Jetzt laufen auch alle IO's...

Ok. Dann füge ich mal in die Fehlerliste, dass OS X noch ein generelles Problem hat, wenn zu viele Skripte gleichzeitig laufen.
Ich vermute nämlich, dass dies das Problem ist…

Danke erstmal!

paresy

wupperi · 12. Dezember 2015 um 09:13

Kannst Du die Settings und die Skripte mal bitte hier rein stellen. Ich habe auch den WMRS200 und mich interessiert, welche zusätzlichen Info’s man herausbekommt.

pelota · 12. Dezember 2015 um 13:38

Hallo Wupperi

Ja klar, hätte ich eigentlich schon lange tun sollen. :o

Ich hab’s in das „Anleitung/Nützliche Scripte“ Forum gehängt, ist ja nicht explizit für IPS 4:
WMRS200: Erweiterte Daten (Batterie, Trend, Vorhersage)

Gruss
pelota

paresy · 25. Dezember 2015 um 19:04

Gibt ab jetzt ein Update für OS X, welches hoffentlich das Problem umgeht. Freue mich auf Feedback, ob es die Abstürze löst!

paresy

Achi · 4. April 2016 um 17:50

Hallo Zusammen,

bei mir ist es nach einem Absturz oder nach dem regulären Dienst beenden nicht möglich den Dienst wieder zu starten. Ich muss meinen Rechner immer neu Starten.
Ich bekomme auch keine Fehlermeldung. Wenn ich auf Dienst starten klicke werde Ich aufgefordert mein Adminpasswort einzugeben. Wenn ich das gemacht habe verschwindet die Eingabeaufforderung. Wenn Ich nun im Tray schaue ist der Dienst nicht aktiviert.
Betriebssystem OSX 10.10.5 Yosemite

Tipps?

paresy · 4. April 2016 um 17:52

Das scheint in der Tat noch ein Fehler zu sein. Siehe hier: Bug? IPS auf Mac start nicht

paresy