https://bugs.winehq.org/show_bug.cgi?id=40537
Bug ID: 40537 Summary: ddraw:ddraw1 causes Windows XP to crash Product: Wine Version: 1.9.8 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
Since 2016/04/22 running ddraw:ddraw1 on my EeePC (Intel GMA 950) crashes Windows XP. So the crash is caused by one of these two commits:
commit 7cabef1457fe0aae4319339fdc46b059b41fc3bf Author: Henri Verbeet hverbeet@codeweavers.com AuthorDate: Thu Apr 21 17:05:09 2016 +0200 Commit: Alexandre Julliard julliard@winehq.org CommitDate: Fri Apr 22 12:22:45 2016 +0900
ddraw: Require exclusive mode only for primary surface flips.
Signed-off-by: Henri Verbeet hverbeet@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
commit 1736431c683ade50a8e539331158dc5570cd300c Author: Henri Verbeet hverbeet@codeweavers.com AuthorDate: Thu Apr 21 17:05:08 2016 +0200 Commit: Alexandre Julliard julliard@winehq.org CommitDate: Fri Apr 22 12:22:42 2016 +0900
ddraw: Allow DDSCAPS_FLIP without DDSCAPS_PRIMARYSURFACE.
Signed-off-by: Henri Verbeet hverbeet@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=40537
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=40537
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=40537
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |7cabef1457fe0aae4319339fdc4 | |6b059b41fc3bf
--- Comment #1 from François Gouget fgouget@codeweavers.com --- Further tests show that just reverting the 7cabef14 patch fixes the Windows XP crash. ddraw:ddraw2, ddraw:ddraw4 and ddraw:ddraw7 also cause Windows XP to crash when the 7cabef14 patch is applied and don't when it is not.
More precisions on the hardware and software: * Windows XP SP3 * Intel Graphics Media Accelerator 6.14.10.4906 driver (DirectX 9.0) * Intel GMA 950 GPU (Mobile 945 Express Chipset Family) Video BIOS 1585.0 * 128MB of video RAM, 1024x600 32bpp
https://bugs.winehq.org/show_bug.cgi?id=40537
Julius Schwartzenberg julius.schwartzenberg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julius.schwartzenberg@gmail | |.com
--- Comment #2 from Julius Schwartzenberg julius.schwartzenberg@gmail.com --- Maybe it would be a good idea to disable the automatic reboot on BSoD and catch the error?
If Windows XP would still be supported, it would be appropriate to send the test case to Microsoft/Intel, but I guess this would be useless now.
https://bugs.winehq.org/show_bug.cgi?id=40537
parkerjbarker@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |parkerjbarker@yahoo.com
--- Comment #3 from parkerjbarker@yahoo.com --- Ddraw:ddraw1 also crashes my 32-bit Vista Ultimate. The build I tried to test is: https://test.winehq.org/data/8a92dd9a5720c4b6b334e4f13629c0b0f5a72e94 which is the test for release 1.9.20.
*** STOP: 0x0000008E (0xC0000005, 0xA5CDBD96, 0xADC6F7B4, 0x00000000) *** ialmdev5.DLL - Address A5CDBD96 base at A5CD0000, DateStamp 4549bcd2
This was after the various screen resolution changes.
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #4 from parkerjbarker@yahoo.com --- Is there a way to download wine test programs for previous builds?? It's not straightforward on the winehq test runs page.
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #5 from François Gouget fgouget@codeweavers.com --- (In reply to parkerjbarker from comment #4)
Is there a way to download wine test programs for previous builds?? It's not straightforward on the winehq test runs page.
You can get them from the "Main summary for build ..." headers on test.winehq.org. For instance: https://test.winehq.org/builds/winetest-2035a8c7c84a.exe
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #6 from parkerjbarker@yahoo.com --- So... why doesn't someone just send in a patch to revert the 7cab commit? That seems easy enough. If I knew how to do it, I'd probably do it.
https://bugs.winehq.org/show_bug.cgi?id=40537
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fjfrackiewicz@gmail.com
--- Comment #7 from fjfrackiewicz@gmail.com --- (In reply to parkerjbarker from comment #6)
So... why doesn't someone just send in a patch to revert the 7cab commit? That seems easy enough. If I knew how to do it, I'd probably do it.
You might want to CC the author of the patch in this bug report so they know about your findings and see what they have to say. Usually that's what is supposed to be done: you list the regression and CC the author of the commit that causes the regression in your bug report.
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #8 from Henri Verbeet hverbeet@gmail.com --- (In reply to parkerjbarker from comment #6)
So... why doesn't someone just send in a patch to revert the 7cab commit?
Because so far all the evidence suggests this is a driver issue instead of an issue with the commit in question. It may very well be possible to create a workaround for that issue, but that requires finding out what the issue is first, and that requires someone who can reproduce the issue taking a look.
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #9 from parkerjbarker@yahoo.com --- I completed the wine test, build 21dd04670c1e2fa06bfc5bbb5b0c6f4537cde9a4 (released just after 2.0-RC2), and it works and doesn't cause a blue screen for me any more. Thank you!
https://bugs.winehq.org/show_bug.cgi?id=40537
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dimesio@earthlink.net, | |winetest@luukku.com
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #10 from François Gouget fgouget@codeweavers.com --- This issue is still present in b5ad6a44801e.
On my Windows XP EeePC ddraw:ddraw{1,2,4,7} still all cause a BSOD with a message implicating the graphics driver. Here is the debug information (the 0xA81E8628 changes with each run, the rest is constant):
*** STOP: 0x0000008E (0xC0000005,0xBF05A2C6,0xA81E8628,0x00000000)
*** igxpdv32.DLL - Address BF05A2C6 base at BF04F000, DateStamp 476971c3
The crash goes away when I switch the hardware acceleration from "Disable all cursor and advanced drawing acceleration." to "Disable all DirectDraw and Direct3D, and cursor and advanced drawing acceleration.". Of course then most tests are skipped...
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #11 from Henri Verbeet hverbeet@gmail.com --- (In reply to François Gouget from comment #10)
The crash goes away when I switch the hardware acceleration from "Disable all cursor and advanced drawing acceleration." to "Disable all DirectDraw and Direct3D, and cursor and advanced drawing acceleration.". Of course then most tests are skipped...
Does it work if you don't disable acceleration at all?
Could you find out if there's a specific change/function call that causes the issue? E.g., is this because the set_display_mode() call was removed, or does this happen when trying to restore surfaces, etc.? Does this only happen for a specific surface type (see test_data[]), or all of them? Does this happen when test_flip() is run on its own, or does it somehow depend on state set by a previous test?
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #12 from François Gouget fgouget@codeweavers.com --- (In reply to Henri Verbeet from comment #11)
Does it work if you don't disable acceleration at all?
I only started playing with the acceleration settings to try and narrow down the issue. So yes, with full acceleration (the default), it crashes.
Against all expectations I found a slightly newer driver: 6.14.10.4926 (2008-02-28, winxp_14324.exe)). https://downloadcenter.intel.com/download/16835/Intel-Graphics-Media-Acceler...
However even with this driver ddraw:ddraw1 crashes in essentially the same way:
*** STOP: 0x0000008E (0xC0000005,0xBF05A2C6,0xA81F0628,0x00000000)
*** igxpdv32.DLL - Address BF05A2C6 base at BF04F000, DateStamp 47b6002d
Dissecting the test now...
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #13 from François Gouget fgouget@codeweavers.com --- Created attachment 56743 --> https://bugs.winehq.org/attachment.cgi?id=56743 Minimal ddraw1.c file to reproduce the crash
The ddraw1 crash happens in restore_surfaces() call, even if restore_callback() does nothing at all.
However further investigation shows that neither the removed set_display_mode() call, nor the lines added by 7cabef14 matter: I came up with a minimal test that reliably produces the same crash.
What the driver does not like is the DDSCAPS_COMPLEX | DDSCAPS_FLIP | DDSCAPS_TEXTURE CreateSurface() combination.
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #14 from Henri Verbeet hverbeet@gmail.com --- Created attachment 56745 --> https://bugs.winehq.org/attachment.cgi?id=56745 modified test
Does this also crash?
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #15 from François Gouget fgouget@codeweavers.com --- Yes, this produces the same crash.
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #16 from François Gouget fgouget@codeweavers.com --- I'll add that removing either DDSCAPS_COMPLEX or DDSCAPS_FLIP from surface_desc.ddsCaps.dwCaps for the IDirectDraw_EnumSurfaces() call avoids the crash. It's only when they are together that the crash happens. (reader from the future: see the modified test attachment)
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #17 from Henri Verbeet hverbeet@gmail.com --- (In reply to François Gouget from comment #16)
I'll add that removing either DDSCAPS_COMPLEX or DDSCAPS_FLIP from surface_desc.ddsCaps.dwCaps for the IDirectDraw_EnumSurfaces() call avoids the crash. It's only when they are together that the crash happens. (reader from the future: see the modified test attachment)
That makes sense, removing those likely makes it fail validation in the ddraw runtime, before the driver gets involved.
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #18 from Henri Verbeet hverbeet@gmail.com --- Created attachment 56801 --> https://bugs.winehq.org/attachment.cgi?id=56801 patch
Does this patch help?
https://bugs.winehq.org/show_bug.cgi?id=40537
--- Comment #19 from François Gouget fgouget@codeweavers.com --- It does: Windows no longer crashes.
(there are still failures and the tests themselves crash in test_color_fill() but those are separate issues)
https://bugs.winehq.org/show_bug.cgi?id=40537
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |544fd16c15943fecec9ad03d201 | |d24f5775c1224 Status|NEW |RESOLVED
--- Comment #20 from Henri Verbeet hverbeet@gmail.com --- Should be fixed by commit 544fd16c15943fecec9ad03d201d24f5775c1224.
https://bugs.winehq.org/show_bug.cgi?id=40537
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 2.0-rc5.
-
wine-bugs＠winehq.org