[ 1.8 | 1.9 ] device->run() crash VS2012 64bit

[xilefian]

Unhandled Exception when using a 64bit build of Irrlicht 1.8 using the Visual Studio 11.0 (2012) compiler.

EDIT: Also tested on Irrlicht 1.9 branch nightly builds with the very same environment.

No code changes were made, built direct from source targeting 64bit Windows and using the latest Windows SDK, this was built using the directx sdk that came with Visual Studio 2012 Ultimate (Windows 8 SDK).
Compiled fine on Windows 7 64bit, targeting Windows 64bit, however all demo applications crash at the method IrrlichtDevice::run() at this method.

Code: Select all

//! Process system events
void CIrrDeviceWin32::handleSystemMessages()
{
    MSG msg;
 
    while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
    {
        // No message translation because we don't use WM_CHAR and it would conflict with our
        // deadkey handling.
 
        if (ExternalWindow && msg.hwnd == HWnd)
            WndProc(HWnd, msg.message, msg.wParam, msg.lParam);
        else
            DispatchMessage(&msg); // Crashes here with unhandled exception, no stack trace is given
 
        if (msg.message == WM_QUIT)
            Close = true;
    }
}

When commenting out the lines

Code: Select all

        else
            DispatchMessage(&msg);

The application runs fine although the winapi no longer functions (Cannot set the window caption, icons do not appear, the window buttons no longer function).

Therefore, one can presume that something is wrong with the winapi on 64bit Windows with the VC11.0 Windows SDK.

I have also re-written certain aspects of Irrlicht to be 64bit safe and this crash still occurs.

This is the output from my console when the bug is triggered on my 64bit port of my program that worked fine with a 32bit build of Irrlicht:

Irrlicht Engine version 1.8.0
Microsoft Windows 7 Professional Edition Service Pack 1 (Build 7601)
WGL_extensions: WGL_ARB_extensions_string WGL_ARB_pixel_format WGL_ATI_pixel_format_float WGL_ARB_pixel_format_float WGL_ARB_multisample WGL_EXT_swap_control WGL_EXT_swap_control_tear WGL_ARB_pbuffer WGL_ARB_render_texture WGL_ARB_make_current_read WGL_EXT_extensions_string WGL_ARB_buffer_region WGL_EXT_framebuffer_sRGB WGL_ATI_render_texture_rectangle WGL_EXT_pixel_format_packed_float WGL_I3D_genlock WGL_NV_swap_group WGL_ARB_create_context WGL_AMD_gpu_association WGL_AMDX_gpu_association WGL_ARB_create_context_profile WGL_NV_DX_interop WGL_NV_DX_interop2 WGL_NV_float_buffer
Pixel Format: 2
Using renderer: OpenGL 4.2.12198
AMD Radeon HD 6900 Series: ATI Technologies Inc.
OpenGL driver version is 1.2 or better.
GLSL version: 4.2
Resizing window (1280 720)

---Normal, working resource loading and custom engine output---

First-chance exception at 0x000000003F0A2C9D in bwrpg.exe: 0xC0000005: Access violation executing location 0x000000003F0A2C9D.
First-chance exception at 0x000000003F0A2C9D in bwrpg.exe: 0xC0000005: Access violation executing location 0x000000003F0A2C9D.
First-chance exception at 0x000000003F0A2C9D in bwrpg.exe: 0xC0000005: Access violation executing location 0x000000003F0A2C9D.
First-chance exception at 0x000000003F0A2C9D in bwrpg.exe: 0xC0000005: Access violation executing location 0x000000003F0A2C9D.
First-chance exception at 0x000000003F0A2C9D in bwrpg.exe: 0xC0000005: Access violation executing location 0x000000003F0A2C9D.
First-chance exception at 0x000000003F0A2C9D in bwrpg.exe: 0xC0000005: Access violation executing location 0x000000003F0A2C9D.

[hendu]

I have also re-written certain aspects of Irrlicht to be 64bit safe

Are you referring to the Windows parts or the generic parts? I've been running irr on 64-bit linux for years.

[xilefian]

I have also re-written certain aspects of Irrlicht to be 64bit safe

Are you referring to the Windows parts or the generic parts? I've been running irr on 64-bit linux for years.

The windows parts, a heck of a lot of the generic parts are not 64bit safe (Storing pointers as u32/s32), however I have only started re-writing the windows specific parts to be 64bit safe AFTER I had this crash, this crash happens with stock Irrlicht 1.8, downloaded and compiled to 64bit on Windows with VS2012

[hendu]

It wouldn't compile at all for me if it were storing pointers in ints in the generic parts. Can you give the exact parts where it does that?

[xilefian]

It wouldn't compile at all for me if it were storing pointers in ints in the generic parts. Can you give the exact parts where it does that?

Forgive me, I must have had my stupid glasses on, I can't find any of the examples I noted down earlier and I would have noticed them as it takes some effort to store a pointer in an integer.

There are lots of examples of ints stored as pointers and 32bit to 64bit misalignment but I'm guessing they aren't a worry, perhaps I was thinking of them.

The original problem still persists, none the less.