Re: [PATCH 1/1] d3d8: Don't assert on invalid IDirect3DBaseTexture8 interfaces.
-----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? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRa7lTAAoJEN0/YqbEcdMwNjEP/RLeLk3+009+Cp2n5sWOUprn Z5ED8iL3RXRjsCJNU5Fi2JIkCcVRmdkkn2RTBN9Q9KEkUL0qjg6B7Admy5sWtMIk LDtYpjS6BeDIJm8e0D0HwGItv2ekxW37ggg9fsArcXUO/lKf2GrJmUiyAjQfzmT9 IDlewcLSzUiAdbzZ4WUZzkqIa9lQgDpZBAvOgvgqhY2suf+YpJi6oTMfgwzpiSyB L2mlXx4cb0/hYaPAdWZUbc9uHvsCQ5ZwE4EhIxWpMlZM8FENMN3Gc0vrpzWAXoBo XRifoh3n0VKaYyZ+Wi+zGRaFX40P4ouBUKuFcBdjEPq6Fhz46GEGY8KFf1MVZKwM 7pzkhv6yc8/GTr2q5wthhmnZxDLHIZNyVEoMU0AFB1M0V/k0sJQfXpCCA/6vql+g dgUtyPggMSefwT0lc/7S/UwQdvuRYyIcdVd47alDJyRfU5NOMx091IiqkKXm9nby nqGAfdO3GDQoOIXJpWD5E1UMPHt6AGXGsfypkuVTtTljvOx+U7S9ngBeFkjuor8+ VFwStSFGboPxAjfKqzubdFcPcp4t8E5/qqkXR+Nc2UBJV5XeC3Pg5GOZxBsDZvbz zU4btX6kgC1Si1vIkf+D8CyZgaoPSwiVgGfVkTaqYSqnO39JZ0SpjYlv7e4yuhfa jkXNYd+XevrLq435YYir =TVml -----END PGP SIGNATURE-----
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.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRa+l9AAoJEN0/YqbEcdMw9qsQAJFvdFH3jGhrVsyII++ART9J etfmFEfsFcw99m1mkPfpUsPqtlk0tiwWJ5OTI6pcoa5zAqh03e9sr83xQYvxyX/J B155EW5CepOMbTKHbedPyS2UXYcdRCFxN0w6wVcWRMap7WTLNPWLC4A7XGFNhkSZ ZIDM7IlDjOntHij74tdxEzx+xs/aZsgaTcfWaxX3IzrHsxOb2gywKI3NcrTg+TNT yQvTq9ac2jeZ4U7nHnASAfg9TYZtIdNygK1DhuHWTx9QEo+Xb+Ik09VR4zYWmCEt EFqxIcNnSqCDqVO9lDigEpUSLBqfpxTBdb6SPnQ6vJhwjO/XTYl3fKWzby3IVgEH wo8p+T7f3n+rnpNocQ7BQlVjwIqyRwsPj6B65xaB9Sxv+zd1hTiPD7diwLh4bveX VEpSXRkfESAOUgnj8HWiRczSb/9GN2m2YCdgiHIyXMDd3TcvNagncK2o5ROC9s3i cN2rdyP7nFYRZzwyn6ttN+gAeFjcK1Ryk37nCF77HkKiFCqE6cqGTYnQxDPH8D2m xaKj36vjswg1Tk6PoZ1CN/isW99psbRHaNcdimW0ExcoboiePD8qMhdFLHZ2a123 Bdbti4zUkUIhGt3VnE7MQyMZ2ivWLSXrbQplFQcViz6gmJB+hm+LJl+ONBRNky1j ADcAEILlJ8JVLXR9EDCV =QLR7 -----END PGP SIGNATURE-----
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.
participants (2)
-
Rico Schüller -
Stefan Dösinger