Hi Dmitry,
On 06/05/12 13:05, Dmitry Timoshkov wrote:
Alexandre Julliard julliard@winehq.org wrote:
That doesn't seem very useful. What use case would there be for an app to rely on some random 75% of its strings to remain valid?
Although the test is about statistics, my intention was to show that BSTR cache in Wine corrupts cached strings. I could try to figure out exact steps which lead to corruption of real strings the application cares about, but that's pretty hard to do, there are enourmous amount of lines in the log that are related to BSTR creation/destruction, and finally the string the app cares about and tries to use is corrupted. I thought that adding a statistical test would hint Jacek what might be wrong with current cache implementation.
Unfortunately, statistical test isn't much helpful. The corruption you can see is probably due to the fact that not all strings are cached. Once the cache is full (for strings of similar size), the string is immediately freed. We can't cache all of them, that would be a massive leak. When I wrote the patch, I've seen the exact app using BSTRs in a pattern that I've verified that should work with the cache (or better said, the bug is hidden by the cache). I understand that it may be not easy in some cases, but I don't see how we could fix the implementation without understanding the cause of the problem.
BTW, did you test the app on Windows with disabled BSTR cache? It's easy to do by setting OANOCACHE environment variable before running the app. If that breaks the app, then indeed the app is broken in a way that it depends on BSTR cache behaviour.
Cheers, Jacek