| |
| |
|
Uwe
''Pascal''
Niemeier | Hallo Leute, hallo Roland!
Dieser kleine Code verursacht als prc oder exe bei mir (XP) einen Programmabsturz:
KompilierenMarkierenSeparieren!
window 50,50-400,400
declare Edit&
Edit&=create("RichEdit",%hwnd,"Test",10,50,100,100)
RTF("SaveText",Edit&,"Test.txt")
waitkey
Gibts da irgendwo einen Speicher-Überlauf oder so?
Durch Einfügen von Leerzeilen (!) vor dem Kompilieren klappts nämlich manchmal.
Mit call(&OpenText... gibt es keine Probleme.
Scheint allerdings schon seit Profan 7.9 so zu sein... Ich glaub, das wurde schonmal angemahnt 
SeeYou
Pascal |
|
| |
| |
| |
|
|
 | | Hm bei mir funktionierts ohne Absturz als interpeter prc und exe, X10RC6 & XPHome. |
|
| |
| |
| |
|
|
 | Wo Leerzeilen? Bei mir stützt es auch ab:
Windows98 SE |
|
| |
| |
| |
|
|
| | Datei wird ohne Probleme gespeichert - Inhalt: das Wort Text |
|
| |
| |
| |
|
|
| Das hängt vom jeweilgen System ab und ob dort gerade der nachfolgende virtuelle Speicher realem Speicher zugeordnet wurde oder nicht => scheint ein Speicherüberlauf zu sein  .
Ich hab mir den Fehler mal mit TNT angesehen. Die Adresse vor der Adresse ist noch zugewiesen und enthält Daten. |
|
| |
| |
| |
|
|
RGH | Endlich mal ein Beispielcode mit diesem ominösen RTF-Bug, der auch bei mir abstürzt ... und nur wenige Stunden später (Ich war schon am Aufgeben ...), konnte ich diesen Bug endlich dingfest machen!
An einer Stelle wurde bei RTF() ein Speicherzugriff gemacht, der nicht sein sollte. Und je nachdem, in welchem Zustand sich der Rechner gerade befindet, geht es in die Hose oder eben nicht. So hatte ich den Effekt, daß es nur knallte, wenn ich vor dem Compilieren und Starten gefragt wurde, ob ich speichern will und wenn der Text im Richedit größer als zwei Zeichen war.
Naja, jetzt ist zwar der Abend fast rum, aber dieses Problem ist nun auch behoben!
Gruß
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 25.09.2006 ▲ |
|
| |
|
|
| Moin...
Wie gesagt, hängt damit zusammen, ob der Speicher auf den da zugegriffen werden soll, zugewiesen ist oder nicht. Ob der zugewiesen ist oder nicht, hängt u.a. von den Umgebungsvariablen (z.B. Pfad) des Programmes ab. Auch vorher abgelaufene (Speicher-)operationen im Programm spielen da mit rein.
Ein sehr mieser Fehler, da in der Regel das Programm nicht abstürzt und nur Daten im Speicher überschrieben werden.
Ich habe seit etwa drei Jahren den Eindruck, das da irgendwo noch so etwas in der Art rumfleucht... |
|
| |
| |
| |
|
|
RGH | [quote:7b2a2cf450=Andreas Hötker]Ein sehr mieser Fehler, da in der Regel das Programm nicht abstürzt und nur Daten im Speicher überschrieben werden.
Ich habe seit etwa drei Jahren den Eindruck, das da irgendwo noch so etwas in der Art rumfleucht... [/quote:7b2a2cf450]
Wie ich bereits vor ca 15 Stunden schrieb: Der Fehler ist gefunden und definitiv in XProfan 10 behoben! Ihr braucht Euch also keine Gedanken mehr darum zu machen, sonder einfach auf die nächste Version warten! ;)
Gruß
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 26.09.2006 ▲ |
|
| |
|
|
| Hallo Roland...
Ist klar, das meinte ich nicht  . Ich habe seit etwa drei Jahren ein Problem, das sich eigentlich ganz ähnlich äußert - mit dieser Funktion und speziell mit diesem Problem aber nichts zu tun hat!
Seit mein Quelltext die 12000 Zeilen überschritten hat  , wird zeitweise eine sehr kritische API nicht richtig ausgeführt. Ob der Fehler auftritt oder nicht hängt u.a. davon ab, welche Bedienungsschritte der User vorher unternommen hat, wie groß der Quelltext zur Zeit ist, auf welchem Rechner das Programm läuft und ob es compiliert ist oder nicht. Ich möchte nicht unbedingt behaupten, daß der Fehler an Profan liegt - ich möchte dich aber bitten, es vielleicht irgendwo im Hinterkopf zu behalten, das das so sein könnte.
´Gruß
Andreas |
|
| |
| |
| |
|
(1.140)
Deutsch
English
Français
Español
Italia