http://bugs.winehq.org/show_bug.cgi?id=18569
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #3 from Anastasius Focht focht@gmx.net 2009-05-30 15:54:08 --- Hello,
as I've already said in #winehq - such bugs are very difficult to diagnose due their nature.
I looked again at this thing and it most likely seems to be an application bug which Wine unearths due to different heap management/locking strategy in combination with different multithreading profile (thread timing).
There are C++ class members which get concurrently accessed/modified from different threads. Although the app implements locking by using critical sections there are very small time frames (code sections) where the locking strategy is uneffective due to thread timing. It really matters when threads really begin to execute their worker function and how long they take.
This has direct consequence on the app's heap management. Because a shared heap is used for all threads by default (msvc), failure to properly guard allocations/deallocations will introduce heap corruption.
The reason why +heap or +relay works here is that it modifies thread timing in a subtile way (when workers start and end), preventing heap management races.
--- Can you try the following: use 'winecfg', set version to "Windows NT4" and check if it improves the situation for you...
Background: OS < Win2K forces the msvc heap allocator the app is linked with to a more conservative strategy which involves more locking. The might prevent heap corruption resulting from multithreaded heap allocation races in certain situations.
Regards