The next Bug: PHP-Scripts längenbegrenzt???

Bugreports und Updatewünsche an die Firma contronics
Keine allgemeinen Fragen!

Moderator: Co-Administratoren

gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

The next Bug: PHP-Scripts längenbegrenzt???

Beitrag von gwanjek » 15.01.2007, 23:53

Hallo,
sorry daß ich schon wieder nerve. Allerdings nervt es auch, wenn ein offenbar von vielen anderen Usern (ok, bei der Konkurrenz) benutztes PHP-Script
- am DOS-Prompt anstandslos durchläuft
- im Makro das Projekt zum einfrieren bringt!!!

und das auch noch unter der sehr wohl reproduzierbaren Bedingung der Überschreitung einer gewissen Menge Codes (wobei selbst Kommentare in dieser Menge Code mitzählen)

Also nochmal:
- Teil des Scripts für sich läuft,
- anderer auch
- beide zusammen: Projekt friert ein / auch nach vielen Minuten keine Reaktion / nur mit Task-Manager zu killen

Der Gag dabei: Wenn ich einige Zeilen wieder rausnehme und zwar EGAL WELCHE (sogar: Kommentare) läuft es wieder. Hauptsache ich bleibe offenbar unter einer gewissen Quellcode-Größe!

Bevor einer sagt: "ach ja, bei der Konkurrenz ist ja alles anders, kann ja nicht gehen" usw.: Das Script holt lediglich einige Informationen per Internet von einem Webserver und speichert die in einer Stringvariablen zur weiteren Verwendung. Da dürften die Bedingungen ja wohl gleich sein! (und es funktioniert ja auch am Prompt gestartet ohne Probleme, ohne IPS installiert zu haben).

Funktionell werden übrigens PLZ-abhängige Wettervorhersage-Werte der nächsten 3 Tage geholt. Höchst interessant und offenbar lange stabil in breiter Anwendung gelöst... Wer mehr dazu wissen will, siehe ganz unten.

Nachfolgend nun das abgerüstete Code-Beispiel, bei dem bereits der Fehler auftritt:

Darin sind oben einige Zeilen gnadenlos auf simple Zuweisungen zusammengekürztes Hauptprogramm, darunter dann einige Functions, die im Beispiel noch nichtmal angesprochen werden. Alles als Makro "calcVorhersage" vom Typ "Knopf", als letzte Zeile im Hauptprogramm wird "abc" ausgegeben in ein Zeichen-Objekt "viewAusgabe"

Im angegebene Beispiel führt auf-den-Knopf-Klicken zum besagten Einfrieren. Simplizierte Sollfunktion war die besagte Ausgabe. Egal ob nun unten die letzten zwei Functions rausgenommen werden, oder anderer Code wie z.B. die beiden vorletzten Hauptprogramm-Zeilen
$data['VORHERSAGE'] = array();
$data['UPDATEINFO'] = array();
vor der finalen Output-Anweisung
$viewAusgaben="abc";
...und schon erscheint "abc" sauber in die Ausgabe!

Da es also egal ist, WELCHER Code rausgenommen wird, kann es am Code selbst ja wohl kaum liegen. Wie gesagt, der läuft ja auch auf gleichem PC mit gleichem PHP!

Ergo ist dann also entweder irgendwas mit dem Speichermodell ganz arg im Argen (siehe die anderen Laufzeitfehler!), oder irgendwas begrenzt prinzipbedingt die Quellcodegröße!

Wenn das nun nicht direkt so nachvollziehbar sein sollte: Ich habe schon eine ganze Reihe andere Objekte im Projekt! SPG-Datei ist 77188 Bytes lang. Vielleicht muß erst ein gewisser "Füllgrad" des Speichers erreicht sein, bevor der überläuft?

Code: Alles auswählen

<?

// --- EINSTELLUNGEN ---------
$PLZ     = "Bern";
$PLZ     = "76137";
$varname = "WETTER_www-wetter-net.Data";

