Absturz

IP-Symcon
1 

#0  zend_get_class_entry ()
    at /home/pi/kernelcpp/res/php-5.5.26/Zend/zend_API.c:237
#1  0x00a11658 in zend_exception_error ()
#2  0x009fa02c in zend_error_noreturn ()
#3  <signal handler called>
#4  0xb6901c54 in recv () from /lib/arm-linux-gnueabihf/libpthread.so.0
#5  0xb6dd9cd8 in ?? () from /usr/lib/arm-linux-gnueabihf/libssh2.so.1
Cannot access memory at address 0x414c
#6  0xb6dd9cd8 in ?? () from /usr/lib/arm-linux-gnueabihf/libssh2.so.1
Cannot access memory at address 0x414c
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
2

Und wieder einen:


#0  zend_get_class_entry ()
    at /home/pi/kernelcpp/res/php-5.5.26/Zend/zend_API.c:237
#1  0x00a11658 in zend_exception_error ()
#2  0x009fa02c in zend_error_noreturn ()
#3  <signal handler called>
#4  0xb6886f0c in writev () from /lib/arm-linux-gnueabihf/libc.so.6
#5  0xb69a6354 in std::__basic_file<char>::xsputn_2(char const*, int, char const*, int) () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#6  0xb69de1ec in std::basic_filebuf<char, std::char_traits<char> >::xsputn(char const*, int) () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#7  0xb69bfe5c in std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, int) ()
   from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#8  0x00870af4 in IPSSettings::WriteSettings() ()
#9  0x008715e0 in std::thread::_Impl<std::_Bind_simple<IPSSettings::IPSSettings(IIPSKernelEx*)::{lambda()#1} ()> >::_M_run() ()
#10 0xb69dd848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#11 0xb69dd848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
3

Hast du eine Idee wann die kommen oder ab du die Nachstellen kannst?

paresy

4

Verwendest du in manchen Scripten auch cURL? Ich hatte den Fehler auch schon mal gesehen. Aber seit ich cURL aufrufe per Semaphore auf Single Thread beschränkt habe, habe ich keine Fehler mehr. Kann natürlich auch sein, dass er einfach nicht nochmal aufgetreten ist.

5

Nein, cURL verwende ich nicht. Reproduzieren ist auch schwierig; kann keine Systematik erkennen,. Kann nur sagen, dass der Dienst keine 12h ohne Absturz durchhält. Hilft es, wenn ich weiter im Debug-Mode bleibe?

6

Hallo zusammen.

Wir sollten vielleicht immer die Linux Version, die Raspi-Firmware und die IPS Version mit angeben?
Ich vermute inzwischen, es gibt dort Zusammenhänge mit den aktuellen Abstürzen.

Mich hatte der Treat von herbertf dazu bewegt:
Absturz innerhalb von 10Minuten nach erstmaligem „Too many scripts at once…“ - Seite 2

Mein IPS läuft seit zwei Tagen wieder stabil (obwohl der Cache den gesamten Freien Speicher beansprucht) nachdem ich Linux und Pi Firmware auf den neuesten Stand („Kernel version: Linux 4.1.10-v7+ armv7l Firmware: #821“) gebracht habe.
Und Jessie läuft auch noch drauf.

LG
lueralba

7

Ich würde gern mal fragen, ob man aus den Debug-Logs irgendwas rausfinden konnte? Momentan behelf ich mir mit einem Cronjob, welcher den Dienst überprüft und neu startet, falls er nicht mehr laufen sollte.

8

Hallo dfhome.

Nachdem ich nun etliche Abstürze hatte, habe ich ALLE ereignisgesteuerten Sripte abgeschaltet.
Dann Tag für Tag wieder WENIGE reaktiviert. Bei meinem Fritzboxscript bin ich z.Zt. fündig geworden.
Nachstellen kann ich es noch nicht, aber eingrenzen.
(Alle anderen: Bitte nicht steinigen, ich hatte es schon mal komplett abgeschaltet, da gab es aber immer noch Abstürze !?!)

Das Script im Pi war noch cURL basiert. Habe es eben auf SOAP (von Nall Chan - Danke - ) geändert.
Gerade wieder meinen Lasttest gestartet.

Bin guter Dinge, dass es besser wird … :slight_smile:
War so ein bisschen deprimierend.

Gruß
lueralba