Break in Quad-Select in Schleife in Prozedur = Crash

Hier werden, insbesondere in den Beta-Phasen, Bugmeldungen gepostet. Das offizielle BugForum ist allerdings hier.
Benutzeravatar
Regenduft
Beiträge: 574
Registriert: 25.03.2008 15:07
Wohnort: THE LÄÄÄND!

Break in Quad-Select in Schleife in Prozedur = Crash

Beitrag von Regenduft »

Sorry, für den Total bescheidenen Titel, wenn mir jemand 'ne gute Formulierung gibt ändere ich's sofort!

Win XP - PB 4.30 x86

Ich weiß ganicht wie ich's in Worte fassen soll. Am besten ist wohl ein kommentierter Quell-Code:

Code: Alles auswählen

Procedure abc(quady.q)
  
  Repeat

    Select quady ; <- This is causing the crash! Using e.g. a long will
                 ;    work fine. I originally used a "FileSize" here, so it
                 ;    doesn't depend on the usage of a parameter.

    Case 0
      Debug "case 0 -> no error" ; (no break = no error)

    Case 1
      Debug "case 1 -> ERROR!"
      Break
  
    Default
      Debug "case 2 -> ERROR!"
      Break

    EndSelect

    Break

  ForEver
  
EndProcedure ; <- here is where the "Invalid memory
             ;    access. (write at address 0)" appears
abc(0)
abc(1)
abc(2)
Das ganze Tritt scheinbar nur in genau dieser Konstelation auf! Keine Schleife; kein Fehler. If statt Select; kein Fehler. Long statt Quad; kein Fehler. usw. usf.

Kann den jemand reproduzieren?
PureBasic 5.73 LTE x86/x64 | Windows 7 (x64)
Benutzeravatar
milan1612
Beiträge: 810
Registriert: 15.04.2007 17:58

Beitrag von milan1612 »

Jupp, is reproduzierbar. Poste das ganze mal im englischen Forum, hier bringts nix.
Bin nur noch sehr selten hier, bitte nur noch per PN kontaktieren
Benutzeravatar
cxAlex
Beiträge: 2111
Registriert: 26.06.2008 10:42

Beitrag von cxAlex »

Liegt am Quad:

http://www.purebasic.fr/german/viewtopi ... c&start=40

Lösung:

Code: Alles auswählen

Macro FakeEndSelect
  CompilerIf #PB_Compiler_Processor = #PB_Processor_x86 
    !POP dword[ESP]
   CompilerEndIf
EndMacro

Procedure abc(quady.q)
 
  Repeat
    Select quady 
    Case 0
      Debug "case 0 -> no error"
      
    Case 1
      Debug "case 1 -> ERROR!"
      FakeEndSelect
      Break
 
    Default
      Debug "case 2 -> ERROR!"
      FakeEndSelect
      Break
      
    EndSelect

    Break
  ForEver
  
EndProcedure
abc(0)
abc(1)
abc(2)
Kann jetzt nicht sagen ob das ein Bug ist, aber es liegt am Stack, da ein Quad unter 32 Bit 2 Anweisungen braucht. Unter 64 Bit sollte es gehen.

Gruß, Alex
Projekte: IO.pbi, vcpu
Pausierte Projekte: Easy Network Manager, µC Emulator
Aufgegebene Projekte: ECluster

Bild

PB 5.1 x64/x86; OS: Win7 x64/Ubuntu 10.x x86
Benutzeravatar
Regenduft
Beiträge: 574
Registriert: 25.03.2008 15:07
Wohnort: THE LÄÄÄND!

Beitrag von Regenduft »

Danke fürs testen

@ milan1612: Ich poste Bugs immer erst hier und nach 'ner Bestätigung ins englische Forum, aber trotzdem Danke für den Hinweis.

@ cxAlex: Uuups? (Habe mir noch nicht den ganzen von Dir gelinken Thread durchgeschaut) Heißt das Break ist sozusagen "eine Art" GoTo? Muss man das genauso vorsichtig handhaben? :shock:
Kurz: Ist das ein Fehler meinerseits?