ini_set( 'max_execution_time', 300);

//--- BEGIN --------
$t1 = time();
$baseurl = "http://www.wetter.net/cgi-bin/wetter-net/";
$data    = array();
$data['VORHERSAGE'] = array();
$data['UPDATEINFO'] = array();

$viewAusgaben="abc";

// ---------------------------------------------------------------------------
function GetUrl( $baseurl, $script, &$plz, $param, $analyze_plz=false)
{
   $s = file_get_contents( MkUrl($baseurl, $script, $plz, $param) );
   if( empty($s))
      {  IPS_LogMessage( "WETTER_www-wetter-net_GETDATA", "can't get url content");   die;  }

   // test for multiple plz
   if( $analyze_plz && !preg_match("#k_ani([0-9]+)\.gif#U", $s) )
   {
      preg_match( '#wetter_stadt\.pl\?ID=([0-9]+)&ALIAS=(.*)"#U', $s, $m);
      if( count($m)!=3)
         {  IPS_LogMessage( "WETTER_www-wetter-net_GETDATA", "can't match PLZ");   die;   }
      $plz = "ID=".$m[1]."&ALIAS=".$m[2];

      // now retry with fixed 'plz'
      $s = file_get_contents( MkUrl($baseurl, $script, $plz, $param) );
      if( empty($s))
         {  IPS_LogMessage( "WETTER_www-wetter-net_GETDATA", "can't get url content");  die;  }
   }

   return( $s );
}

// ---
function MkUrl( $baseurl, $script, $plz, $param)
{
   $plz = str_replace( " ", "%20", $plz);  // quote possible spaces for parameter ALIAS=
   if( substr($plz,0,2) == "ID")
      return($baseurl.$script."?".$plz."&"."PARA=".$param);
   else
      return($baseurl.$script."?"."NAME=".$plz."&"."PARA=".$param);
}

// ---
function aMerge( $a_main, $a_merge)
{
   for( $i=1; $i<=3; $i++)
   {
      if( !array_key_exists( $i, $a_main)) $a_main[$i] = array();
      $a_main[$i] = array_merge( $a_main[$i], $a_merge[$i]);
   }
   return( $a_main );
}

// ---
function ParseVZustand( $s)
{
   $data = array();
   $a    = explode( "\n", $s);
   $a    = preg_grep( "#k_ani#", $a);
   $tag  = 1;
   $part = 1;
   foreach( $a as $line)
   {
      preg_match( "#k_ani([0-9]+)\.gif#U", $line, $m);
      if(count($m)==2) $data[$tag]['Zustand'.$part] = $m[1];

      preg_match( '#ALT="(.*)"#U', $line, $m);
      if(count($m)==2) $data[$tag]['Zustand'.$part.'_Text'] = $m[1];

      $part++;
      if( $part > 3)    { $tag++; $part = 1;  }
      if( $tag > 3)     { break;              }
   }
   return( $data);
}

// ---
function ParseVTemp( $s, $key)
{
   $data = array();
   $a    = explode( "\n", $s);
   $a    = preg_grep( '#class="temp"#', $a);
   $tag  = 1;
   foreach( $a as $line)
   {
      preg_match( "#>(-*[0-9]+)&deg;#U", $line, $m);
      if(count($m)==2) $data[$tag][$key] = $m[1];

      $tag++;
      if( $tag > 3)     break;
   }
   return( $data);
}

// ---
function ParseVProzent( $s, $key)
{
   $data = array();
   $a    = explode( "\n", $s);
   $a    = preg_grep( "#%#", $a);
   $tag  = 1;
   $part = 1;
   foreach( $a as $line)
   {
      preg_match( "#([0-9]+)%#U", $line, $m);
      if(count($m)==2) $data[$tag][$key.$part] = $m[1];

      $part++;
      if( $part > 3)    { $tag++; $part = 1;  }
      if( $tag > 3)     { break;              }
   }
   return( $data);
}

