0

I'm building my x64 python c library extension from x86 one.

I found out fread with a file pointer opend by fopen64 killed the python process because of an error APPCRASHof ntdll.dll. It doesn't happen under x86 build and neither happen if the file pointer is opened by fopen.

First, I thought it happened because of Windows bug mentioned here. But it didn't fix it.

Is there any good practice to avoid this problem? I'm considering make definition to choose witch file open function is used so that it can work under both x64 and x86, but I don't have any marvelous ideas to do so.

My Environment

  • Windows 7 x64
  • Python 2.7.10 x64
  • Numpy 1.11.0
  • MinGW64
fx-kirin
  • 1,906
  • 1
  • 20
  • 33
  • Looks like [fopen64 is just a wrapper for fopen anyway](https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-crt/stdio/fopen64.c). So you should probably just use fopen. – Harry Johnston Jun 13 '16 at 23:47
  • Yeah, I've already check the include file. But the error occurred with `fopen64` but not with `fopen`. – fx-kirin Jun 14 '16 at 02:12
  • The actual problem is likely elsewhere, memory corruption or similar. But my point is that as far as I can tell, using fopen64 achieves exactly nothing, so why not just use fopen? – Harry Johnston Jun 14 '16 at 02:26
  • Thanks for your advice. Because it was meant to use more than 2GB data file under x86 environment and I just wanted to use the same code under x64 one. – fx-kirin Jun 14 '16 at 02:29
  • As near as I can tell, fopen64 is exactly the same as fopen in the 32-bit version of MinGW too. But I could be mistaken. – Harry Johnston Jun 14 '16 at 02:35
  • Actually, it's not the same on x86 cos `fopen` on x86 can't handle more than 2GB file. – fx-kirin Jun 14 '16 at 04:35
  • That's true on Linux. Not on Windows. – Harry Johnston Jun 14 '16 at 04:55
  • No. It also happens on Windows too. I checked it in my project. Anyway, I'm not going to dig it any more. – fx-kirin Jun 14 '16 at 05:05
  • That's bizarre - the version of MinGW64 I linked to earlier certainly doesn't require you to use `fopen64` in order to deal with large files (since the function doesn't do anything but call `fopen`) and since Windows doesn't have `O_LARGEFILE` or any equivalent I don't see how or why any other version would do so. Still, not my problem either way. :-) FWIW, if you're no longer interested in figuring out what's going wrong, I recommend that you delete the question. – Harry Johnston Jun 14 '16 at 05:13
  • Thanks for sticking around it. I'm not familiar with this ground so I can't tell exactly what is happening. Windows has `_LARGEFILE64_SOURCE`, it might be close to the answer. And the answer I wrote here fixed my problem. I might help somebody who has the same problem. – fx-kirin Jun 14 '16 at 05:38

1 Answers1

0

For now, I'm using the code below.

#if defined(_WIN64)
#define _fopen fopen
#else
#define _fopen fopen64
#endif
fx-kirin
  • 1,906
  • 1
  • 20
  • 33