2016-06-13 29 views
0

Ich baue meine x64 Python c Bibliothekserweiterung von x86 eins.Fread mit fopen64 unter MinGW64 tötet den Prozess

Ich fand heraus, fread mit einem Dateizeiger von fopen64 opend tötete den Python-Prozess aufgrund eines Fehlers APPCRASH von ntdll.dll. Es passiert nicht unter x86-Build und passiert auch nicht, wenn der Dateizeiger von geöffnet wird.

Zuerst dachte ich, es passiert wegen Windows-Fehler here erwähnt. Aber es hat es nicht behoben.

Gibt es eine gute Praxis, um dieses Problem zu vermeiden? Ich überlege, dass Definition zu wählen, Hexe Datei öffnen Funktion verwendet wird, so dass es sowohl unter x64 und x86 arbeiten kann, aber ich habe keine wunderbaren Ideen, dies zu tun.

Meine Umwelt

  • Windows 7 x64
  • Python 2.7.10 x64
  • Numpy 1.11.0
  • MinGW64
+0

Sieht aus wie [fopen64 ist nur ein Wrapper für fopen sowieso] (https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-crt/stdio/fopen64.c). Du solltest also wahrscheinlich nur fopen benutzen. –

+0

Ja, ich habe bereits die Include-Datei überprüft. Aber der Fehler ist mit 'fopen64' aufgetreten, aber nicht mit' fopen'. –

+0

Das eigentliche Problem ist wahrscheinlich anderswo, Speicherbeschädigung oder ähnliches. Aber mein Punkt ist, dass, soweit ich das beurteilen kann, die Verwendung von fopen64 genau nichts bringt, also warum nicht einfach fopen benutzen? –

Antwort

0

Vorerst verwende ich den Code unten .

#if defined(_WIN64) 
#define _fopen fopen 
#else 
#define _fopen fopen64 
#endif