/* some basic definitions */
typedef unsigned long long u64;
typedef unsigned int u32;
typedef unsigned short u16;
typedef unsigned char u8;
typedef signed long long s64;
typedef signed int s32;
typedef signed short s16;
typedef signed char s8;
#if defined(_WIN64) || defined(_LP64)
#define VERSION64BIT
#endif
#if defined(VERSION64BIT)
// 64 bit code here
#else
// 32 bit code here
#endif
It compiles fine but it crashes on XP64 bit running on an Athlon X2. It often crashes in the middle of search. What could be the source of the problem? Is there anything I need to add or change in the above code to make it work?
By the way, I'm using ICC 10.1.020 integrated with VS 2005.
The types look OK to me, but you might want to typedef u64 to 'unsigned __int64' on Windows platforms and 'unsigned long long' on Linux/Unix platforms. This isn't your problem though, it's just these are the correct 64-bit types for the MS/Intel compilers.
Your problem lies elsewhere I think... Why not run a debug build inside the debugger to find out where the crash is occuring?
trojanfoe wrote:The types look OK to me, but you might want to typedef u64 to 'unsigned __int64' on Windows platforms and 'unsigned long long' on Linux/Unix platforms. This isn't your problem though, it's just these are the correct 64-bit types for the MS/Intel compilers.
They can do long long as well, so that's really not a problem.
trojanfoe wrote:Your problem lies elsewhere I think... Why not run a debug build inside the debugger to find out where the crash is occuring?
trojanfoe wrote:The types look OK to me, but you might want to typedef u64 to 'unsigned __int64' on Windows platforms and 'unsigned long long' on Linux/Unix platforms. This isn't your problem though, it's just these are the correct 64-bit types for the MS/Intel compilers.
They can do long long as well, so that's really not a problem.
trojanfoe wrote:Your problem lies elsewhere I think... Why not run a debug build inside the debugger to find out where the crash is occuring?
Agreed.
Windows does "long long" now? For the longest they did not and I resorted to #ifdef's to solve that.
I could easily solve the problem if I have a 64 bit OS. What I did is that I compiled it with PGO, send it to my tester with 64 bit OS, then my tester sends it back to me together with the PGO files and then I recompiled it with optimizations.
The DEBUG enabled build I have sent him doesn't even produce any errors on the error file and dump file I used for debugging. It just crashed. It didn't happen immediately, it happens after somewhere on the 10th time it searched.
They seem to be faster than any compiling flags I've used anyway in my 32bit build. I don't know why. My engine is bitboards. Maybe my code is well optimized already.
I could easily solve the problem if I have a 64 bit OS. What I did is that I compiled it with PGO, send it to my tester with 64 bit OS, then my tester sends it back to me together with the PGO files and then I recompiled it with optimizations.
The DEBUG enabled build I have sent him doesn't even produce any errors on the error file and dump file I used for debugging. It just crashed. It didn't happen immediately, it happens after somewhere on the
10th time it searched.
Yeah that could be a bit of a problem. I remember using CrashFinder (http://www.wintellect.com/cs/DasBlogCon ... der2.5.zip) to find where production builds were crashing, assuming you keep the .PDB file as well as the .EXE from your release builds, but I doubt you'd be able to use it from a 32-bit OS on a 64-bit EXE. You could try compiling CrashFinder for 64-bit and letting your tester give you the information. If you go down this path I would recommend you reherse a crash in a 32-bit test program (deference NULL is always a favourite) so you can direct the tester how to use it to get the results you need.
Best option though, is for you to use a 64-bit OS yourself.
