-------- Original-Nachricht -------- > Datum: Wed, 18 Mar 2009 20:31:35 +0100 > Von: Tijl Coosemans <t...@ulyssis.org> > An: Francois Gouget <fgou...@codeweavers.com> > CC: wine-devel@winehq.org, wine-patches <wine-patc...@winehq.org>, Alex > Kozlov <s...@rm-rf.kiev.ua> > Betreff: Re: libwine: Only partially reserve memory beyond 0x80000000 on > FreeBSD.
> On Wednesday 18 March 2009 16:36:29 Francois Gouget wrote: > > Tijl Coosemans a écrit : > >> After enabling the memory reservation code on FreeBSD last week, > >> several games either suffer a performance loss or simply crash, > >> often with GL_OUT_OF_MEMORY errors or similar out of memory errors > >> from X libs. (Tested with nvidia driver and opensource r300 dri > >> driver.) > > > > Which games can be used to reproduce this issue? Is one of them > > freely downloadable? Even better, can this issue be reproduced with a > > non-game application? > > Puzzle Quest is a game that starts up slowly and locks up before > getting to the game menu. > > http://www.infinite-interactive.com/puzzlequest.php?page=demo > > Alex Kozlov (CCed) can give you more examples. He mentioned StarWolves, > Warlords4, Erherlords, Soldier of Fortune Gold, Fall: Last Days og > Gaia, Dominions3... > > Normal applications all seem to work. > > > Also, won't this patch be obsolete once Alexandre completes his > > current OpenGL memory allocation work? That is, doesn't it just hide > > the problem rather than solving it? > > I don't know what Alexandre's work involves, but the problem here are > malloc(3) and mmap(2) calls in code outside Wine. On FreeBSD mmap > allocates upwards starting after the location of the executable + some > malloc heap space. With everything above 0x80000000 reserved and the > wine executable located at 0x7bf00000, there's only about 64MiB of > address space left of which about 32MiB is currently designated malloc > heap (loader/main.c:RLIMIT_DATA). The 32MiB that is left is just enough > to contain all unix and Wine libs, and a 32MiB malloc heap seems to be > enough for all normal applications. I attached a typical layout. > > >> It also causes other problems like: > >> http://bugs.winehq.org/show_bug.cgi?id=17718 > > > > This bug mentions the following error: > > Fatal error 'Cannot allocate red zone for initial thread' at line 384 > > in file /usr/src/lib/libthr/thread/thr_init.c (errno = 2) > > > > It would be nice to figure out how we get in init_main_thread(). > > Apparently there are only two possible cases: > > * 1) Some thread routines have detected that the library hasn't yet > > * been initialized (_thr_initial == NULL && curthread == NULL), > or > > * > > * 2) An explicit call to reinitialize after a fork (indicated > > * by curthread != NULL) > > > > I don't really understand why we would reallocate the stack in the > > first case so my guess is this happens through a fork. > > I've never been able to reproduce this and haven't looked at it very > closely because the problem went away with this patch, but my best > guess is case 1. The threading lib is only initialized when actually > needed. And then perhaps it fails to allocate the red zone for the main > process stack because that page has already been reserved. That doesn't > explain why I can't reproduce it though. > > >> This patch only partially reserves memory, enough for the shared > >> heap, virtual heap and wine top-down allocations, and leaves the > >> majority unreserved. > > > > Isn't the memory reservation supposed to prevent Unix libraries from > > being mapped in this memory range? If so, won't leaving holes open us > > to this sort of trouble again? > > > > Also, besides FreeBSD's braindead stack allocation routines, why > > should this patch only be used on FreeBSD? If it's supposed to help > > with OpenGL memory allocation then shouldn't it be used on Linux too > > (which has the same issue with OpenGL)? > > The memory reservation is needed on Linux because mmap allocates > downwards from the end of address space, so without reservation all > libs end up far beyond 0x80000000 close to the stack. On FreeBSD mmap > allocates upwards so the layout in the attached file for instance looks > the same with or without reservation. On FreeBSD the memory reservation > doesn't really solve any problem. > > What exactly is the issue with OpenGL on Linux? Under OpenGL we have the same issue these days for both Nvidia and Ati hardware. Check http://bugs.winehq.org/show_bug.cgi?id=13335 which contains an early version of Alexandre his patch. There are still some issues with it (some threading one if I remember correctly) and most importantly on 64-bit Nvidia systems there are huge slowdowns. I have some Nvidia employee looking at that but haven't heard back. -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
