Automatischer BugReport

Hallo,
offensichtlich existiert bei euch folgendes Postfach nicht „bugreports@ipsymcon.de“ ==> euer Server meldet „550 sorry, no mailbox here by that name“

… daher hier als Post,
wie ich in der Console das Debugfenster der RegisterVariable öffnen wollte ist es zur folgenden Meldung gekommen „ERROR OCCURED ==> SessionID #??? existiert nicht“ (siehe Screenshot) und *.ELF

… was ich eigentlich schauen wollte ob das Zeitproblem noch in der RegVar besteht ==> diese Zeitproblem kann ich auch gleich hiermit als noch vorhanden melden

http://www.ip-symcon.de/forum/f18/speicherueberlauf-konstellation-7374/#post61359

… habe auch nochmals einen Screenshot des Buffers der IPS2.1b [28.07.2009] mitangehängt

tgusi74

Das was auf dem Bild zu sehen ist, ist muss ein Programmierfehler deinerseits sein. IP-Symcon schreibt den Buffer in den Log, wenn du RegVar_SetBuffer aufrufst. Da der Inhalt in deiner Verantwortung liegt, muss in deinem Skript ein Fehler sein.

paresy

Hallo paresy,
das kann nicht sein …

hier das Empfangsfile, welches durch die RegVar aufgerufen wird

<?
$RegVar_COM3_READ  = 35886 /*[LOGO\RegisterVariable_COM3_READ]*/  ;


//BUFFER FUELLEN --> Daten lesen von COM-Port
$buf = RegVar_GetBuffer($RegVar_COM3_READ);

//Semaphore setzen wenn der Buffer leer ist und neue Daten empfangen werden
if (strlen($buf) == 0)
    {
      SetValueInteger(17047 /*[LOGO\LOGO_READ\LOGO_SEMAPHORE]*/ ,1);
    }


$buf .= $IPS_VALUE;
RegVar_SetBuffer($RegVar_COM3_READ,$buf);
//*******************************************



