Re: wined3d surface handle buffer overflow

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:
>
> 1) 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
>
>
>
>   
>