Hello Fabian,
looks rather like ddraw than wined3d. It is a regression from my patch "ddraw: Store surface handles in the global table.", I will take a look. Thanks for debugging and letting me know.
Regards, Paul.
On 10/11/24 16:07, Fabian Maurer wrote:
Hello,
I'm currently investigating a wined3d regression that leads to an assert - bug 57300.
In short, there is memorys corruption in "d3d_device2_SwapTextureHandles" when copying a "global handle table" handle into the "device handle table". The "device handle table" is only 64 entries long, but the handle is bigger than that - writing out of bounds.
As I see, it all surfaces get allocated into the global handle table. Then in d3d_device2_SwapTextureHandles they get copied into the device handle table. Once in "CreateStateBlock" and once in "EndStateBlock". The device handle table only contains the wined3d state block handle.
If those assumptions are correct, I have a few questions:
- Isn't there a risk of overriding the state block handle when swapping the
texture with handle 1? 2) Why are the handles only copied, completely bypassing the ddraw_allocate_handle function? Doesn't this mess up the next call to "ddraw_allocate_handle"?
A potential solution to the buffer overflow would be the increase the size of the table if the handle doesn't fit. But I don't know if that's the correct course of action, and I don't know what to do with the table size / count values.
Or maybe there' something else wrong here that I'm not seeing, insights would be appreciated.
Regards, Fabian Maurer