if (strlen($buf)>= 71)
	{
    if (ord($buf[8]) == 17)
       {
	 echo("DATENEMPFANG OKAY Byte8=" . ord($buf[8]) . " ==> " . strlen($buf) . " Zeichen
");
	 SetValueInteger(17047 /*[LOGO\LOGO_READ\LOGO_SEMAPHORE]*/ ,0);
       }
    else
		 {
        echo ("ERROR: Lesebuffer verschoben !! --> Typ=Byte[8]=" . ord($buf[8]) . ")
" );
	     SetValueInteger(17047 /*[LOGO\LOGO_READ\LOGO_SEMAPHORE]*/ ,0);
		 }
	}

?>

… dieses Zeitverhalten ist erst seit der „StrUtilities.dll“ vom 28.05.2009 zum ersten mal aufgetreten, mit einer älteren DLL ist dieses Verhalten nicht festzustellbar und alles geht „ratz fatz“, nur eben das Speicherproblem

Bitte um Info wo da der Fehler liegt
Danke

tgusi74

Mal zusammengekürzt:

$buf = RegVar_GetBuffer($RegVar_COM3_READ); 
 $buf .= $IPS_VALUE; 
RegVar_SetBuffer($RegVar_COM3_READ,$buf)

Alles in allem hängst Du an den Buffer permanent Daten an und verkürzt ihn nie. Dadurch wird Dein Speicher natürlich immer voller.

Hallo Horst,
dafür sorgt der Anforderungsscript, bevor der neue Request geschickt wird ein löschen des Buffers durchgeführt

verkürzter Script (es sind normalerweise eben noch Prüfungen für den Semaphore enthalten, welche die Anforderung nicht durchlassen wenn noch nicht fertig)

 
<?
$ComPortID         = 33848 /*[Serial_Port_COM3]*/ ;
$RegVar_COM3_READ  = 35886 /*[LOGO\RegisterVariable_COM3_READ]*/ ;
$RegVar_COM3_WRITE = 39138 /*[LOGO\RegisterVariable_COM3_WRITE]*/ ;

  //LeseBuffer leeren bevor neuen Request
   RegVar_SetBuffer($RegVar_COM3_READ,"");
   IPS_Sleep(50);

   echo("SENDE NEUE ANFORDERUNG ========> " . date("H:i:s"));

   //Schreibe BEFEHL an die LOGO! --> 0x55 0x13 0x23 0x00 0xAA
   RegVar_SendText($RegVar_COM3_WRITE, chr(hexdec("55")).chr(hexdec("13")).chr(hexdec("13")).chr(hexdec("00")).chr(hexdec("AA")));

?>

… als Anhang nochmals den Ablauf des Empfangs bzw. Verarbeitung im Debugfenster (siehe zeitlichen Zusammenhang)

tgusi74

P.S.: sollten wir nicht den Thread wechseln ?? (bzw. ihr verschiebt die Post’s)

Hi,

das Zeitverhalten kann ich bestätigen. Schnelles auslesen meines BHKW ist mit der „StrUtilities.dll“ vom 28.05.2009 nicht mehr möglich. Teilweise dauert das 5-6 Sekunden. Sonst hatte ich im 3 Sekundenintervall ausgelesen um bestimmte Meldungen mit zu bekommen.
Das Speicherproblem ist jetzt dafür weg, der bleibt konstant stehen (hoffe das bleibt so).
Dafür kam gestern ein paar mal diese Meldung im Log:

27.07.2009 14:30:20.609 | 59281 | WARNING | Serial Port | Access violation at address 0053E9BD in module ‚ips.exe‘. Write of address 00000004

Heute kam die nicht und passiert ist durch die Meldung auch nichts.

Gruß
Thomas

P.S wie ich im anderen Post schon geschrieben habe, finde ich die jetzige Lösung nicht sehr gelungen. Ausserdem ist es auch nicht sehr erbauend, wenn sich solche Sachen grundlegend ändern und man in einem großen Projekt dann dadurch Arbeit hat ohne Ende. Durch das Speicherproblem wurde man aber gezwungen zu handeln.

Da haben paresy und ich Dich wohl falsch verstanden. Aufgrund des tollen Linktitels Speicherüberlauf mit dieser Konstellation und dem Hinweis auf das Speicherproblem dachten wir, dass Du auch noch auf ein zusätzliches Speicherleck aufmerksam machen wolltest :rolleyes:.
Das mit der Verlangsamung ist eigentlich meine Schuld, da ich mich darüber beschwert hatte, dass durch das Threading die ankommenden Daten von mehreren Skriptaufrufen parallel verarbeitet worden sind und ich dadurch dann gerne mal die Daten im Buffer verdreht hatte. Da half dann auch keine Semaphore mehr. Das wurde zusammen mit dem Speicherleck behoben. Allerdings ist diese Version verlangsamt.
Nach dem Release der 2.1 kannst Du paresy aber nochmal drauf hinweisen. Dann wird er mal sehen, dass er der RegisterVariable einen eigenen Thread reserviert.

Sorry,
wenn ich da mit dem Link für Verwirrung gesorgt habe, wollte eben nur darauf hinweisen das wir das ZEITLICHE verhalten vom 28.05.2009 nun in der IPS2.1b haben, finde ich überhaupt nicht gut das jetzt die Verarbeitung mindestens 5mal solang dauert als früher :confused:

Leider muss ich jetzt auch gleich daraufhinweisen, das mir vorhin IPS wieder eingeschlafen ist !! (wie im LINK hier :mad:)

Im Logfile waren die letzten Einträge

Access violation at address 7C920F20 in module 'ntdll.dll'. Read of address 000003CE

P.S.: könnt ihr die Beiträge entsprechend verschieben, oder den Thread umbenennen

danke
tgusi74

Hallo,
hier nochmals ein LOG-Auszug, ab diesen Zeitpunkt war wieder der Bufferinhalt verdreht !!

… es war aber zu diesen Zeitpunkt kein Aktivitäten mehr ersichtlich, jedoch wenn dann das „Zwangslöschen des Semaphore“, im Test nach 20 Sekunden durchgeführt wird (Anforderungsscript), dann stimmt ab diesen Zeitpunkt der Bufferinhalt nicht mehr

Problemlösung ist dann immer das schließen und wiederverbinden der COM-Schnittstelle !! (… dann stimmt auch der Bufferinhalt wieder)

… irgendwo hängen da noch Daten im Empfangsbereich, welche trotz sauberen Ablöschen des Buffers vor „neuer Anforderung“ da, dann immer noch reinspucken !! :confused:

Als Anhang die Scripts des Test’s (alle anderen Timer, … sind während Test deaktiviert)

tgusi74

Hallo tgusi74,

eine Frage.
Du sendest 2 mal 0x13.

Die nächste, warum benutzt du nicht „\x55\x13\x23\x00\xAA“

//Schreibe BEFEHL an die LOGO! --> 0x55 0x13 0x23 0x00 0xAA 
   RegVar_SendText($RegVar_COM3_WRITE, chr(hexdec("55")).chr(hexdec("13")).chr(hexdec("13")).chr(hexdec("00")).chr(hexdec("AA"))); 

Ist mir nur so aufgefallen, hat aber mit deinem Problem nichts zutun.

Hallo,
habe heute tagsüber den Test laufen gehabt,
nach ca. 6 Stunden ist IPS wieder eingeschlafen, da hat offensichtlich der von PARESY vermutete DEADLOCK vom 30.05.2009 wieder zugeschlagen, jedoch war dieses mal nicht auffälliges im Logfile

@RWN,
da liegt der Fehler im Kommentar, der Anforderungstring stimmt ==> 0x55 0x13 0x13 0x00 0xAA

tgusi74

Hallo Paresy,
habe den Test mit der neuen 2.1b 29.07.2009 erneut durchgeführt, wird DEADLOCK und Access Violation

Access violation at address 7C920F20 in module 'ntdll.dll'. Read of address 00000004

… schau dir bitte einmal das Logfile an, hier gehen bevor die Access Violation kommt der Anforderungsversuch 3 ab ??? (Timerevent wo eben der Semaphore noch sitzt)

Danke
tgusi74

Hast du vielleicht auch eine von den ips.elf Dateien in deinem IPS Order die du mir anhängen könntest?

paresy

hier die IPS.ELF

Kannst du mal die Version ausprobieren, die ich eben hochgeladen habe? Sie müsste eigentlich wieder sehr schnell sein und hoffentlich auch den Fehler gleich mit erledigen.

paresy

Okay,
Test ist aktiv ==> Geschwindigkeit schaut wieder Top aus :slight_smile: … immer unter 1 Sekunde für Anforderung + Antwort

… dann hoffen wir das Beste, dass es morgen noch läuft :wink:

Danke
tgusi74

Hallo,
hier das Testergebniss


30.07.2009 22:27     Teststart
31.07.2009 01:27:02  erste mal dass der Bufferinhalt fehlerhaft ist

                     ... jede weitere Anfrage fehlerhaft

31.07.2009 01:51:24  Bufferinhalt wieder in Ordnung

                     ... jede weiter Anfrage wieder sauber !!

31.07.2009 06:51     das offene Konsolenfenster ist eingefroren,
                     aber IPS arbeitet in Hintergrund noch fehlerfrei

31.07.2009 13:13:00  erneut ist der Pufferinhalt verschoben

                     ... je weitere Anfrage fehlerhaft

31.07.2009 15:30     Versuch die Konsole zu beenden (keine Rückmeldung)

                     ... mit Taskmanager abgeschossen (Konsole + SysTray)
                            
                     ... SysTray wieder gestartet und Konsole öffnen ==> Fenster öffnet nicht

                     ... wieder mit Taskmanager abgeschossen (Konsole + SysTray)

                     ... SysTray gestartet ==> versuch den Dienst zu beenden, ohne Erfolg (jedoch stehen einige Zeilen im Logfile)

                     ... Taskmanager IPS abgeschossen

… leider ist die IPS-Konsole eingefroren und der Bufferinhalt ist Zeitweise verschoben gewessen

… als Anhang das gekürzte Logfile (22MB anstatt 650MB)

tgusi74

P.S.: habe jetzt den Test wieder gestartet und die ZEITSYSNCHRONISATION in Windows abgeschaltet !!!

Also der Buffer kann seitens IPS nicht verschoben sein, da es eine einfache Liste ist, die nacheinander abgearbeitet wird. Da muss bei dir noch irgendwo ein Synchronisationsproblem drin sein.

Außerdem wirkt das Skript insgesamt recht kompliziert. Die Write RegVar kannst du löschen und einfach die Read RegVar dafür verwenden. Oder sind das wirklich 2 Com Ports? Wenn nicht, fallen dann schonmal 50% der Skriptaufrufe weg.

Muss das so gemacht werden?

COMPort_SetRTS ($ComPortID,false);
COMPort_SetDTR($ComPortID,false);
IPS_Sleep(50);

COMPort_SetDTR($ComPortID,true);
COMPort_SetRTS ($ComPortID,true);

Um welche/wieviel Zeichen ist der Puffer verschoben?

paresy

Hallo Paresy,
habe nun die RegVAR „RegisterVariable_COM3_WRITE“ entfernt (ausgehängt), war immer der Meinung das ich für das schreiben eine eigene RegVar benötige zwar mit Dummyscript :rolleyes: und habe mich immer gewundert warum diese auch beim Empfang mitgetriggert wird

… habe nun auch das Logging nochmals umgebaut um genauer sagen zu können was da im Buffer steht (Test läuft, Script im Anhang)

==> wenn das Zeichen 8 im Buffer nicht 0x11 (Dec 17) ist, dann stimmt der Bufferinhalt nicht !! (Gerätekennung, welcher Typ von LOGO! angeschlossen ist)

… zu Test von gestern,
hat es so ausgeschaut als ob das letzte Zeichen 0xAA (Dec 170), noch irgendwo im „IPS“ gehängt (Steuerung ist auzuschliessen) währe und nach einer neuen Anforderung als erstes eingelesen wurde und somit der Buffer zwar nicht verdreht aber verschoben war, normalerweise muss als erstes Zeichen ein 0x06 (Dec 6) empfangen werden ==> ACK das die Anforderung verstanden wurde

… zu Test heute NACHT,
IPS ist wieder um 00:28 eingeschlafen !! (Logfile im Anhang)

Das mit dem „RTS/DTR“ muss leider so gemacht werden, ansonsten keine Daten von der LOGO!

P.S.: … die RegVAR kann nicht gelöscht werden, das stürzt IPS2.1[30.07.2009] ab !! (kann jederzeit auch mit neuanlegen und löschen nachgestellt werden)

tgusi74

hat es so ausgeschaut als ob das letzte Zeichen 0xAA (Dec 170), noch irgendwo im „IPS“ gehängt
Hast Du noch einen Cutter dazwischen?
Das Problem hab ich bei meinem Bussystem auch. Nur schickt der mir noch einen kompletten Datensatz obwohl schon neue Daten vorhanden sind. Allerdings habe ich da noch nicht weiter nachgesehen, da nur Temperaturdaten.
Der ganze Hickhack ist erst seit Umstellung der RegVar.

P.S.: … die RegVAR kann nicht gelöscht werden, das stürzt IPS2.1[30.07.2009] ab !! (kann jederzeit auch mit neuanlegen und löschen nachgestellt werden)

Jo, löschen geht, dabei steigt der Dienst aus.