|
|
|
This thread is locked; no one can reply to it.
|
| Allegro window resize causing crash in Windows 10 |
|
Karadoc ~~
Member #2,749
September 2002
 |
I recently built allegro from the latest source from git, using msys2 on Windows 10. I've found that when windows in allegro are resized, the program sometimes crashes (segfault). I've noticed this in my own programs, and also in the examples. The example the problem is most obvious in is ex_resize.exe, which just resizes a window continuously, bigger then smaller. This example program crash randomly, between around 1 second and 4 seconds of running. Interestingly, I've found that the example does not crash if I run it in "compatibility mode", either as Windows 7 or Windows 8. Incidentally, the examples all require a bunch of dlls, such as libstdc++-6.dll and libgcc_s_seh-1.dll. Is there an easy way to tell cmake to statically link the examples? ----------- |
|
Elias
Member #358
May 2000
|
As for static link, this is from my CMakeCache.txt: CMAKE_CXX_FLAGS:STRING=-static-libstdc++ CMAKE_C_FLAGS:STRING=-static CMAKE_EXE_LINKER_FLAGS:STRING=-static-libstdc++ -static-libgcc -static Do you get the crash also if you use OpenGL mode? -- |
|
Karadoc ~~
Member #2,749
September 2002
|
No. If I use al_set_new_display_flags(ALLEGRO_OPENGL|everything_else_the_same), then it does not crash. (Tested in ex_resize.exe and in my own program.) ----------- |
|
Elias
Member #358
May 2000
|
Ok, so at least we know it's a bug in the D3D driver - and sounds a bit like a race condition to me. Someone needs to go through that driver and see if we still have any sleep/rest calls in there as opposed to event waits (condition variables). -- |
|
Karadoc ~~
Member #2,749
September 2002
|
|
Elias
Member #358
May 2000
|
Yes, that looks fishy - usually something like this is a race condition and whatever changed between win8 and win10 might make it more likely to trigger. Just a guess, just from looking at the code, is that whenever [1] fails things go wrong and win10 might be more likely to have a device reset fail. I don't know the D3D code and I don't have win10 so could be something entirely else though. What happens if you remove the 4 lines under the XXX comment just after the code you showed? -- |
|
Karadoc ~~
Member #2,749
September 2002
|
Commenting out those lines seems to have no effect on ex_resize. It still crashes without compatibility mode. And when with compatibility mode is on, I can't see any difference between the two versions. I then went on to comment out the do_reset & al_rest part; partially just to make sure that my changes are actually being applied... That version does not crash; but it also doesn't look quite right. The "A" shape a bit too big to fit inside the window, and the lines look a bit jagged / pixelated. By the way although the OpenGL version works, it doesn't look as nice as the DirectX version, because when the window is growing, the openGL version seems to fill the growth area black, and so it flickers in the corner with a black L shape as it grows. The DirectX version seems to resize more smoothly. -- Incidentally, I tried changing CMakeCache.txt like you described. I ran cmake again after changing it, but it didn't work. ie. everything compiled fine, but it still isn't statically linked. ----------- |
|
SiegeLord
Member #7,827
October 2006
 |
I can reproduce this in my Win10 VM. I'll try to fix it today. EDIT: I have a potential fix for this. I think the issue is that Allegro has a dangling pointer to the backbuffer render target. Try adding this line to d3d_disp.cpp after line 950: get_extra(al_get_backbuffer(al_display))->render_target = NULL; "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Karadoc ~~
Member #2,749
September 2002
|
That seems to have fixed it. ex_resize and my game both no longer crash in directX mode. Thanks for the help. Allegro is now 1 step closer to perfection. ----------- |
|
|
