Menu
▾
▴
1 Attachments
#429 d2d1.h HwndRenderTarget GetSize crash incorrect interface
compiling a simple application that utilizes direct 2d will crash with any call to ID2D1HwndRenderTarget::GetSize() , this is using the latest release build of mingw-w64, win32 threading, and seh exception handling. This bug has been present for a few iterations of mingw-w64. I am using the C++ interface ( D2D_USE_C_DEFINITIONS is not defined ). Looking through the mailing list it seems that the C definitions was fixed for a vlc compilation, although I have not tried to verify this. Attached is as short of an example that will crash that can be written. Link with d2d1 and compile with -std=c++11 (for nullptr use), and it will segfault in the d2d1.h header on ID2D1HwndRenderTarget::GetSize(), if you print m_factory and m_target both are not null, and have been created properly. Please fix this issue.
This sounds similar to a problem we had in Wine - you can't call d2d methods like GetSize() from C code, because it will need implicit parameter after 'this' pointer. Could you post a full command line/makefile you use to build your test?
g++ d2dcrash.cpp -DWINVER=0x0601 -s -static -mwindows -municode -lole32
-ld2d1 -O3 -o test.exe
Compile the included example of the issue and it will crash, comment out
the line that calls the getsize function on the Id2d1HwndRenderTarget
interface ( should be named m_target ) on line 20 , recompile, execute ,
and it will not crash, inspection without stripping debug information out
via gdb shows a segmentation fault occours because the interface is
incorrect. Searching through Google revealed the previous post about the C
interface, I've no idea if this has been corrected, however the c++
interface suffers from the same issue, possiably not because of the same
reason as previously posted about the C interface. My toolchain : mingw-64
gcc 4.9.2 seh win32 threads. Windows 7 / 8.1 the example crashes on both
os's.
On Nov 8, 2014 11:33 AM, "Nikolay Sivov" nsivov@users.sf.net wrote:
Related
Bugs: #429
This is what I get after updating to mingw64 gcc 4.9.2 seh win32 threads
(64 bit toolchain)
donwloaded from:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-win32/seh/x86_64-4.9.2-release-win32-seh-rt_v3-rev0.7z/download
Usr@Machine ~/Desktop
$ g++ -std=c++11 d2d1Crash.cpp -g -static -mwindows -municode -lole32
-ld2d1 -o
test.exe
Usr@Machine ~/Desktop
$ gdb test.exe
Starting program: c:\Users\Usr\Desktop\test.exe
[New Thread 1700.0x2f4]
warning: SHIMVIEW: ShimInfo(Complete)
GNU gdb (GDB) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
Program received signal SIGSEGV, Segmentation fault.
0x000000000040173c in Render () at d2d1Crash.cpp:21
21 m_target->EndDraw();
(gdb) n
gdb: unknown target exception 0xc000041d at 0x40173c
Program received signal ?, Unknown signal.
0x000000000040173c in Render () at d2d1Crash.cpp:21
21 m_target->EndDraw();
(gdb) n
[Inferior 1 (process 1700) exited with code 030000002035]
(gdb)
Commenting out line #20 in the provided example and recompiling, and re
debugging yields:
Usr@Machine ~/Desktop
$ g++ -std=c++11 d2d1Crash.cpp -g -static -mwindows -municode -lole32
-ld2d1 -o
test.exe
Usr@Machine ~/Desktop
$ gdb test.exe
GNU gdb (GDB) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
Starting program: c:\Users\Usr\Desktop\test.exe
[New Thread 7996.0x1a00]
warning: SHIMVIEW: ShimInfo(Complete)
Breakpoint 1, Render () at d2d1Crash.cpp:21
21 m_target->EndDraw();
(gdb) n
22 }
(gdb) //no crash.
On Sat, Nov 8, 2014 at 2:30 PM, KD kd.boss@gmail.com wrote:
--
¯
°²º¤æ=.KD.=椺²°¯Related
Bugs: #429
Last edit: Jonathon 2014-11-08
debug build is follows.
g++ d2dcrash.cpp -DWINVER=0x0601 -g -static -mwindows -municode -lole32 -ld2d1 -o d2dcrash.exe
this of course expects a shell that has the tool chain installed. I'm not highly familiar with creating makefiles, I typically use cmake or Qt's build system, but if you absolutely require a makefile I could try to cobble one together for you.
This bug has been persistent across a few revisions of mingw-64, and I'm not the first to report it, though I've followed all the suggestions on the other post trying to track it down myself. The interface as far as the ORDER of the function definitions is concerned is correct, as far as I can tell, compared against the windows sdk 7.1
If you compile and run any of the code on microsoft's "Teach yourself C++" site that uses d2d1 it will do the same thing, as they all use the GetSize() function in their Render() method.
a good example of this would be the following.
https://msdn.microsoft.com/en-us/library/windows/desktop/ff684181%28v=vs.85%29.aspx
This is the same bug.
http://sourceforge.net/p/mingw-w64/bugs/334/