Hello!
Markus Stockhausen wrote:
> 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?
The best thing is to write a test for this behavior and test it on
different Windows versions. If even Windows 7 behaves that way I figure
we'll have to provide that "feature" too. Else the application is buggy
and won't work on all Windows versions either.
bye
michael
> 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.
