http://bugs.winehq.org/show_bug.cgi?id=16023
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com Status|NEW |ASSIGNED
--- Comment #13 from François Gouget fgouget@codeweavers.com 2008-12-05 03:04:27 --- I've looked into this with help from Pierre Beyssac, and, as Alexandre said, the real source of the bug is this 4 year old patch:
commit ac815f5a6a5308c36080b592c748a353e9524c08 Author: Gerald Pfeifer pfeifer@dbai.tuwien.ac.at Date: Thu Nov 4 04:52:48 2004 +0000
Disable memory reservation code on FreeBSD, where it just doesn't work.
Alexandre's recent patch is only the trigger that breaks things. Tracking down the relevant 2004 discussion threads about it gives:
http://www.winehq.org/pipermail/wine-devel/2004-June/027625.html http://www.winehq.org/pipermail/wine-devel/2004-June/027626.html http://www.winehq.org/pipermail/wine-devel/2004-June/027602.html http://www.winehq.org/pipermail/wine-devel/2004-October/030775.html http://www.winehq.org/pipermail/wine-patches/2004-October/013534.html
To sum up, at the time it was disabled because the reservation code failed and killed the process. Nowadays the reservation code works just fine and this lets the application start up. (See memory_reservation.diff)
However, it reserves all the memory from 0x7ffe0000 to the bottom of the stack at about 0xbfbe0000. The problem is that pthread tries to allocate the stack for new threads right below the main thread stack. I.e. right where we made our memory reservations. So enabling the memory reservation code currently breaks threading. There are three possible approaches to fix it: 1) leave a hole beneath the main thread stack. But that's tricky: the size of the hole determines how many threads we can start. The bigger the hole, the more likely it is that something will use that space and conflict with a Windows application. 2) teach _thread_stack_alloc() (in /usr/src/lib/libc_r/uthread/uthread_stack.c) how to allocate its stack elsewhere. Not sure how hard this would be or how likely it is to be accepted upstream. 3) have Wine allocate the thread stack itself. It looks like this should be doable via pthread_attr_setstack().
I'm going to investigate option 3...