16 Jun
2004
16 Jun
'04
5:49 p.m.
> 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
--
Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/
16 Jun
16 Jun
5:58 p.m.
New subject: Wine on FreeBSD current
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 16 June 2004 12:49, Gerald Pfeifer wrote:
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
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA0Io4qUvQmqp7omYRAjroAKCy/HQJ2y3Y9Y8n7rRoS8yqkxNozwCfZfcP
OpleJ+reEedjRT3o3UDzr6Y=
=/tbJ
-----END PGP SIGNATURE-----
6:19 p.m.
New subject: Wine on FreeBSD current
On Wed, 16 Jun 2004, Jonathan Fosburgh 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.
:-(
Gerald
--
Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/
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.
6:54 p.m.
New subject: Wine on FreeBSD current
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA0JdxqUvQmqp7omYRAkQJAJ9MGV4Z/lVYw1WOw7YL01BgLQ+QRQCfbF6P
gKjb73HptvibzRDRqmsy8B0=
=dpxK
-----END PGP SIGNATURE-----
17 Jun
17 Jun
3:52 a.m.
New subject: Wine on FreeBSD current
On Wed, Jun 16, 2004 at 07:49:26PM +0200, Gerald Pfeifer wrote:
Hi Gerald,
Thanks for the reply.
> 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. 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.
--
John Birrell
12:47 p.m.
New subject: Wine on FreeBSD current
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA0ZL8qUvQmqp7omYRAlEeAKDKPinkmDGmCXSe49iqoGzJS/ZI9ACdHUsb
xzmrBeZo7GFsvq6Ow1payoI=
=8l67
-----END PGP SIGNATURE-----
1:26 p.m.
New subject: Wine on FreeBSD current
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
20 Jun
20 Jun
2:57 p.m.
New subject: Wine on FreeBSD current
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
--
Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/
9:04 p.m.
New subject: Wine on FreeBSD current
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
9:34 p.m.
New subject: Wine on FreeBSD current
John Birrell <jb(a)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.
--
Alexandre Julliard
julliard(a)winehq.org
22 Jun
22 Jun
9:36 p.m.
New subject: Wine on FreeBSD current
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
9:43 p.m.
New subject: Wine on FreeBSD current
On Tue, Jun 22, 2004 at 11:36:16PM +0200, Gerald Pfeifer wrote:
On Sun, 20 Jun 2004, Alexandre Julliard wrote:
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.
--
John Birrell
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?
10:05 p.m.
New subject: Wine on FreeBSD current
Gerald Pfeifer <pfeifer(a)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>
--
Alexandre Julliard
julliard(a)winehq.org
30 Oct
30 Oct
8:21 p.m.
New subject: Wine on FreeBSD current
On Tue, 22 Jun 2004, Alexandre Julliard wrote:
Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at>
writes:
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 );
}
...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>
7141
days inactive
7277
days old
13 comments
6 participants
participants (6)
-
Alexandre Julliard -
Gerald Pfeifer -
Gerald Pfeifer -
John Birrell -
Jonathan Fosburgh -
Mike Hearn