-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-14 16:53, schrieb Rico Schüller:
- if (iface->lpVtbl != (const IDirect3DBaseTexture8Vtbl
*)&Direct3DTexture8_Vtbl + && iface->lpVtbl != (const IDirect3DBaseTexture8Vtbl *)&Direct3DCubeTexture8_Vtbl + && iface->lpVtbl != (const IDirect3DBaseTexture8Vtbl *)&Direct3DVolumeTexture8_Vtbl) + { + WARN("%p is not a valid IDirect3DBaseTexture8 interface.\n", iface); + return NULL; + }
A test would be a good idea.
Are you sure that the assert is the actual problem, and not some memory corruption that changes the vtable poiner? What does e.g. GetTexture do after a bogous SetTexture call?
On 15.04.2013 10:24, Stefan Dösinger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-14 16:53, schrieb Rico Schüller:
- if (iface->lpVtbl != (const IDirect3DBaseTexture8Vtbl
*)&Direct3DTexture8_Vtbl + && iface->lpVtbl != (const IDirect3DBaseTexture8Vtbl *)&Direct3DCubeTexture8_Vtbl + && iface->lpVtbl != (const IDirect3DBaseTexture8Vtbl *)&Direct3DVolumeTexture8_Vtbl) + { + WARN("%p is not a valid IDirect3DBaseTexture8 interface.\n", iface); + return NULL; + }
A test would be a good idea.
Are you sure that the assert is the actual problem, and not some memory corruption that changes the vtable poiner? What does e.g. GetTexture do after a bogous SetTexture call?
Well, the app sets an already released texture. As we access some members (in this case wined3d_texture) we may get some trouble when the memory is reused with some other data as we have the guilty memory still bound somewhere in the pipeline.
I'm not sure what GetTexture does, a test might show it (I'll have a look). The problem might be, that we use some members, which native probably doesn't do in SetTexture. You couldn't call GetTexture in wine with uninitialized memory as we do currently, that's why I think using NULL is the way to go.
Please have a look at http://bugs.winehq.org/show_bug.cgi?id=33055 . Well I think there might be some memory corruption somewhere, but it doesn't have anything to do with the this bug as we use already freed memory in our implementation.
Cheers Rico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-15 10:53, schrieb Rico Schüller:
I'm not sure what GetTexture does, a test might show it (I'll have a look). The problem might be, that we use some members, which native probably doesn't do in SetTexture. You couldn't call GetTexture in wine with uninitialized memory as we do currently, that's why I think using NULL is the way to go.
Given the circumstances, the patch is probably the correct way to go, yes.
Does the game just do the broken SetTexture call once, or does it repeatedly try to use the released texture?
What happens when you pass an invalid pointer (e.g. (void *)0xdeadbeef)? What happens when you pass a valid pointer that points to memory filled with zeros or garbage? If SetTexture does not crash, what is the return value?
Please have a look at http://bugs.winehq.org/show_bug.cgi?id=33055 . Well I think there might be some memory corruption somewhere, but it doesn't have anything to do with the this bug as we use already freed memory in our implementation.
I don't see anything in the log that would keep the texture around. There may be some capability flag issues that trigger a broken codepath in the game, but such an issue is really hard to find.
On 15.04.2013 13:50, Stefan Dösinger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-15 10:53, schrieb Rico Schüller:
I'm not sure what GetTexture does, a test might show it (I'll have a look). The problem might be, that we use some members, which native probably doesn't do in SetTexture. You couldn't call GetTexture in wine with uninitialized memory as we do currently, that's why I think using NULL is the way to go.
Given the circumstances, the patch is probably the correct way to go, yes.
Does the game just do the broken SetTexture call once, or does it repeatedly try to use the released texture?
Only once, the game does what the attached test tries to do. GetTexture wont work and may also crash on win.
What happens when you pass an invalid pointer (e.g. (void *)0xdeadbeef)? What happens when you pass a valid pointer that points to memory filled with zeros or garbage? If SetTexture does not crash, what is the return value?
Using deadbeef will crash immediately, you may have luck when deadbeef points into something valid. The same goes for zeros or garbage values, but it looks like SetTexture accepts them more likely than the other approach and won't crash that often. As our internal structure layout may be different (likely it is) it is like trowing dices to crash here or there.
Note: The assert as is looks a way too strict, but removing it again works only till the dsound patch, which obviously overwrites something we depend on. The game may only work on windows by luck, since this only happens the first run of the game at all.
Please have a look at http://bugs.winehq.org/show_bug.cgi?id=33055 . Well I think there might be some memory corruption somewhere, but it doesn't have anything to do with the this bug as we use already freed memory in our implementation.
I don't see anything in the log that would keep the texture around. There may be some capability flag issues that trigger a broken codepath in the game, but such an issue is really hard to find.
-
Rico Schüller -
Stefan Dösinger