C-Pointer in BlitzMax

Übersicht BlitzMax, BlitzMax NG Beginners-Corner

Neue Antwort erstellen

Midimaster

Betreff: C-Pointer in BlitzMax

BeitragMo, Apr 19, 2021 11:10
Antworten mit Zitat
Benutzer-Profile anzeigen
Wenn ich in BlitzMax eine C-Function rufe, und diese C-Funktio gibt mir einen Pointer auf eine STRUCT zurück... Ist dann der RAM-Bereich dieser STRUCT schon dadurch in seiner vollen Länge geschützt, das ich mir in BlitzMax den Pointer als Byte PTr merke? Oder muss ich noch die Länge der STRUCT in Erfahrung bringen und durch eine TBANK den RAM-Bereich schützen?
Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

Thunder

BeitragDi, Apr 20, 2021 12:27
Antworten mit Zitat
Benutzer-Profile anzeigen
BlitzMax Pointer sind genauso unsicher wie Pointer in C. Der Pointer ist nur die Start-Adresse, ein Zugriff außerhalb der Grenzen des allozierten Speichers muss vermieden werden.
Dazu muss aber keine TBank verwendet werden, es reicht wenn du nur Speicher dereferenzierst der innerhalb des structs liegt. Du kannst dir die Größe des structs in eine exportierte Variable schreiben oder von einer Funktion zurückgeben, oder (solange das struct unverändert bleibt) die Größe mit printf und sizeof auslesen und konstant in BlitzMax hardcoden.
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Midimaster

BeitragDi, Apr 20, 2021 12:52
Antworten mit Zitat
Benutzer-Profile anzeigen
Thunder hat Folgendes geschrieben:
...
Dazu muss aber keine TBank verwendet werden, es reicht wenn du nur Speicher dereferenzierst der innerhalb des structs liegt. Du kannst dir die Größe des structs in eine exportierte Variable schreiben oder von einer Funktion zurückgeben, oder (solange das struct unverändert bleibt) die Größe mit printf und sizeof auslesen und konstant in BlitzMax hardcoden.


Ah, Ok das war eine der Sachen die ich nicht wußte. Hätte ja sein können das BlitzMax alleine dadurch, dass es eine Pointer-Adresse mitgeteilt bekommt, gar nicht weiß wie groß die Struktur ist, die sich daran anschließt. Deshalb mein Versuch das Ganze mit einer CreateStaticBank auch in BlitzMax zu sichern.

Nun brauche ich es also nicht.

die Größe weiß ich bereits mittel sizeof() im C-Teil. Deshalb ja auch die TBank mit 24.000 Byte. Die Struct selbst ist fix und hat etwas 22700 Bytes.
GottseiDank muss ich sie (und ihre Elemente) auch gar nicht in BlitzMax ansprechen. Mein einziger Job besteht darin den RAM-Bereich vor BlitzMax-GC zu schützen.

danke erst mal.
Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

DAK

BeitragDi, Apr 20, 2021 16:07
Antworten mit Zitat
Benutzer-Profile anzeigen
Schützen gibt es mit Pointern eh nicht wirklich. Pointers haben keine Ahnung von den Daten die da liegen und können machen was sie wollen.

Solange die Daten noch nicht wieder dealloziert wurden und man kein Multithreading verwendet, gibt es da nicht wirklich was zu beachten, außer dass man nicht aus dem allozierten Bereich rausschreiben darf.
Gewinner der 6. und der 68. BlitzCodeCompo

Thunder

BeitragDo, Apr 22, 2021 1:20
Antworten mit Zitat
Benutzer-Profile anzeigen
DAK hat Folgendes geschrieben:
außer dass man nicht aus dem allozierten Bereich rausschreiben darf.


Lesen auch nicht! Smile
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

DAK

BeitragDo, Apr 29, 2021 14:04
Antworten mit Zitat
Benutzer-Profile anzeigen
Lesen kann man schon. Kriegt man hald Blödsinn zurück, aber weh tun wird es nicht. Im Gegensatz zum Schreiben.
Gewinner der 6. und der 68. BlitzCodeCompo
 

ohaz

BeitragDo, Apr 29, 2021 14:16
Antworten mit Zitat
Benutzer-Profile anzeigen
Tut sehr wohl weh. Da können super relevante Daten drin sein. Siehe Heartbleed.

Thunder

