http://bugs.winehq.org/show_bug.cgi?id=16023 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget(a)codeweavers.com Status|NEW |ASSIGNED --- Comment #13 from François Gouget <fgouget(a)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(a)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... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.