Allgemein ist mir aber aufgefallen (ja... war wohl wieder zu blöd die SF richtig zu benutzen), dass es einen Bug mit Quads und Select seit PB 4.02 und immernoch gibt:
http://www.purebasic.fr/german/viewtopi ... 253#168253
Wenn ich einen der dortigen codes (link) kompiliere, crasht mir sogar die gesamte IDE! (und laut Thread läuft's auf Mac problemlos...)

*nixblick* :oops:
PureBasic 5.73 LTE x86/x64 | Windows 7 (x64)
Benutzeravatar
cxAlex
Beiträge: 2111
Registriert: 26.06.2008 10:42

Beitrag von cxAlex »

Hm, scheint dann echt ein Bug zu sein.

Dann mal ab damit ins Englische Forum damit der in 4.4 raus ist !

PS: Ja, Break ist eine Art GoTo.
Projekte: IO.pbi, vcpu
Pausierte Projekte: Easy Network Manager, µC Emulator
Aufgegebene Projekte: ECluster

Bild

PB 5.1 x64/x86; OS: Win7 x64/Ubuntu 10.x x86
Benutzeravatar
milan1612
Beiträge: 810
Registriert: 15.04.2007 17:58

Beitrag von milan1612 »

cxAlex hat geschrieben:PS: Ja, Break ist eine Art GoTo.
Wobei bei Break im Gegensatz zu Goto der Compiler fuers Aufraeumen zustaendig ist :lol:
Bin nur noch sehr selten hier, bitte nur noch per PN kontaktieren
Benutzeravatar
Regenduft
Beiträge: 574
Registriert: 25.03.2008 15:07
Wohnort: THE LÄÄÄND!

Beitrag von Regenduft »

:freak: Gnarf... Ihr 2 macht mich noch ganz duselig im Kopf! :wink: (vielleicht war's aber auch der gelinkte GoTo-Killer-Thread :lol:)
PB-Doku hat geschrieben:Hinweis: Um eine Schleife sicher zu verlassen, sollten Sie immer Break anstelle von Goto verwenden.
und zur Sicherheit nochmal das englische Original:
PB-Doc hat geschrieben:Note: To exit a loop savely, you always should use Break instead of Goto.
(wobei da jetzt kein Wort über Bedingungen steht)
cxAlex hat geschrieben:PS: Ja, Break ist eine Art GoTo.
milan1612 hat geschrieben:Wobei bei Break im Gegensatz zu Goto der Compiler fuers Aufraeumen zustaendig ist :lol:
Na also... dann ist es nicht das selbe in grün... sondern eher das gleiche in lila-blassblau mit orangen Hippie-Gummiegänseblümchen drauf... oder so...
Ich post's jetzt in englische forum.
PureBasic 5.73 LTE x86/x64 | Windows 7 (x64)
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag von Kaeru Gaman »

die Erklärung von netmaestro erscheint mir einleuchtend:

das Break springt aus der Schleife ohne das Select korrekt zu beenden.

so gehts:

Code: Alles auswählen

Procedure abc(quady.q)
 
  Repeat

    Select quady ; <- This is causing the crash! Using e.g. a long will
                 ;    work fine. I originally used a "FileSize" here, so it
                 ;    doesn't depend on the usage of a parameter.

    Case 0
      Debug "case 0 -> no error" ; (no break = no error)

    Case 1
      Debug "case 1 -> ERROR!"
      EXIT = 1
 
    Default
      Debug "case 2 -> ERROR!"
      EXIT = 1

    EndSelect

      EXIT = 1

  Until EXIT
 
EndProcedure ; <- here is where the "Invalid memory
             ;    access. (write at address 0)" appears
abc(0)
abc(1)
abc(2)

kann sein, dass das Break zwar prüft, ob es in einem select steckt,
dann aber davon ausgeht, dass es sich um ein LONG-select handelt.
deswegen schafft das zusätzliche LONG-POP von cxAlex abhilfe.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Benutzeravatar
AND51
Beiträge: 5220
Registriert: 01.10.2005 13:15

Beitrag von AND51 »

Das Problem gab es schon vor mindestens einem Jahr und wurde unter anderem breits von mir gepostet, als ich 'entdeckte', dass man auch mit ProcedureReturn nicht aus einem Select-Block springen darf (gleiches Stack-Problem). Ich hatte das Problem bereits zu 3.94er Zeiten, als es noch keine Quads gab.
PB 4.30

Code: Alles auswählen

Macro Happy
 ;-)
EndMacro

Happy End
tranquil
Beiträge: 117
Registriert: 22.09.2004 22:07
Kontaktdaten:

Beitrag von tranquil »

AND51 hat geschrieben:Das Problem gab es schon vor mindestens einem Jahr und wurde unter anderem breits von mir gepostet, als ich 'entdeckte', dass man auch mit ProcedureReturn nicht aus einem Select-Block springen darf (gleiches Stack-Problem). Ich hatte das Problem bereits zu 3.94er Zeiten, als es noch keine Quads gab.
Darf man nicht? Verdammt! Warum wird das nirgends dokumentiert? Ich bin davon ausgegangen das ProcedureReturn den Stack, egal wo ich aus der Prozedure springe, aufräumt. :-/

Wozu haben wir denn nun die Compiler warnings wenn soetwas nicht gewarnt wird? Nun heißt es Sources überarbeiten..... :P
Antworten