// ---
function ParseVWindrichtung( $s, $key, $key2)
{
   $data = array();
   $a    = explode( "\n", $s);
   $a    = preg_grep( '#/images/symbole/w#', $a);
   $tag  = 1;
   foreach( $a as $line)
   {
      preg_match( '#/images/symbole/w([0-9]+)\.gif.*TITLE="([NWSO\-]+)"#U', $line, $m);
      if( count($m)==3)
      {
         $data[$tag][$key2] = $m[1];
         $data[$tag][$key]  = $m[2];
      }

      $tag++;
      if( $tag > 3)     break;
   }
   return( $data);
}

// ---
function ParseVWindgeschwindigkeit( $s, $key)
{
   $data = array();
   $a    = explode( "\n", $s);
   $a    = preg_grep( '#>[0-9]+<br>km/h#', $a);
   $tag  = 1;
   foreach( $a as $line)
   {
      preg_match( "#>([0-9]+)<#U", $line, $m);
      if(count($m)==2) $data[$tag][$key] = $m[1];

      $tag++;
      if( $tag > 3)     break;
   }
   return( $data);
}
?>
work:=Scriptoutput
wenn work<>"" dann
	viewAusgaben:="Script-Output: "+work
endewenn
Die letzten Zeilen unten sind zum Abfangen von PHP-Ausgaben gedacht. Das Prinzip funktioniert an anderem Ort problemlos. Apropos: Das Knopf-Objekt hat noch eine Zeichen-Variable "work".

-------------------------------------
Das Originalscript ist in der z.Zt. aktuellsten Fassung hier zu finden. Hinweise / Links auf aktuellere Versionen stehen im 1. Artikel des dortigen Threads.

Als einzige Anpassung (der am DOS-Prompt laufenden Version) habe ich ab Zeile 89 die im dortigen System offenbar mögliche automatische Erkennung und ggf. Zuweisung der Ziel-Projektvariablen auskommentiert, sowie darunter eine skalare Variable per print_r zugewiesen (fehlt alles in der abgerüsteten Version, die schon den o.g. Fehler wirft, scheidet deshalb als Ursache aus!)

Code: Alles auswählen

.......

// --- SAVE INTO IPS-VARIABLE ----
#if( !IPS_VariableExists( $varname))
#{
#   IPS_CreateVariable( $varname, "String");
#}
#SetValueString( $varname, wddx_serialize_value($data) );
$a=print_r($data)."END\n";
echo $a;
//echo "END\n";
return(true);


