On Sat, 25 Mar 2000, Lionel Ulmer wrote:
> On Fri, Mar 24, 2000 at 11:57:49PM +0100, Ove Kaaven wrote:
> > And you still haven't said how it crashes. I just played Part 1 of Monkey
> > Island 3 with XFree86 4.0 with ldd showing that it's linked to both
> > libGL.so.1 and libpthread.so.0, no problems.
>
> My current setup is Wine CVS as of yesterday + the latest version of
> your pthread patch.
>
> My system : X is XFree 4.0.0, glibc is version 2.0.6.
Oh, I have glibc 2.1.3.
> The easiest way to get Wine to crash is to start anything with
> '-debugmsg +heap'. As far as I can understand what happens, I have :
>
> 1) HeapAlloc that calls vsprintf (because of the -debugmsg +heap)
>
> 2) vsprintf that does some thread safety stuff because it then
> breaks at 'mutex_real_init'.
>
> 3) the mutex given as input to 'mutex_real_init' has the 'critsect'
> field set to NULL -> call HeapAlloc and go to step 1....
>
> This means that Wine is eating all the memory (as the mutex is always
> different each time I break at 'mutex_real_init').
Well, if you think of a solution for that one, tell me... but that's not
the most common problem people encounter, I bet...
> Without the '+heap', I get a bit further (as I at least parse the
> wine.conf file), but I crash with a segmentation fault. The problem
> being that the 'HeapAlloc' call in 'mutex_real_init' returns NULL
> (thus getting the segfault in InitializeCriticalSection). The function
> 'mutex_real_init' is called at least 30000 times with an uninitialized
> mutext before the crash.
Memory exhausted on the system heap? That doesn't sound good, but as you
know I can't reproduce it here... should we start recommending people to
upgrade their libc, or can you debug it?