BeitragFr, Apr 30, 2021 0:17
Antworten mit Zitat
Benutzer-Profile anzeigen
Nein ehrlich, ganz abgesehen von Security-Bedenken (die auch valide sind):

Man darf prinzipiell keine Pointer zu nicht allozierten Speicherbereichen dereferenzieren. Also Speicher lesen oder schreiben, der nicht alloziert ist. Lesen oder Schreiben macht keinen Unterschied, denn es kann sein, dass die zugegriffene Page nicht in den physischen Speicher gemappt ist, und dann gibt es einen Page Fault, der ist unabhängig davon, ob es sich um einen Lese- oder Schreibzugriff handelt.
Und wenn das Betriebssystem dann draufkommt, dass der Speicherbereich (die Page) nicht alloziert war, wird das Programm gekillt.

Hier ist ein Screenshot von einem Beispiel aus Visual Studio: https://www.blitzforum.de/upload/file.php?id=13457

In dem Fall hatte ich den Debugger eingeschaltet, der sagt mir was das Problem ist. Wenn ich das Programm in Release mode builde und in cmd ausführe, gibt es einfach Hello aus und wird beendet.
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Midimaster

BeitragFr, Apr 30, 2021 14:31
Antworten mit Zitat
Benutzer-Profile anzeigen
Derzeit ist ja der Zustand meines wrappers so, dass er im RELEASE perfekt (grins) läuft, aber im DEBUg mode konsequent abstürzt. allerdings ohne jeden Hinweis auf die Ursache. Die Meldung ist "EXCEPTION_ACCESS_VIOLATION", mehr nicht!

Heisst das im Umkehrschluss, das wahrscheinlich im C-Teil meines Programms ein Fehler ist, wenn die App ausschließlich im DEBUG mode abstürzt?

Sind Situationen denkbar, wo tatsächlich ausschließlich der DEBUGGER die Ursache für einen Absturz ist, oder weißt auch sowas IMMER auf einen Programmierfehler hin?
Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

Farbfinsternis

BeitragFr, Apr 30, 2021 15:46
Antworten mit Zitat
Benutzer-Profile anzeigen
Das ist alles schon ewig her, aber ich meine ich habe damals die Structs in BlitzMax "nachgebaut" und dann das Integer-Handle mittels "HandleToObject" in ein Type konvertiert:
Code: [AUSKLAPPEN]

Function HandleToObject:Object( handle:Size_T )
Returns The object associated with the integer handle 
Description Convert integer handle to object

Da müsst ich mich aber erstmal wieder komplett rein friemeln um was Genaueres sagen zu können. Definitiv ist es aber so dass ich nie mit Pointern und deren Offsets gearbeitet habe, weil mir das viel zu weird und gefährlich war.
Farbfinsternis.tv

Thunder

BeitragSa, Mai 01, 2021 11:50
Antworten mit Zitat
Benutzer-Profile anzeigen
Midimaster hat Folgendes geschrieben:
Heisst das im Umkehrschluss, das wahrscheinlich im C-Teil meines Programms ein Fehler ist, wenn die App ausschließlich im DEBUG mode abstürzt?


Ja. Es kann aber auch im BlitzMax Code sein. EXCEPTION_ACCESS_VIOLATION heißt genau, dass auf Speicher zugegriffen wird, der nicht alloziert ist. Siehe: https://docs.microsoft.com/en-...ion_record
Aber da es nur im Debug Mode auftritt und keine Fehlermeldung vom Debugger kommt, deutet das eher auf den C-Code oder vielleicht den Wrapper.

Midimaster hat Folgendes geschrieben:
Sind Situationen denkbar, wo tatsächlich ausschließlich der DEBUGGER die Ursache für einen Absturz ist, oder weißt auch sowas IMMER auf einen Programmierfehler hin?


Ja, sind denkbar. Aber das würde bedeuten, dass der Debugger oder Compiler fehlerhaft ist. Die Frage ist also: Ist der Fehler im Debugger/Compiler oder in deinem Programm? Üblicherweise vertraut man dem Debugger und dem Compiler... auch wenn in BlitzMax zumindest ein bekannter Fehler existiert bei der Kompilierung von Try-Catch Blöcken. Ich habe Mal darüber geschrieben: https://www.blitzforum.de/worklogs/564/#3839
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Neue Antwort erstellen


Übersicht BlitzMax, BlitzMax NG Beginners-Corner

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group