// ---------------------------------------------------------------------------
function GetUrl( $baseurl, $script, &$plz, $param, $analyze_plz=false)
{
.......
Achja: Logischerweise ist das alles natürlich nur reines Anschauungsmaterial, wie denn sowas rein technisch gehen könnte. Denn sicher sollte man das auf gar keinen Fall so bauen und einfach andere Webseiten-Inhalte abziehen, die sicher copyrightgeschützt sind oder so! Nicht das einer noch behauptet, ich unterstütze sowas!

Gruß Gerd

Aber bitte erstmal wieder eine stabile Version hinbekommen, siehe meinen Thread von gestern bzw. das was der Familienvater so schrieb! Das ist erstmal sicher viel viel wichtiger, als das hier.

Auch zu dem Parallelverarbeitungs-Problem schweig ich erstmal noch, denn auch das braucht erstmal ein stabiles System!

Übrigens während des Verfassens dieses Textes ist wieder 2mal der LAufzeitfehler aufgetreten: TTimer bei Adresse 005A2BF2, lesen von Adresse einmal 64E9030C, einmal 5Be9030C. Alles bei nicht gestartetem Projekt, seit so 15-20min offenem Makro-Editor-Fenster mit o.g. Code
Zuletzt geändert von gwanjek am 16.01.2007, 10:08, insgesamt 2-mal geändert.

Benutzeravatar
over.unity
Beiträge: 348
Registriert: 04.01.2007, 10:20
Wohnort: Frankreich - Elsass

Beitrag von over.unity » 16.01.2007, 00:16

Könnte es sein, dass die Skript zur gleichen Laufzeit ausgeführt werden? Ab einer gewissen grösse könnte ich mir dann vorstellen, dass so was auftritt. Schreibe doch in ein File - das von Deinen BEIDEN Skripte ausgeführt wird - die Ausführzeit (Millisekunden) -> vergleiche die Zeit....


gruss
-
over.unity

Gross denken, klein beginnen

Benutzeravatar
over.unity
Beiträge: 348
Registriert: 04.01.2007, 10:20
Wohnort: Frankreich - Elsass

Beitrag von over.unity » 16.01.2007, 00:23

hmmpf, sorry, bin z.T. ein wenig kompliziert. schreibe einfach in einem Deiner Skripte zuoberst ein SLEEP("1"); hinhein.
Funktioniert nun das Ganze?


gruss
-
over.unity

Gross denken, klein beginnen

gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

Beitrag von gwanjek » 16.01.2007, 07:45

nein, es wird nur EIN Script ausgeführt!

Die zweite Code-Angabe unten ist nur ein Abschnitt mit der Modifikation des Originalscripts (siehe Link zwei Absätze darüber), um das unabhängig von der IPS-Software z.B. hier in der Studio-SW laufen lassen zu können / läuft damit auch direkt an Windows-Eingabeaufforderung aufgerufen (Aufruf per "php testscript.php"). Und natürlich habe ich das zuerst dann hier in der Studio-SW probiert, was den allerersten Fehler (einfrierendes Studio-SW-Projekt) zur Folge hatte!

Im ersten Codeblock oben ist das alles gar nicht mehr enthalten, alles rausgelöscht um potentielle Fehlerquellen auszuschließen. Dieser Code ist so wie er da steht von der Länge her genau an der Grenze zum Fehler. Ein / zwei Zeilen rausgenommen und es läuft. Das komische dabei: egal welche Zeilen! Also eindeutig kein Code- sondern Längen- oder Speichermodell-Problem!

Bei Aufruf des Projektes, in das ich das eingebettet habe, gibt es natürlich ein *INI-Objekt. Ich warte aber vor Klick auf das bewußte Knopf-Objekt extra ab, bis das fertig bearbeitet ist (enthält auch eine Ausgabe am Ende). Natürlich läuft im Projekt noch weiteres ab, z.B. sind Heizungs-Objekte und eine KS300 enthalten, die natürlich kommunizieren. Aber das sollte ja wohl naturgemäß dann möglich sein und bei "klick" läuft definitiv kein anderes Makro!

Wegen Interferenz mehrerer PHP-Scripts: Ich ging bisher davon aus, daß unterschiedliche, mit <? ... ?> gekapselte PHP-Blöcke jeweils eigene PHP-Instanzen aufrufen! Oder läuft da etwa die ganze Zeit ein Mutter-Prozeß im Hintergrund??? Kann sowas nicht im Taskmanager erkennen, wär ja auch fatal, wenn z.B. PHP-Variablen dann Instanz- und Makroüberreifend erhalten blieben, und die sich ebenfalls gegenseitig überschreiben würden, wie es schon die Makrovariablen der Studio-SW tun. Dann würd ja z.B. auch keine PHP-Webseite mit Datenbankarbeit von mehr als einem Besucher gleichzeitig stabil benutzbar sein, denn das wäre ja dann das gleiche Problem....

Das PHP-Skripts ab einer gewissen Größe sich gegenseitig beeinflussen kann ich mir nicht nur NICHT vorstellen, sondern das DARF definitiv niemals so sein, und ist es auch nicht, wie hunderttausende Anwendungen weltweit mit erheblich komplexeren Anwendungen als diese paar hundert Zeilen täglich beweisen. Stichworte: Shoppingsysteme, Banking, komplexe Intranetsysteme..... Womit wir eigentlich wieder beim leidigen Thema der stochastisch initiierten Parallelprozesse in der Studio-SW wären...

Aber wie gesagt, es läuft nur EIN Script und stürzt ab gewisser Größe reproduzierbar(!) ab.

Wen ich heute abend wieder zu Hause bin, probier ich trotzdem mal das SLEEP. Hier im Büro mangelts mir im Moment dazu an FHZ-Umgebung :-)

