I'm just wondering if it is supposed to work as well as FreeBSD stable.
Right now, Wine doesn't work at all on FreeBSD -STABLE:
wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory
and before that I used to see deadlocks upon startup of non-trivial applications (such as Forte Agent, both 16bit and 32bit flavors).
I believe there are also signficant threadings issues on -CURRENT, so overall Wine is hardly, if at all, usable on any version of FreeBSD I have access to, even though I'm still working to keep it at least compilable on FreeBSD 4.9 and 5.2/5.3.
Gerald
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 16 June 2004 12:49, Gerald Pfeifer wrote:
I'm just wondering if it is supposed to work as well as FreeBSD stable.
Right now, Wine doesn't work at all on FreeBSD -STABLE:
wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory
I get the same problem on -CURRENT with recent CVS versions of wine. Hopefully, in the port of the new release, this will bee worked out and maybe I can stick with the port and not mess with CVS.
- -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX
On Wed, 16 Jun 2004, Jonathan Fosburgh wrote:
wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory
I get the same problem on -CURRENT with recent CVS versions of wine. Hopefully, in the port of the new release, this will bee worked out and maybe I can stick with the port and not mess with CVS.
Given that I'm the maintainer of the wine port in FreeBSD, I can say quite authoritatively that I probably won't update to the latest snapshot, unless some third party is able to provide a patch to fix this breakage. :-(
Gerald
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 16 June 2004 13:19, Gerald Pfeifer wrote:
Given that I'm the maintainer of the wine port in FreeBSD, I can say quite authoritatively that I probably won't update to the latest snapshot, unless some third party is able to provide a patch to fix this breakage.
I tried to look through the mmap.c code but I don't have enough of an understanding of what it is supposed to do to figure out how to make it work, or even work around it.
- -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX
On Wed, 16 Jun 2004 13:54:37 -0500, Jonathan Fosburgh wrote:
I tried to look through the mmap.c code but I don't have enough of an understanding of what it is supposed to do to figure out how to make it work, or even work around it.
It provides mmap emulation for some systems and is responsible for enforcing a Win32 compatible address space layout upon the app:
http://winehq.com/site/docs/wine-devel/address-space
thanks -mike
On Wed, Jun 16, 2004 at 07:49:26PM +0200, Gerald Pfeifer wrote:
I'm just wondering if it is supposed to work as well as FreeBSD stable.
Right now, Wine doesn't work at all on FreeBSD -STABLE:
wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory
and before that I used to see deadlocks upon startup of non-trivial applications (such as Forte Agent, both 16bit and 32bit flavors).
I believe there are also signficant threadings issues on -CURRENT, so overall Wine is hardly, if at all, usable on any version of FreeBSD I have access to, even though I'm still working to keep it at least compilable on FreeBSD 4.9 and 5.2/5.3.
Hi Gerald,
Thanks for the reply.
From what I can see, there are two problems with the Wine build from CVS
on FreeBSD -current that seem to be related to the use of BSD make. In the dlls 'setupapi' and 'version' directories there are source files called install.c. These confuse the build during a "make install". BSD make tries to compile and link a program called "install". Renaming the source files to something other than install.c (such as winstall.c) allows the build to succeed.
At run time, the error:
"wine: failed to initialize: /something/lib/wine/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory"
is caused by Wine attempting to mmap memory outside the user process address space. I see mmap addr around 0xd8100000 (mostly 0xd81eccd8) whereas the user address space limit on FreeBSD current is 0xbfc00000 (at least on my system).
This failure is well before any thread library issues are encountered.
I ran a test of mmap on FreeBSD current to see what address space I was able to mmap. Using objdump to identify the pages that the test program was linked to load in, the test program was able to mmap MAP_ANON, MAP_FIXED, MAP_NOCORE all memory from 0x0 to 0xbfc00000, except the pages at which the test program was mapped at.
I'll look further into how Wine is mmap'ing memory on FreeBSD.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 16 June 2004 22:52, John Birrell wrote:
Thanks for the reply.
From what I can see, there are two problems with the Wine build from CVS on FreeBSD -current that seem to be related to the use of BSD make. In the dlls 'setupapi' and 'version' directories there are source files called install.c. These confuse the build during a "make install". BSD make tries to compile and link a program called "install". Renaming the source files to something other than install.c (such as winstall.c) allows the build to succeed.
At run time, the error:
"wine: failed to initialize: /something/lib/wine/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory"
is caused by Wine attempting to mmap memory outside the user process address space. I see mmap addr around 0xd8100000 (mostly 0xd81eccd8) whereas the user address space limit on FreeBSD current is 0xbfc00000 (at least on my system).
This failure is well before any thread library issues are encountered.
I ran a test of mmap on FreeBSD current to see what address space I was able to mmap. Using objdump to identify the pages that the test program was linked to load in, the test program was able to mmap MAP_ANON, MAP_FIXED, MAP_NOCORE all memory from 0x0 to 0xbfc00000, except the pages at which the test program was mapped at.
I'll look further into how Wine is mmap'ing memory on FreeBSD.
Thanks for the info. :) I never use BSD make to build wine, in fact, BSD make has always failed horribly for me. When I build from CVS I always use gmake and rarely does the build fail when I do that. As to the threading issue, the error I get is:
Fatal error 'Uninitialized mutex in pthread_mutex_trylock_basic' at line 474 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 22)
In limited testing I received the same errors when libmaping libpthread to libthr. Wine is somewhat useable with libc_r right now. I will do some more testing on that. - -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX
On Thu, 17 Jun 2004, John Birrell wrote:
"wine: failed to initialize: /something/lib/wine/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory"
is caused by Wine attempting to mmap memory outside the user process address space. I see mmap addr around 0xd8100000 (mostly 0xd81eccd8) whereas the user address space limit on FreeBSD current is 0xbfc00000 (at least on my system). [...] I ran a test of mmap on FreeBSD current to see what address space I was able to mmap. Using objdump to identify the pages that the test program was linked to load in, the test program was able to mmap MAP_ANON, MAP_FIXED, MAP_NOCORE all memory from 0x0 to 0xbfc00000, except the pages at which the test program was mapped at.
Thanks for the fine analysis, John!
I wonder, is there some way to avoid the "bad" mmapping on FreeBSD, change Wine, or do we have to get FreeBSD changes?
Gerald
On Sun, Jun 20, 2004 at 04:57:43PM +0200, Gerald Pfeifer wrote:
On Thu, 17 Jun 2004, John Birrell wrote:
"wine: failed to initialize: /something/lib/wine/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory"
is caused by Wine attempting to mmap memory outside the user process address space. I see mmap addr around 0xd8100000 (mostly 0xd81eccd8) whereas the user address space limit on FreeBSD current is 0xbfc00000 (at least on my system). [...] I ran a test of mmap on FreeBSD current to see what address space I was able to mmap. Using objdump to identify the pages that the test program was linked to load in, the test program was able to mmap MAP_ANON, MAP_FIXED, MAP_NOCORE all memory from 0x0 to 0xbfc00000, except the pages at which the test program was mapped at.
Thanks for the fine analysis, John!
I wonder, is there some way to avoid the "bad" mmapping on FreeBSD, change Wine, or do we have to get FreeBSD changes?
From what I can see, the FreeBSD mmap address allocation behaviour that I see
isn't documented. From the documentation, I would have expected the Wine code to work - it doesn't seem unreasonable to me.
I think the FreeBSD kernel code needs to change. If this is to happen, it will only be in the FreeBSD5 tree. It is too late in the FreeBSD4 branch to make that sort of change since it's not really a bug fix.
To get Wine to work on FreeBSD4, there needs to be a way of making the reservation code optional. A simple mmap test in configure which snaffles memory above 0x80000000 and then tries to mmap some more memory without specifying a fixed address would detect if mmap is behaving in a way that would allow the Wine reservation code to function.
For FreeBSD5, which will become the stable branch sometime soon, I think the kernel code needs to change. I have a FreeBSD src commit bit, but I'm not a vm person, so I can only prototype a change and submit it for review. I'm not sure if the other developers will regard this change favourably, though. They may take the attitude that if Wine can be made to work with the FreeBSD kernel code as is, then Wine should be coded accordingly.
If the Wine code was restructured to make the reservation code optional, that would cover both FreeBSD4 and FreeBSD5. Then, if the FreeBSD mmap algorithm was to change in the future, the build could start using the reservation code at that time.
John Birrell jb@cimlogic.com.au writes:
To get Wine to work on FreeBSD4, there needs to be a way of making the reservation code optional. A simple mmap test in configure which snaffles memory above 0x80000000 and then tries to mmap some more memory without specifying a fixed address would detect if mmap is behaving in a way that would allow the Wine reservation code to function.
Well, there's a reason for that reservation code, and it's that some Windows apps require it; so unless you find some other way to ensure that FreeBSD never allocates anything above 0x80000000, the reservation code can't really be made optional.
On Mon, 21 Jun 2004, John Birrell wrote:
For FreeBSD5, which will become the stable branch sometime soon, I think the kernel code needs to change. I have a FreeBSD src commit bit, but I'm not a vm person, so I can only prototype a change and submit it for review.
Excellent, thanks! Would you mind keeping me in the loop (as I'm maintaining the FreeBSD emulators/wine port)?
I'm not sure if the other developers will regard this change favourably, though. They may take the attitude that if Wine can be made to work with the FreeBSD kernel code as is, then Wine should be coded accordingly.
Well, as long as they tell us _how_ to change Wine, and in a way that will be acceptable to Alexandre... :-)
If the Wine code was restructured to make the reservation code optional, that would cover both FreeBSD4 and FreeBSD5. Then, if the FreeBSD mmap algorithm was to change in the future, the build could start using the reservation code at that time.
I agree...
On Sun, 20 Jun 2004, Alexandre Julliard wrote:
Well, there's a reason for that reservation code, and it's that some Windows apps require it; so unless you find some other way to ensure that FreeBSD never allocates anything above 0x80000000, the reservation code can't really be made optional.
...and in fact, Alexandre, wouldn't it be better to have _some_ apps broken under Wine on FreeBSD than a completely broken Wine on FreeBSD for all apps?
Gerald
On Tue, Jun 22, 2004 at 11:36:16PM +0200, Gerald Pfeifer wrote:
On Sun, 20 Jun 2004, Alexandre Julliard wrote:
Well, there's a reason for that reservation code, and it's that some Windows apps require it; so unless you find some other way to ensure that FreeBSD never allocates anything above 0x80000000, the reservation code can't really be made optional.
...and in fact, Alexandre, wouldn't it be better to have _some_ apps broken under Wine on FreeBSD than a completely broken Wine on FreeBSD for all apps?
While there aren't many FreeBSD people using Wine, I can't see the Wine folks wanting to spend any time jumping through hoops for a negligible user base.
In fact, it's possible that the code to change FreeBSD's mmap address allocation algorithm is actually simpler than the changes to Wine required to make the registration code optional. I need to do more work to confirm that, but that's my gut feeling at the moment.
Gerald Pfeifer pfeifer@dbai.tuwien.ac.at writes:
...and in fact, Alexandre, wouldn't it be better to have _some_ apps broken under Wine on FreeBSD than a completely broken Wine on FreeBSD for all apps?
Nope. What matters is not so much how many apps run today, but that we have a design that will allow at some point in the future to run all possible apps. We shouldn't compromise on a design that guarantees that some apps will *never* run just because it runs more apps today. Besides, a completely broken Wine is the best way to ensure that someone starts worrying about the issue <g>
On Tue, 22 Jun 2004, Alexandre Julliard wrote:
Gerald Pfeifer pfeifer@dbai.tuwien.ac.at writes:
...and in fact, Alexandre, wouldn't it be better to have _some_ apps broken under Wine on FreeBSD than a completely broken Wine on FreeBSD for all apps?
Nope. What matters is not so much how many apps run today, but that we have a design that will allow at some point in the future to run all possible apps. We shouldn't compromise on a design that guarantees that some apps will *never* run just because it runs more apps today. Besides, a completely broken Wine is the best way to ensure that someone starts worrying about the issue <g>
Sadly, that's not how it worked this time. Rather, FreeBSD users are still using an old version of Wine, and Wine mainline gets worse and worse on that platform.
Would you mind considering the patch below, so that we can at least make some progress?
Gerald
ChangeLog: Disable memory reservation code on FreeBSD, where it just doesn't work? Index: libs/wine/mmap.c =================================================================== RCS file: /home/wine/wine/libs/wine/mmap.c,v retrieving revision 1.7 diff -u -3 -p -r1.7 mmap.c --- libs/wine/mmap.c 24 Jul 2004 02:30:09 -0000 1.7 +++ libs/wine/mmap.c 30 Oct 2004 20:04:47 -0000 @@ -254,6 +254,9 @@ void mmap_init(void) struct reserved_area *area; struct list *ptr; #ifdef __i386__ +#if ! defined(__FreeBSD__) + /* FIXME: this is broken on FreeBSD (verified on 4.10 and 5.2.1). */ + char stack; char * const stack_ptr = &stack; char *user_space_limit = (char *)0x80000000; @@ -280,6 +283,7 @@ void mmap_init(void) /* Linux heuristic: if the stack top is at c0000000, assume the address space */ /* ends there, this avoids a lot of futile allocation attempts */ if (base != (char *)0xc0000000) +#endif #endif reserve_area( base, 0 ); }
-
Alexandre Julliard -
Gerald Pfeifer -
Gerald Pfeifer -
John Birrell -
Jonathan Fosburgh -
Mike Hearn