Hi,
maybe this topic has discussed before but I did not find any threads in the devel mailing list for the last months. Additionally i followed wine development for only a few weeks. So here we go ...
oleaut.c in native Windows has some type of "heap reusage" when working with strings. This can be unconvered when placing debug messages into IMalloc_xxx functions. A sequence of SysAllocString, SysFreeString will show something like that:
Alloc olemalloc:IMalloc_fnAlloc (0x7ec47df8, 16) - addr is 0x12a1b8 Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16 Alloc nothing Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16
When exiting the program one can see a message like this
olemalloc:IMalloc_fnFree (0x7ec47df8, 0x12a1b8)
In Wine the heap will be released immediately. Why sould that be of any concern you may ask. This behaviour makes some buggy applications run with native oleaut32 (see bug 12460). In this case the application copies the contents of a string directly after it has been freed. Wine corrupts the heap in between and the application will crash.
My question is: Should this behaviour declared as "application is buggy & will not be fixed" or has a patch a chance to find its way into git? An idea would be an deferred free like this.
- TlsAlloc on entry of dll.
- SysFreeString TlsGetValue for last address if value is set FreeHeap(address) TlsSetValue for current address
- on exit of dll do some cleanup (heap & Tls)
Of course this behaviour is far away from the oleaut implementation and will consume some more CPU cycles.
Thanks for your feedback in inadvance.
Markus