Gruß Gerd

gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

Beitrag von gwanjek » 16.01.2007, 22:20

Hallo over.unity,
der Sleep-Befehl bringt leider auch nichts.

Habe noch zwei andere Sachen probiert:
- die -zwar nie aufgerufene- aber dennoch hier fehlende Funktion "IPS_LogMessage" ergänzt, ganz unten als weitere function angehängt:

Code: Alles auswählen

.......
// ---
function IPS_LogMessage( $aaa, $bbb)
{
	echo $aaa.": ".$bbb."\n";
}
?>
......
Kein Erfolg. Friert weiter ein / weiter oben irgendwelchen Code rausgenommen (einige der anderen Functions): läuft.

Zweiter Test (nu kommts!)

Anderes neues minimalisiertes Projekt, völlig abgerüstet, lediglich als Module ein Unterputsschalter, eine Schaltsteckdose, und eine KS300 aufgenommen ohne irgendwelchen sonstigen Firlefanz, dazu eine Uhr (Makro-Inhalt: Uhr:=UHRZEIT) um zu sehen, daß da überhaupt was läuft. Alles direkt in eine Ansicht aufgenommen.

Dazu dann das o.g. Zeichenobjekt "viewAusgaben" sowie den Knopf "calcVorhersage" mit dem bewußten Makro aufgenommen: GLEICHER FEHLER!

Genauer:
zuerst ging es, mit genau dem oben in meinem ersten Artikel als Codeblock aufgeführten Script.

Dann auch hier die Function "IPS_LogMessage" ergänzt (siehe Codeblock oben in DIESEM Artikel): Fehler! Projekt friert sofort bei Tasten-Klick ein!

Dann die Quelle etwas verkleinert, also ein anderes Stückchen Code rausgenommen (die vorletzte Function "ParseVWindgeschwindigkeit" komplett rausgelöscht): Script läuft!

Also wenn DAS jetzt nicht nachvollziehbar ist!

Achso, ich habe die Studio-SW in Rel 70107 laufen. Habe darauf am Wochenende geupdated nach den im anderen Thread beschriebenen Abstürzen und Projektverlusten unter 61210. Heute habe ich gesehen, das auf der Contronics-Download-Seite wieder die 71106 steht, zumindest in den Texten der Kästchen mit den Modulen! Ist die 70107 nun zurückgezogen??? Läuft die 70106 denn nun stabil? Muß/soll ich downgraden?

Gruß Gerd
Zuletzt geändert von gwanjek am 16.01.2007, 23:22, insgesamt 1-mal geändert.

Benutzeravatar
over.unity
Beiträge: 348
Registriert: 04.01.2007, 10:20
Wohnort: Frankreich - Elsass

Beitrag von over.unity » 16.01.2007, 23:07

hmm, da weiss ich auch nicht mehr weiter. Also ich habe die xx05 Version, die läuft einwandfrei. Ich würde die Version installieren, welche auf der Contronics Seite angeboten wird.


gruss
-
over.unity

Gross denken, klein beginnen

gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

Beitrag von gwanjek » 16.01.2007, 23:20

würd ich auch, wenn es da nicht noch das andere Laufzeitfehler-Problem gäbe, das schon zumindest seit 61210 existiert. Ist das da nun beseitigt?

Das Laufzeitproblem halte ich sogar noch für einen Tick wichtiger als das hier (was für sich natürlich schlimm genug ist), denn ohne eine stabil laufende SW geht gar nix.

Gruß Gerd

contronics-RK
Beiträge: 954
Registriert: 18.07.2006, 15:58

Beitrag von contronics-RK » 18.01.2007, 12:10

