OpenGL 3.2 dans Delphi 2009 en utilisant FastMM 4.97 problème avec les UBOs dans FullDebugMode

Question

Je suis assis avec une application OpenGL 3.2 dans Delphi 2009. Lorsque vous utilisez FastMM 4.97 avec FullDebugMode défini, les UBO ne reçoivent pas leurs données correctement. Avec FullDebugMode indéfini tout fonctionne comme un charme.

Exemple: Définition des dimensions de la fenêtre pointant vers deux champs d'entiers privés, FWidth et FHeight, dans notre classe de cadres de rendu. Cela fait maintenant quelques jours que j'arrache les cheveux à cette question et je ne sais vraiment pas comment procéder. Je ne m'attends pas à un support complet d'OpenGL ici mais j'espère que quelqu'un peut venir avec une suggestion basée sur des différences connues entre l'exécution de FullDebugMode et non.

Paramètres du projet:

[Compiling] 
Optimization False 
Stack frames True 
Use debug .dcus True 
[Linking] 
Debug info  True 
Map file  Detailed 

OS est Windows 7 64 bits.

Édition: Trouvé! Il n'avait rien à voir avec OpenGL. Ailleurs dans notre base de code, une fonction a retourné un PAnsiChar en utilisant Result := @AnsiString(Object.Name)[1]; Cela fonctionnait normalement la plupart du temps puisque la mémoire était seulement libérée mais inchangée. Dans FullDebugMode, les données ont été remplacées par une séquence de 80 $ lorsqu'elles ont été libérées.

Answer 1

Vous recherchez probablement une mémoire qui a été libérée prématurément (par votre propre application).

Normalement, vous pouvez toujours accéder aux anciennes valeurs jusqu'à ce qu'elles soient remplacées par une nouvelle allocation + écritures. Cela pourrait très bien permettre à votre application de fonctionner correctement, même si vous accédez à des parties de mémoire obsolètes. Cependant, dans FullDebugMode, la mémoire désallouée est remplie avec une séquence octet 80 $. Vous pouvez facilement vérifier cela si vous connaissez l'appel exact de glBufferSubData qui casse, regardez simplement la mémoire à ce moment-là.