http://bugs.winehq.org/show_bug.cgi?id=16023
Summary: PC-BSD fails to launch majority of applcations, 'Invalid address' Product: Wine Version: 1.1.8 Platform: PC OS/Version: FreeBSD Status: NEW Keywords: download, regression Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: austinenglish@gmail.com
Tried running the conformance tests today on PC-BSD, but got a strange error: wine: could not load L"Z:\usr\home\pcbsd\winetest-latest.exe": Invalid address
googling around, seems it's a regression from 1.1.7 in 1.1.8: http://fixunix.com/freebsd/557241-wine-1-1-8-regression-wine-could-not-load-... http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-11/msg00585.h...
I can get notepad to run, but that's about it. Seems to affect all but the most basic of apps.
I've started the regression test, but this is a vm, so it's going to be a bit. I've got a feeling it's one of Alexander's recent ntdll/kernel32 changes, but we'll see soon.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2008-11-12 16:24:10 --- My guess is that the extra allocations for the virtual heap take over the exe space. Someone really needs to implement memory reservation for FreeBSD.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #2 from Austin English austinenglish@gmail.com 2008-11-12 16:51:48 --- (In reply to comment #1)
My guess is that the extra allocations for the virtual heap take over the exe space. Someone really needs to implement memory reservation for FreeBSD.
[pcbsd@pcbsd ~/wine-git]$ git bisect bad 222e406deb878a6312b3c4bf3bcd0e185fa2ff2c is first bad commit commit 222e406deb878a6312b3c4bf3bcd0e185fa2ff2c Author: Alexandre Julliard julliard@winehq.org Date: Fri Oct 31 13:00:59 2008 +0100
ntdll: Create a separate heap for allocating memory views instead of using malloc.
:040000 040000 ec7dbb2e089b4ffefecb4e4b67c0be053880dbeb 761646b9c56562f6851e9d1f165d492b430be987 M dlls
http://bugs.winehq.org/show_bug.cgi?id=16023
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll
http://bugs.winehq.org/show_bug.cgi?id=16023
Kyryll A Mirnenko mirya@zoc.com.ua changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirya@zoc.com.ua
--- Comment #3 from Kyryll A Mirnenko mirya@zoc.com.ua 2008-11-18 10:30:58 --- Confirming for the latest (at the monent of sending) FreeBSD 7.1-PRERELEASE
http://bugs.winehq.org/show_bug.cgi?id=16023
Norbert Mihály norbert79@freemail.hu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |norbert79@freemail.hu
--- Comment #4 from Norbert Mihály norbert79@freemail.hu 2008-11-19 12:45:32 --- Confirmed also for Solaris. Wine 1.1.8, Solaris Latest update - Solaris 10 U6 (10/08)
Nothing seem to work.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #5 from Austin English austinenglish@gmail.com 2008-11-20 01:29:00 --- (In reply to comment #4)
Confirmed also for Solaris. Wine 1.1.8, Solaris Latest update - Solaris 10 U6 (10/08)
Nothing seem to work.
Works fine for me in OpenSolaris.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #6 from Norbert Mihály norbert79@freemail.hu 2008-11-20 05:53:46 --- Weird, yet it seems to be much more frustrating, as no Wine seem to work anymore under Solaris 10. (This is not OpenSolaris).
No Wine seems to be working since 1.0.1 and above.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #7 from Austin English austinenglish@gmail.com 2008-11-20 15:30:42 --- (In reply to comment #6)
Weird, yet it seems to be much more frustrating, as no Wine seem to work anymore under Solaris 10. (This is not OpenSolaris).
No Wine seems to be working since 1.0.1 and above.
Please run a regression test and file a separate bug: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=16023
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |amitrans@narod.ru
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2008-11-29 13:00:34 --- *** Bug 16268 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #9 from James Hawkins truiken@gmail.com 2008-11-29 18:18:11 --- *** Bug 16268 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #10 from Austin English austinenglish@gmail.com 2008-11-29 18:34:32 --- Filing another bug report won't help. If you or anyone else affected is familiar enough with FreeBSD, please implement memory reservation on that platform.
http://bugs.winehq.org/show_bug.cgi?id=16023
Evgeny Azanov nec.away@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nec.away@gmail.com
--- Comment #11 from Evgeny Azanov nec.away@gmail.com 2008-12-01 20:50:15 --- "quick and dirty" patch from Alex Kozlov via freebsd-emulation... http://forums.freebsd.org/showthread.php?t=535
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #12 from Austin English austinenglish@gmail.com 2008-12-01 21:07:57 --- Created an attachment (id=17587) --> (http://bugs.winehq.org/attachment.cgi?id=17587) memory patch
I don't have access to git at the moment, so here's a regular unix diff.
Alexandre, mind taking a look?
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...
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #14 from François Gouget fgouget@codeweavers.com 2008-12-05 03:07:56 --- Created an attachment (id=17649) --> (http://bugs.winehq.org/attachment.cgi?id=17649) Reenable mmap_init() on FreeBSD
http://bugs.winehq.org/show_bug.cgi?id=16023
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #17649|0 |1 is obsolete| |
--- Comment #15 from François Gouget fgouget@codeweavers.com 2008-12-08 04:58:14 --- Created an attachment (id=17748) --> (http://bugs.winehq.org/attachment.cgi?id=17748) Gets Wine working on FreeBSD again
This reenables the memory reservation code and fixes the thread issues that the previous version introduced.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #16 from Austin English austinenglish@gmail.com 2008-12-08 11:35:08 --- (In reply to comment #15)
Created an attachment (id=17748)
--> (http://bugs.winehq.org/attachment.cgi?id=17748) [details]
Gets Wine working on FreeBSD again
This reenables the memory reservation code and fixes the thread issues that the previous version introduced.
Works great here, thanks Francois!
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #17 from François Gouget fgouget@codeweavers.com 2008-12-08 11:58:23 --- Great <g>. I'm not sure if this will make it into Wine though as Alexandre had the following comments about this patch: * He would prefer it if we played our little thread games only on the first call to create_thread() * But he also says that we should really allocate the stack ourselves, especially as it is something we will need to do anyway for the OpenGL memory allocation issue (bug 13335).
So I will see how to progress further.
http://bugs.winehq.org/show_bug.cgi?id=16023
Tijl Coosemans tijl@ulyssis.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tijl@ulyssis.org
--- Comment #18 from Tijl Coosemans tijl@ulyssis.org 2008-12-27 08:15:41 --- The main reason the reservation code is still disabled on FreeBSD is because mmap(NULL) only tries addresses after the executable + some malloc heap space. Wine is located at 0x7bf00000. The heap size is currently set to 0x02000000 by the wine-freebsd loader, which is thought to be the absolute minimum required to support FreeBSD 6, where malloc doesn't fall back on mmap if it runs out of this heap space. It's not enough to run certain games for instance. Although I suspect there are memory leaks in certain DRI drivers, these games do run with a much larger heap space, like 512MiB. Anyway, so mmap(NULL) looks for free memory after about 0x7e000000. If you reserve everything beyond the 2GiB user space limit, that means there's about 32MiB left for all mmap(NULL) calls that might exist in code outside Wine, like for instance the ELF loader. A large portion of that 32MiB is already taken by DSOs. Wine itself translates all mmap(NULL) calls into mmap(0x110000) and this is why the virtual heap ends up at the beginning of address space.
Getting Wine to run on different mmap implementations is more complicated than just getting the reservation code working.
Also, as a comment to the patch above. You shouldn't have to hack around how FreeBSD allocates stacks for threads. If the standard stack allocation fails, Wine should allocate a stack for each thread and specify it with pthread_attr_setstack(3). I thought it already did this though...
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2008-12-27 08:29:46 --- (In reply to comment #18)
The main reason the reservation code is still disabled on FreeBSD is because mmap(NULL) only tries addresses after the executable + some malloc heap space. Wine is located at 0x7bf00000. The heap size is currently set to 0x02000000 by the wine-freebsd loader, which is thought to be the absolute minimum required to support FreeBSD 6, where malloc doesn't fall back on mmap if it runs out of this heap space. It's not enough to run certain games for instance. Although I suspect there are memory leaks in certain DRI drivers, these games do run with a much larger heap space, like 512MiB. Anyway, so mmap(NULL) looks for free memory after about 0x7e000000. If you reserve everything beyond the 2GiB user space limit, that means there's about 32MiB left for all mmap(NULL) calls that might exist in code outside Wine, like for instance the ELF loader. A large portion of that 32MiB is already taken by DSOs.
Yes, but the point is that we don't want DSOs (at least not the Wine ones) to end up above 0x80000000, that's why we have the reservation code, and that's why it needs to be enabled on FreeBSD too. If there isn't enough space for DSOs below 0x80000000 this needs to be fixed.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #20 from Tijl Coosemans tijl@ulyssis.org 2008-12-27 11:26:11 --- I wrote down a few things to get a bit of an overview. If there's anything wrong or if something can be done differently please say so.
These are the things related to mmap: * location of executables, DSOs (*.dll.so *.exe.so, *.so) * thread stacks * malloc heap spaces
These are the things outside wine that use mmap: * ELF loader calls mmap syscall directly. * libc malloc calls internal libc mmap. * DSOs can call libc mmap(2), but could also call the syscall. * Stack allocation by libpthread. Inside Wine, stack allocation can be controlled by setting thread attributes in the argument to pthread_create(3), but threads could be created in code outside Wine as well.
Different mmap implementations: * Allocate from the main stack downwards. (Linux) * Allocate from the program start address+malloc heap upwards. (*BSD) * Allocate randomly. (SELinux?)
Other observations: * Wine wants to control at least the lower 2GiB of address space, but preferably even more to support 3GiB aware processes (?). * Some .dll.so files have a specific image base address, and all of them are best allocated below 0x80000000 (at least for processes that aren't 3GiB aware). * Most ELF loaders don't support base addresses for DSOs. AFAIK only the glibc loader in combination with prelink. (It's possible that linking DSOs as an ELF executable type can trick some loaders into supporting it, but this isn't portable.) * At thread creation/destruction libpthread calls into the ELF loader to allocate/deallocate thread local storage for symbols that have been declared with __thread. These functions are essentially private and OS specific.
Consequences: * You can't control all mmap calls (for instance by overriding/wrapping the libc mmap symbol). * To support the random mmap you need something like wine-preloader which preserves all the regions Wine wants to control before any DSO ends up there. * To support .exe.so and .dll.so base addresses Wine needs its own ELF loader or a .exe.so/.dll.so loader as a wrapper around the OS ELF loader. * If Wine has its own .dll.so loader anyway it can make sure they all end up below 0x80000000 independent of the OS ELF loader capabilities and mmap implementations. * The Wine loader (wine-pthread/kthread) could then be located at around 0xa0000000 for instance instead of 0x7bf00000 now, leaving plenty of space up to the main stack for all mmap calls outside Wine. * Everything before the Wine loader can be preserved by wine-preloader and can be used by the Windows process. Wine would keep track of used/free regions and always call mmap with a specific address and MAP_FIXED. Beware of multiple threads here. Never call munmap.
About the .exe.so/.dll.so loader: * Because libpthread calls into the OS ELF loader, that one will still have to be around and to support __thread symbols in code outside Wine all standard .so libraries need to be loaded by it. * So, any dependencies that are standard .so libraries would have to be loaded using the dlopen/dlclose/dlsym API. * If __thread is used in .dll.so or .exe.so, Wine needs to wrap thread creation/destruction to call into the .dll.so loader which can allocate/deallocate the memory for those symbols.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #21 from Alexandre Julliard julliard@winehq.org 2008-12-27 12:43:49 --- Providing an ELF loader in Wine is not a realistic option. It would need to interact with the system loader using internal interfaces that are not exported and not supposed to be used from applications. Fixing the memory reservation code on FreeBSD is trivial by comparison.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #22 from Tijl Coosemans tijl@ulyssis.org 2008-12-28 11:18:22 --- I just don't think you can get the reservation code working satisfyingly without moving wine-pthread lower.
Introducing a .dll.so loader would really release a lot of the constraints Wine currently tries to fit in and solve the -image-base problem at the same time. And as far as I can see it can be done in a portable way. It would handle .dll.so completely and the system loader would never know about them. Normal .so libraries can be handled through dlopen/dlsym. Most of them are already dlopen'ed anyway.
http://bugs.winehq.org/show_bug.cgi?id=16023
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com Summary|PC-BSD fails to launch |FreeBSD (PC-BSD) fails to |majority of applcations, |launch majority of |'Invalid address' |applications, 'Invalid | |address'
--- Comment #23 from Gerald Pfeifer gerald@pfeifer.com 2008-12-29 01:54:20 --- (In reply to comment #18)
The main reason the reservation code is still disabled on FreeBSD is because mmap(NULL) only tries addresses after the executable + some malloc heap space. Wine is located at 0x7bf00000. The heap size is currently set to 0x02000000 by the wine-freebsd loader, which is thought to be the absolute minimum required to support FreeBSD 6, where malloc doesn't fall back on mmap if it runs out of this heap space.
Would it make a significant difference if we were to require a minimum of FreeBSD 7.0? If so, that might be an option with the release of 7.1 pending.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #24 from Austin English austinenglish@gmail.com 2008-12-29 16:33:15 --- Alexey Suslikov (he's working on the OpenBSD wine port and has helped me get it working) asked me to post this: "From http://www.openbsd.org/security.html
New Technologies
As we audit source code, we often invent new ways of solving problems. Sometimes these ideas have been used before in some random application written somewhere, but perhaps not taken to the degree that we do.
* strlcpy() and strlcat() * Memory protection purify o W^X o .rodata segment o Guard pages o Randomized malloc() o Randomized mmap() o atexit() and stdio protection * Privilege separation * Privilege revocation * Chroot jailing * New uids * ProPolice * ... and others
Tijl Coosemans (on 16023) refers to SELinux as for randomized mmap and arguing for ELF pre-loader for wine while Alexandre Julliard objects.
What I'm asking for, is to provide a links to above security.html page and simply tell about randomized mmap is not only for SELinux but also for OpenBSD.
Alexey"
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #25 from Tijl Coosemans tijl@ulyssis.org 2008-12-29 17:36:24 --- Interesting. But to clarify a few things, the preloader and the ELF loader are different things. The wine-preloader already exists for Linux (loader/preloader.c). It's a static program that reserves some memory regions that are important to Wine and then loads the actual Wine program. The ELF loader I'm suggesting would be to allow Wine to load .dll.so libraries in the way it wants to independent of the system ELF loader.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #26 from François Gouget fgouget@codeweavers.com 2008-12-31 13:34:40 --- Created an attachment (id=18354) --> (http://bugs.winehq.org/attachment.cgi?id=18354) Let Wine allocate the pthread stack
This is not FreeBSD specific but is needed in order to avoid threading problems after applying the next patch.
I tested this patch on Linux and in my limited testing it worked ok: the memory got allocated correctly, ntdll carved the guard page as expected, and it released the memory too when the thread closed.
http://bugs.winehq.org/show_bug.cgi?id=16023
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #17748|0 |1 is obsolete| |
--- Comment #27 from François Gouget fgouget@codeweavers.com 2008-12-31 13:41:59 --- Created an attachment (id=18355) --> (http://bugs.winehq.org/attachment.cgi?id=18355) Reenable the memory reservation code on FreeBSD
I did not test this patch at all on FreeBSD (I don't have access to a FreeBSD machine right now), but it's a simple tweak of the previous memory reservation patch.
Applied alone it breaks threading. But combined with the patch to pthread.c it should get things working again on FreeBSD and seems nearer the to right way to fix things than my previous attempt (but that seems to be a fickle thing).
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #28 from Austin English austinenglish@gmail.com 2009-01-01 17:21:20 --- (In reply to comment #27)
Created an attachment (id=18355)
--> (http://bugs.winehq.org/attachment.cgi?id=18355) [details]
Reenable the memory reservation code on FreeBSD
I did not test this patch at all on FreeBSD (I don't have access to a FreeBSD machine right now), but it's a simple tweak of the previous memory reservation patch.
Applied alone it breaks threading. But combined with the patch to pthread.c it should get things working again on FreeBSD and seems nearer the to right way to fix things than my previous attempt (but that seems to be a fickle thing).
Thanks Francois! I've only got a FreeBSD box at work, and OpenBSD at home, which isn't quite up to running yet. I'll test this Saturday at the earliest, Monday at the latest.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #29 from Austin English austinenglish@gmail.com 2009-01-03 11:46:46 --- Alexey Suslikov (OpenBSD Wine port maintainer) asked me to post this:
"Also, can you comment in 16023 and point to a patch in 16666 which disables linking with -Wl,--section-start,.interp=0x7bf00400 in order to bring wine close to a working state on OpenBSD.
I believe it is related to what Tijl describes as "-image-base problem".
Please refer to http://www.openbsd.org/papers/rp2007-slides.pdf wrt OpenBSD's ld.so which
- load libraries at random memory locations, - load libraries in random order.
I think this is important in context of ELF loader discussion in 16023."
The patch he's referring to is: http://bugs.winehq.org/attachment.cgi?id=18415
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #30 from Tijl Coosemans tijl@ulyssis.org 2009-01-03 15:29:32 --- With image-base problem I'm referring to ntdll.dll.so and kernel32.dll.so which are linked with the -image-base flag. It is used to give them a fixed location in memory. On Linux this is implemented in winegcc using the prelink utility. Other platforms as far as I know don't support a base address for DSOs. From what I've been told this is needed to get more sophisticated copy protection schemes working. These don't work on FreeBSD at the moment.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #31 from Vitaliy Margolen vitaliy@kievinfo.com 2009-01-03 19:34:53 --- (In reply to comment #30)
From what I've been told this is needed to get more sophisticated copy protection schemes working.
Some programs always assume that core dlls exist in all processes at the same base addresses. And use this assumption for some nasty stuff.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #32 from Austin English austinenglish@gmail.com 2009-01-03 19:52:58 --- (In reply to comment #31)
(In reply to comment #30)
From what I've been told this is needed to get more sophisticated copy protection schemes working.
Some programs always assume that core dlls exist in all processes at the same base addresses. And use this assumption for some nasty stuff.
This is one of the cases where we'll likely have to take the good with the bad. A lot of viruses/etc., use this behavior, but some anti-hack, etc. does as well.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #33 from Austin English austinenglish@gmail.com 2009-01-05 10:11:49 --- (In reply to comment #27)
Created an attachment (id=18355)
--> (http://bugs.winehq.org/attachment.cgi?id=18355) [details]
Reenable the memory reservation code on FreeBSD
I did not test this patch at all on FreeBSD (I don't have access to a FreeBSD machine right now), but it's a simple tweak of the previous memory reservation patch.
Applied alone it breaks threading. But combined with the patch to pthread.c it should get things working again on FreeBSD and seems nearer the to right way to fix things than my previous attempt (but that seems to be a fickle thing).
On the first boot in a WINEPREFIX: err:qmgr:register_server register_service failed: 1722 err:seh:setup_exception_record stack overflow 892 bytes in thread 000b eip 7e1bcaca esp 00250fb4 stack 0x250000-0x251000-0x350000
Which are both caused by these patches (tested with notepad, which still works either way).
If you need ssh access to a PC-BSD box, let me know...I can arrange something.
http://bugs.winehq.org/show_bug.cgi?id=16023
Sven Schellack sven.schellack@arcor.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sven.schellack@arcor.de
--- Comment #34 from Sven Schellack sven.schellack@arcor.de 2009-01-21 12:58:03 --- (In reply to comment #33) Tested the patches on
schel@~: uname -a FreeBSD dawn.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Jan 21 18:05:02 CET 2009 root@dawn.local:/usr/obj/usr/src/sys/DAWN i386
with the latest Nvidia driver (180.22) and World of Warcraft. It refuses to start. Output:
err:qmgr:register_server register_service failed: 1726 err:module:load_builtin_dll failed to load .so lib for builtin L"glu32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire address space failed: Cannot allocate memory err:module:load_builtin_dll failed to load .so lib for builtin L"opengl32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire address space failed: Cannot allocate memory err:seh:setup_exception_record stack overflow 12 bytes in thread 000b eip 7f5748a0 esp 00251324 stack 0x250000-0x251000-0x350000 err:process:__wine_kernel_init boot event wait timed out err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"Z:\home\schel\.wine\drive_c\Programme\World of Warcraft\Wow.exe" failed, status c0000005
http://bugs.winehq.org/show_bug.cgi?id=16023
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |blocker Target Milestone|--- |1.2.0
--- Comment #35 from Austin English austinenglish@gmail.com 2009-01-28 18:06:30 --- Blocks testing with winetest.exe, breaks wine on multiple platforms, well understood, and patch available => nominating for 1.2 and changing severity to blocker.
http://bugs.winehq.org/show_bug.cgi?id=16023
David Jackson norstar39@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |norstar39@gmail.com
--- Comment #36 from David Jackson norstar39@gmail.com 2009-01-31 10:56:13 --- I have encountered this bug as well, on FreeBSD 7.1 using Wine 1.1.13. Has this bug been fixed so far in the patches, if so which patches should I apply? Will it work on FreeBSD 7.1? When will it be integrated into a Wine release? Thank you.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #37 from Tijl Coosemans tijl@ulyssis.org 2009-02-01 05:09:56 --- (In reply to comment #36)
I have encountered this bug as well, on FreeBSD 7.1 using Wine 1.1.13. Has this bug been fixed so far in the patches, if so which patches should I apply? Will it work on FreeBSD 7.1? When will it be integrated into a Wine release? Thank you.
The FreeBSD port has a workaround, so if you installed Wine from ports or as package, you shouldn't see this problem. The patch can be found at: http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/wine/files/patch-dlls-... It's similar to the "memory patch" attached to this bug above.
http://bugs.winehq.org/show_bug.cgi?id=16023
pabloignacio00@gmail.com pabloignacio00@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pabloignacio00@gmail.com
--- Comment #38 from pabloignacio00@gmail.com 2009-02-22 05:03:54 --- When i want to run any Windows application in FreeBSD, it continues on the Wine version 1.1.14, with the message (invalid address), then i copied the correspondent memory patch on the ntdll code, ant the problem was fixed. Would use this code by default on new versions of Wine.
http://bugs.winehq.org/show_bug.cgi?id=16023
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18354|0 |1 is obsolete| |
--- Comment #39 from Alexandre Julliard julliard@winehq.org 2009-02-24 08:17:24 --- (From update of attachment 18354) Thread stacks are now always allocated by Wine.
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #40 from François Gouget fgouget@codeweavers.com 2009-03-08 17:42:37 --- Now that Alexandre has fixed the big threading roadblock by allocating the thread stack in ntdll, my patch to reenable the memory reservation gets Wine working again on FreeBSD :-).
So I sent this patch to wine-patches...
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #41 from Austin English austinenglish@gmail.com 2009-03-08 18:08:57 --- (In reply to comment #40)
Now that Alexandre has fixed the big threading roadblock by allocating the thread stack in ntdll, my patch to reenable the memory reservation gets Wine working again on FreeBSD :-).
So I sent this patch to wine-patches...
I'll keep my fingers crossed for Monday then.
If so, I owe you both a beer or two ;-).
http://bugs.winehq.org/show_bug.cgi?id=16023
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
--- Comment #42 from Austin English austinenglish@gmail.com 2009-03-09 22:49:54 --- (In reply to comment #40)
Now that Alexandre has fixed the big threading roadblock by allocating the thread stack in ntdll, my patch to reenable the memory reservation gets Wine working again on FreeBSD :-).
So I sent this patch to wine-patches...
Yep, works great :-).
http://bugs.winehq.org/show_bug.cgi?id=16023
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
--- Comment #43 from François Gouget fgouget@codeweavers.com 2009-03-10 05:33:07 --- Great! Marking verified (I should do that, right?).
http://bugs.winehq.org/show_bug.cgi?id=16023
--- Comment #44 from Austin English austinenglish@gmail.com 2009-03-10 05:34:56 --- (In reply to comment #43)
Great! Marking verified (I should do that, right?).
I don't see it being done elsewhere...
http://bugs.winehq.org/show_bug.cgi?id=16023
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CLOSED
--- Comment #45 from Alexandre Julliard julliard@winehq.org 2009-03-13 11:15:42 --- Closing bugs fixed in 1.1.17.
-
wine-bugs＠winehq.org