Es gibt eigentlich keine Grössenbeschränkung bei den PHP-Scripts.
Einzige Beschränkung: Das Makro darf insgesamt nicht länger als eine Sekunde aktiv sein, sonst wird es abgebrochen.
Bei Versuch das fragliche Script auszuführen hängte sich das Programm nicht auf, aber es kam die Fehlermeldung:
Error calling PHP-Script in ...
Diese kommt wenn der PHP-Interpeter die Scriptausführung ohne weitere Fehlermeldung/information abbricht.
Es darf nur die Version des PHP-Interpreters verwendet werden, die auf unseren Donloadseiten steht, bei anderen Versionen kann es zu unvorhersehbaren Fehlern kommen.

Ich hoffe diese Infos helfen weiter.

Mit freundlichem Gruss
contronics - Ralph Krapoth

gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

Beitrag von gwanjek » 18.01.2007, 16:51

contronics-RK hat geschrieben:Es gibt eigentlich keine Grössenbeschränkung bei den PHP-Scripts.
Einzige Beschränkung: Das Makro darf insgesamt nicht länger als eine Sekunde aktiv sein, sonst wird es abgebrochen.
Das Script hängt wie beschrieben an einem Knopf-Element. Das Einfrieren passiert unmittelbar bei Klick mit der Maus auf den Knopf. Der Effekt ist nachweislich von der Größe und NICHT vom Code-Inhalt und NICHT vom Projekt-Inhalt abhängig.
contronics-RK hat geschrieben: Bei Versuch das fragliche Script auszuführen hängte sich das Programm nicht auf, aber es kam die Fehlermeldung:
Error calling PHP-Script in ...
Diese kommt wenn der PHP-Interpeter die Scriptausführung ohne weitere Fehlermeldung/information abbricht.
Es darf nur die Version des PHP-Interpreters verwendet werden, die auf unseren Donloadseiten steht, bei anderen Versionen kann es zu unvorhersehbaren Fehlern kommen.
Es gibt auf dem ganzen System nur den PHP-Interpreter von der Downloadseite. Bei Aufruf direkt am Windows-Eingabe-Prompt (D:\Scripts>\php test.php), also mit dem GLEICHEN PHP-Interpreter, läuft das Script fehlerlos durch.

Oder hat sich auf den Downloadseiten die PHP-Version geändert, und dort Anfang Dezember heruntergeladene Version ist jetzt nicht mehr gültig?
contronics-RK hat geschrieben:Ich hoffe diese Infos helfen weiter.
Leider nicht wirklich :-(

Gruß Gerd

gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

Beitrag von gwanjek » 29.01.2007, 11:32

Hallo,
ich habe am Wochenende mal etwas weiter probiert, um andere Fehlerquellen auszuschließen:
  • anderer PC (Laptop, HP Notebook)
  • anderes System (XP statt Win2K-Server)
  • keine von dort übernommene SW, alles neu gezogen und installiert
--> Gleicher Fehler

Möglicher Ansatz zur Ursachenbehebung:
Kann es sein, daß eine (Standard)-PHP-Installation die Ursache ist? Also, ich habe wie in der Online-Hilfe beschrieben, die beiden PHP-Programme im Verzeichnis der SW (C:\programme\contronics\...usw) stehen.

Wo aber bleiben die restlichen PHP-Bestandteile?
- wie bei mir und wie PHP üblich z.B. unter C:\PHP inkl. einer System-Suchvariable darauf?

- oder soll das auch mit in das Verzeichnis der FHZ-Software?

Wie gesagt, es gibt nur dieses eine PHP systemweit und direkt am Prompt ("Eingabeaufforderung") per "php abc.php" aufgerufen, funktioniert das Script auch fehlerlos!

Muß ich jetzt wirklich erst nen Reassembler rauskramen, um die SW-interne Speicherverletzung zu lokalisieren?

Gruß Gerd

Antworten

Zurück zu „homeputer Studio / Standard: Bugs & Updatewünsche“