Seite 1 von 1

AllocateMemory - Interessantes Hintergrundwissen

Verfasst: 04.12.2009 04:00
von STARGÅTE
Tachchen,

ich hatte mal wieder n Bug in meinem Programm, als ich ihn gefunden habe, und ein paar tests gemacht habe. Sind mir folgende Dinge aufgefallen:

Wenn ich ein Speicher erstelle bleiben hinter oder vor dem Speicher immer 8 bis 16 Bytes frei
Es wird dabei immer auf ganze Quads erweitert.

Code: Alles auswählen

Structure Test
 Pos.l[0]
EndStructure

For n = 1 To 20
 *Pointer.Test = AllocateMemory(n)
 If *OldPointer
  Debug "'Freiraum' : "+Str(*Pointer-*OldPointer-MemorySize(*OldPointer))
 EndIf
 Debug "Pointer: "+Str(*Pointer)+" - Länge "+Str(n)
 *OldPointer = *Pointer
Next
Die Frage nun was steht in den 8 Bytes die "so zu sagen" unnötig frei bleiben,
Keine Ahnung

Wenn man aber zB noch ein stück weiter geht so passiert folgendes:
Hier schreibe ich genau an die Stelle etwas an der das nächste AllocateMemory seinen Pointer hätte!
16+8 = 24

Code: Alles auswählen

*Pointer = AllocateMemory(16)
Debug MemorySize(*Pointer)
Irgendwas = 996
PokeL(*Pointer+24, Irgendwas)
*Pointer2 = AllocateMemory(16)
Debug MemorySize(*Pointer2)
Nun komm ein Fehler beim nachfolgedem AllocateMemory : Lesefehler an der Adresse 1000
also immer genau 4 mehr als meine Variable Irgendwas

Und nun stell ich fest das immer hinter dem aktuellen AllocateMemory mit Freiraum die selbe Zahl steht:

Code: Alles auswählen

Structure Test
 Pos.l[0]
EndStructure


For n = 1 To 20
 *Pointer.Test = AllocateMemory(n)
 If *OldPointer
  Freiraum = *Pointer-*OldPointer-MemorySize(*OldPointer)
  Debug "'Freiraum' : "+Str(Freiraum)
 EndIf
 Debug "Pointer: "+Str(*Pointer)+" - Länge "+Str(n)
 *OldPointer = *Pointer
 If Not Freiraum%8
  Debug "  Dahinter: "+Str(PeekL(*Pointer+Freiraum+n-1+8))
 Else
  Debug "  Dahinter: "+Str(PeekL(*Pointer+Freiraum+n-1))
 EndIf
Next
Mir stellt sich jetzt die Frage wieso ?
Eine art Header für alle erstellten Memorys ?
Gibs dort Vielleicht auch n Liste die alle MemoryPointer enthält ?
Wenn ja, könnte man damit seine Speicher (ohne (eigene) LinkedList) überwachen ...

Ich bin noch nicht weiter zum Nachforschen gekommen ...
Vielleicht weiß einer mehr darüber ...

zumindest weiß ich das an dieser Pointer, der Wert für den nächsten kommenden AllocateMemory steht, deswegen sollte man den nicht löschen oder überschreiben, da es sonst zu einem fehler kommt den man bis nicht erklären kann... wie oben gezeigt ... das AllocateMemory() versagt ...

Re: AllocateMemory - Interessantes Hintergrundwissen

Verfasst: 04.12.2009 04:20
von freak
> Die Frage nun was steht in den 8 Bytes die "so zu sagen" unnötig frei bleiben,

Management-Informationen des Heaps (Windows intern).

> Nun komm ein Fehler beim nachfolgedem AllocateMemory : Lesefehler an der Adresse 1000

Das nennt sich dann "heap corruption". Mehr dazu hier: http://www.purebasic.fr/blog/?p=55

> Gibs dort Vielleicht auch n Liste die alle MemoryPointer enthält ?

Dazu gibt es HeapWalk_(). Ist aber nur zu Debug-Zwecken gedacht, nicht als LinkedList oder so:
http://msdn.microsoft.com/en-us/library/aa366710.aspx

Re: AllocateMemory - Interessantes Hintergrundwissen

Verfasst: 04.12.2009 04:34
von STARGÅTE
Cool danke freak,

genau solche Infos wollte ich haben ...

Re: AllocateMemory - Interessantes Hintergrundwissen

Verfasst: 15.03.2011 00:03
von SebastianJu2
Ja danke Freak... war hilfreich... ein Byte zu wenig im AllocateMemory() und es gab die Probleme die deine Funktion finden kann. Wäre ich sonst nicht draufgekommen da das Problem ja wirklich an einer anderen Stelle lag... Aber zufällig Lese- und Schreibfehler und ab und zu geht es haben gepasst als Problembeschreibung.