Hi!
Eben meinte meine Freundin, dass die Nachttischlampe nicht macht was sie soll…dann wollte ich am Laptop auf das IPS WebFront zugreifen und bekam diese hübsche Meldung :eek:
Nach einem Neustart des IPS-Dienst war wieder alles ok 
>> Aktuelle IPS 3.4 Build
Grüße,
Chris
Ich erhalte den Fehler ebenfalls seitdem ich neuerdings die Methode WFC_Reload() nutze, um das Webfront nach einem Bildschirmeinschalten zu refreshen.
Im logfile findet sich dann der Fehler mit der Adresse 007C3DC2:
12.02.2016 14:29:14.026 | 0 | ERROR | ScriptEngine | FunctionName: WFC_GetSnapshot, ThreadID: 10752, CrashReport: Access violation at address 007C3DC2 in module 'ips.exe'. Read of address 00000000
oder auch mal mit der Adresse 007C420B:
13.02.2016 04:48:37.952 | 0 | ERROR | ScriptEngine | FunctionName: WFC_GetSnapshot, ThreadID: 15240, CrashReport: Access violation at address 007C420B in module 'ips.exe'. Read of address 00000000
Der Fehler tritt bei ca. 5% der Aufrufe auf:(
Viele Grüße
Burkhard
Seit kurzem, meine nach dem letzten Update von IPS 3.4 #3801 bekomme ich auch diesen AV
02.07.2016 03:19:34.314 | 0 | ERROR | ScriptEngine | FunctionName: WFC_GetSnapshot, ThreadID: 3800, CrashReport: Access violation at address 006229FB in module 'ips.exe'. Read of address 00000000
Auch bei mir ist es der WFC_Reload wie bei Burkhard.
Wenn das Problem nach einem Neustart nicht verschwindet deutet es auf eine Problem mit deiner Datenbank. Ggf mal die Wiederherstellung und die dortige Überprüfung mal ausführen.
paresy
Das kann ich erst später überprüfen. Eine Reparatur der Datenbank dauert ein wenig länger.
In der DB ist aber sicher ein Fehler. Den hat mir eine Testinstallation der V4 nebst Migration der DB schon einmal ausgeworfen.
Gesendet von meinem SM-G935F mit Tapatalk
Aber wenn ich mir die Frage erlauben darf…
… Warum erst seit dem Update auf #3801?
Gesendet von meinem SM-G935F mit Tapatalk
Ich befürchte das ist purer Zufall. Wahrscheinlich ist der Defekt schon vorher aufgetreten und erst jetzt nach dem Update/Neustart „sichtbar“ geworden.
paresy
Vielen Dank erst einmal für das Feedback.
Melde mich diesbezüglich wieder wenn ich die DB repariert habe.
Gesendet von meinem SM-G935F mit Tapatalk
ich habe meine DB letzte Woche prophylaktisch reparieren lassen - das oben beschriebene Problem besteht nach wie vor.
Aber ich bin inzwischen sicher, die Ursache eingegrenzt zu haben (bei 3 Nutzeren dokumentiert, alle mit IPS 3.4, WIN7 64bit):
Das ganze passiert immer dann, wenn das WFE neu geladen wird, während im Hintergrund ein Download-Zyklus des RainRadar Forecast (RRFC) aktiv ist.
Hier passiert im Detail folgendes:
während der Downloadzyklus des RRFC läuft, werden alle Medien-Objekte des RRFC (sowohl die Files als auch die Objekte im Baum) gelöscht. Und zwar genau in dem Moment, wo PIC 0 erfolgreich runtergeladen wurde. Danach werden nacheinander alle Medienobjekte (=Radarbilder) neu erzeugt: 1 Radarbild wird runtergeladen => als File auf die HDD geschrieben => anschließend neues Media-Objekt erzeugt => Mediaobjekt und Radarbild werden miteinander verknüpft. Danach dasselbe für Radarbild 2 usw. usw. Abstand zwischen den Radarbildern: ca. 500ms – 2000ms. Der gesamte Zyklus dauert bei mir etwa 4-6 Sekunden.
Wenn während dieses Zyklus das WFE neu geladen wird (auslösender Befehl scheint ‚WFC_GetSnapshot ….‘ zu sein), kommt es - reproduzierbar - zu AV’s. Lädt man das WFE neu, nachdem der Download-Zyklus des RRFC beendet ist, passiert nichts (also keine AV’s).
Im Bild ein AV durch Reload des WFE, zwischen aktiven Downloadzyklen mehrer RRFC-Installationen
Weiteres Problem (ich vermute hier einen Zusammenhang):
nach einigen Tagen Laufzeit (aktuell ca. 3 Tage) von IPS kommt es zu heftigen AV’s beim Aufruf von CURL Funktionen. Das führt zu ziemlich heftigen Folge-AV’s in anderen Scripten. Abhilfe schafft hier nur ein IPS-Restart. Das Problem tritt (auch bei 3 Usern dokumentiert) unter Release #3801 (PHP-Version 5.4.45) auf. Ich habe mein IPS vor 3 Tagen auf Release #3786 zurück gestellt (PHP-Version 5.4.24). mal schauen, ob es hier besser läuft.
Im Bild ein - durch RRFC ausgelöster - AV (3 parallel laufende RRFC-Scripte mit CURL-Aufrufen) + Folgefehler:
ist man zu diesem Zeitpunkt (RRFC Bilderaktualisierung) im mobile Client unterwegs, bricht die Verbindung zu IPS ab und im Log finden sich diese Fehlermeldungen
Grüße,
Maikl
Hallo Andreas,
ich denke das Problem mit der Access Violation dank deiner guten Beschreibung gefunden zu haben.
Einen ersten Fix findest du hier: Bereits in Beta!
Für das cURL Problem kann ich nur vermuten, dass es sich um das selbe handelt, welche mir mit IP-Symcon 4.0 schon über den Weg gelaufen ist (Siehe: PHP :: Bug #71144 :: Sementation fault when using cURL with ZTS) Da die PHP Jungs den Fehler aber nur für PHP 5.6 und neuer akzeptiert haben (der Rest ist EOL), kann ich dir nur meinen Patch anbieten, welcher zumindest das Problem umgehen sollte, solange keiner manuell die CURLOPT_DNS_USE_GLOBAL_CACHE Option aktiviert. (Ich habe dazu die Extension DLL gepatched, sodass der Standard Wert auf 0 (aus) ist)
Download: Bereits in Beta!
Ich würde mich freuen, wenn du mir Feedback gibt, ob die Probleme gelöst sind. Dann würde ich entsprechend eine neue Version für alle bereitstellen.
paresy
ich hab die ips.exe mit der aus dem DL ersetzt, ebenso die php_curl.dll. Allerdings lässt sich die curl-Funktion nicht mehr aufrufen.
Ich hab dann den gesamten ext-Ordner auf PHP 5.4.45 gebracht (also alle dll’s auf den Stand aus Release #3801 gebracht), ebenso den Webfront-Ordner.
Leider lässt sich die curl-Funktion noch immer nicht aufrufen:
also meine disconnects mit der Mobile App sind schon mal weg, samt WFC_GetSnapshotEx AV
den CURL Patch probiere ich gleich noch
Update:
zumindest funktioniert bei mir die gepatchte php_curl.dll
RRFC holt die Bilder, keine Disconnects und AVs
Da ich die php_curl.dll AVs aber nicht provozieren kann und diese völlig unregelmässig aufgetreten sind (im Gegensatz zu den WFC AVs) lass ich das mal rennen und melde mich wenns Neues gibt
Grüße,
Maikl
P.S: Danke für diesen schnellen Support
war eine größere Recovery-Aktion notwendig. Jetzt läuft es, auch ich kann die AV’s nach WFE-Reload nicht mehr provozieren. Jetzt mal abwarten, ob der curl-Patch auch hilft.
kurzer Zwischenstatus:
ich hatte heute Nacht eine Access Violation. Zu dem Zeitpunkt lief u.A. ein Script, welches ein Timer-Event angelegt hat => siehe Bild (mehr konnte ich nicht rausfinden). Ob das mit der AV im Zusammenhang steht, weiß ich nicht.
Zur CURL-Thematik: bisher verhält es sich ruhig. Ich denke, man kann dazu erst was sagen, wenn mind. eine Woche ununterbrochener IPS-Betrieb rum ist.
Ich vermute, dass dies eine andere Ursache haben wird. Freu mich aber schon mal, dass der erste Eindruck positiv ist. Die andere AV können wir auch noch angehen, sobald dies hier als gelöst gibt. Nicht, dass wir zu viele Änderungen auf einmal im System haben.
paresy
Ja, der erste Eindruck ist positiv.
Allerdings hat mich die AV heute Nacht sensibilisiert: ich hab eben wieder eine gehabt (die 2. in 24h), gleiches Szenario (Gardena Bewässerungssprojekt, diesmal aber die parallele Projektinstanz) - Script läuft durch und legt Timer an.
Da die beidnen Projekte aber alle 4h laufen (und bisher ‚nur‘ 2 AV’s aufgetreten sind, lässt sich das schwer eingrenzen). Auf jeden Fall waren jedesmal Konsole und WFE via Chrome offen.
Auf jeden Fall waren jedesmal Konsole und WFE via Chrome offen.
hatte ich heute auch 2x
Schliesse mich dem auch an … Konsole offen und WF … Gruss, MaLu
Ist dies neu seit der Version, oder waren diese schon vorher da?
paresy
