Ubuntu
wine package

Problem with wine preloader: Warning: failed to reserve range 00000000-60000000

Bug #114025 reported by Bart Kroon
144
Affects Status Importance Assigned to Milestone
Wine
Invalid
Medium
wine (Baltix)
New
Undecided
Unassigned
wine (Ubuntu)
Fix Released
Medium
Ubuntu Wine Team
Declined for Hardy by Scott Ritchie

Bug Description

Binary package hint: wine

Run wine or winecfg with or without arguments.

Feisty 7.04
wine 0.9.33

Tags: regression

CVE References

Revision history for this message
Stephan Rügamer (sruegamer) wrote :

Strange,

can you delete your ~/.wine directory first, and try again, just because there is no such crash ... most of time, you have old config stuff in your .wine dir.

Regards,

\sh

Changed in wine:
assignee: nobody → ubuntu-wine
Revision history for this message
Bart Kroon (bart-kroon) wrote :

I already removed the ~/.wine directory during testing and it doesn't even get created when I run wine:

bart@pc67243857:10:05:50|0:~$ ls .wine
ls: .wine: No such file or directory
bart@pc67243857:10:08:37|0:~$ wine
preloader: Warning: failed to reserve range 00000000-60000000
Usage: wine PROGRAM [ARGUMENTS...] Run the specified program
       wine --help Display this help and exit
       wine --version Output version information and exit
bart@pc67243857:10:08:41|0:~$ win
wine winebrowser wineconsole winedump winegcc winemaker wineprefixcreate wineserver
wine-auto winebuild winecpp winefile wine-kthread winemine wine-preloader wineshelllink
wineboot winecfg winedbg wineg++ winelauncher winepath wine-pthread winhelp
bart@pc67243857:10:08:41|0:~$ wineconsole
preloader: Warning: failed to reserve range 00000000-60000000
wine: failed to initialize: /usr/lib/wine/ntdll.dll.so: failed to map segment from shared object: Cannot allocate memory
bart@pc67243857:10:08:49|0:~$ winegcc
i486-linux-gnu-gcc: no input files
winegcc: i486-linux-gnu-gcc failed.
bart@pc67243857:10:08:54|0:~$ winecfg
preloader: Warning: failed to reserve range 00000000-60000000
wine: failed to initialize: /usr/lib/wine/ntdll.dll.so: failed to map segment from shared object: Cannot allocate memory
bart@pc67243857:10:08:58|0:~$ winemine
preloader: Warning: failed to reserve range 00000000-60000000
wine: failed to initialize: /usr/lib/wine/ntdll.dll.so: failed to map segment from shared object: Cannot allocate memory
bart@pc67243857:10:09:09|0:~$ ls .wine
ls: .wine: No such file or directory
bart@pc67243857:10:09:15|0:~$

Do you want me to test something else?

Revision history for this message
Scott Ritchie (scottritchie) wrote :

Hmmm....

Do you by any chance have some special security settings enabled? It looks like there's a problem with prelink doing its thing.

Revision history for this message
Bart Kroon (bart-kroon) wrote : Re: [Bug 114025] Re: Problem with wine preloader: Warning: failed to reserve range 00000000-60000000

Security is as out-of-the-box. I installed Edgy then after some months when
Feisty became the stable version I upgraded to Feisty.

LAN is by Ethernet with DHCP and Internet is via a proxy but I don't think
you need internet to run wine.

I'm not the only one having this error:
http://www.google.com/search?hl=en&client=firefox-a&rls=com.ubuntu%3Aen-US%3Aofficial&hs=EWI&q=failed+to+reserve+range+00000000-60000000&btnG=Search

Wish I could help more but I have no clue about this error myself,

Bart

2007/5/29, Scott Ritchie <email address hidden>:
>
> Hmmm....
>
> Do you by any chance have some special security settings enabled? It
> looks like there's a problem with prelink doing its thing.
>
> --
> Problem with wine preloader: Warning: failed to reserve range
> 00000000-60000000
> https://bugs.launchpad.net/bugs/114025
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
----------------------------
Bart Kroon
Sint Jansstraat 24
5507 ND Veldhoven (Oerle)
msn: <email address hidden>
Tel.: +31 40 2377667
GSM: +31 6 27248320
http://bartkroon.eu

Revision history for this message
Bart Kroon (bart-kroon) wrote :

Plz remove my signature if possible. I made a mistake with my e-mailprogram.

Revision history for this message
Scott Ritchie (scottritchie) wrote :

Are things working for you in Gutsy?

Revision history for this message
Bart Kroon (bart-kroon) wrote :

Solved now

2007/10/23, Scott Ritchie <email address hidden>:
>
> Are things working for you in Gutsy?
>
> --
> Problem with wine preloader: Warning: failed to reserve range
> 00000000-60000000
> https://bugs.launchpad.net/bugs/114025
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
----------------------------
Bart Kroon
Sint Jansstraat 24
5507 ND Veldhoven (Oerle)
msn: <email address hidden>
Tel.: +31 40 2377667
GSM: +31 6 27248320
http://bartkroon.eu

Revision history for this message
zjaak (zjaakie) wrote :

Ive got the problem now.. So how did you solve it??

Revision history for this message
Dan Kegel (dank) wrote :

zjaak, what version of Ubuntu and what version of Wine are you using?

Revision history for this message
Nemes Ioan Sorin (nemes-sorin) wrote :

I have to subscribe to this bug, Hardy Heron up to date, wine-0.9.52 || No problems with wine-0.9.51

Revision history for this message
Roderick B. Greening (roderick-greening) wrote :

I have this too under Hardy Heron with wine 0.9.52, but not when it was 0.9.51. What is an appropriate way to revert to 0.9.51 to verify problem does not exist under 0.9.51? I tried to PIN 0.9.51 with a 1001 priority, but I believe that 0.9.51 is not in the repo now.

Revision history for this message
Dan Kegel (dank) wrote :

On Jan 8, 2008 12:23 PM, Roderick Greening <email address hidden> wrote:
> I have this too under Hardy Heron with wine 0.9.52, but not when it was
> 0.9.51. What is an appropriate way to revert to 0.9.51 to verify problem
> does not exist under 0.9.51? I tried to PIN 0.9.51 with a 1001 priority,
> but I believe that 0.9.51 is not in the repo now.

You can grab gutsy's 0.9.51 from
http://wine.budgetdedicated.com/archive/index.html
it will probably work on Hardy.
Let me know if that works for you.

Revision history for this message
Kees Cook (kees) wrote :

This is likely related to the extra security changes added to /etc/sysctl.conf (vm.mmap_min_addr = 65536). As a work-around, set this to 0. Hopefully wine can be built in a way that it doesn't have to reserve the lower 64k all the time.

Revision history for this message
Brian Murray (brian-murray) wrote :

I tried the workaround mentioned by Kees and set '/proc/sys/vm/mmap_min_addr' to 0, however executing winecfg still produces an error albeit a different one.

wine: Unhandled page fault on read access to 0x00000000 at address 0xf7da5d03 (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0xf7da5d03).

I can provide a full register dump, stack dump and backtrace if needed.

Changed in wine:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Brian Murray (brian-murray) wrote :

Here is the crash with /proc/sys/vm/mmap_min_addr set to 0.

Revision history for this message
Brian Murray (brian-murray) wrote :

The error is slightly different with /proc/sys/vm/mmap_min_addr set to the default - 65536.

preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
wine: Unhandled page fault on read access to 0x00000000 at address 0xf7d81d03 (thread 0009), starting debugger...
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0xf7d81d03).

From there on out it is the same except for the memory locations.

Revision history for this message
Brian Murray (brian-murray) wrote :

I've been unable to reproduce this on my laptop however, even with mmap_min_addr set to the default winecfg will warn but continue to execute.

Revision history for this message
Test-tools (roland-verifysoft) wrote :

Hello,

I downgraded on hardy from .55 to .51-winehq, as advised above, still the preloader warning:
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report

But the program works after that....

 Roland

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package wine - 0.9.56-0ubuntu1

---------------
wine (0.9.56-0ubuntu1) hardy; urgency=low

  * New upstream release (LP: #197588)
    - Proper handling of OpenGL/Direct3D windows with menu bars.
    - Stubs for all the d3dx9_xx dlls.
    - Several graphics optimizations.
    - Many installer fixes.
    - Improved MIME message support.
    - Lots of bug fixes.
  * debian/rules:
    - reset LDFLAGS to let wine not crash anymore, (LP: #191575)
      thx to Albert Damen <email address hidden> who came up with this solution.
      (http://www.winehq.org/pipermail/wine-bugs/2007-July/062505.html)
    - adjust dh_strip call (LP: #185513)
  * debian/control:
    - remove gcc-3.4 build-dep
    - get rid of quilt
  * cleaned debian/patches
  * Add finnish translation to desktop files (LP: #196916)
  * dlls/winealsa.drv/waveinit.c: (LP: #195507)
    - let wine use the default alsa device
      (http://bugs.winehq.org/show_bug.cgi?id=10942)
  * Preloader warning (preloader: Warning: failed to reserve range
    00000000-60000000) does not occure anymore (LP: #114025)

 -- Stephan Hermann <email address hidden> Fri, 22 Feb 2008 20:10:36 +0100

Changed in wine:
status: Confirmed → Fix Released
Revision history for this message
In , Michael Abbott (michael-araneidae) wrote :

Every run of wine on my system (including wineprefixcreate on a freshly created prefix directory) produces the following messages several times:

preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report

As the message requests, I am reporting it.

This is running Ubuntu Hardy Heron beta with wine version 0.9.59, or as it reports it:

$ wine --version
preloader: Warning: failed to reserve range 00000000-60000000
wine-0.9.59
$

Revision history for this message
In , Hans-meelstraat (hans-meelstraat) wrote :

I'm seeing the same thing on recent Fedora kernels. This command works
around the problem:

$ sudo sysctl -w vm.mmap_min_addr=0

To make this setting permanent, add this line to /etc/sysctl.conf:

vm.mmap_min_addr=0

Revision history for this message
In , Michael Abbott (michael-araneidae) wrote :

> $ sudo sysctl -w vm.mmap_min_addr=0
>
> To make this setting permanent, add this line to /etc/sysctl.conf:
> vm.mmap_min_addr=0

That's very helpful. I think this page http://www.linuxinsight.com/proc_sys_vm_mmap_min_addr.html explains the logic of this setting and probably why it's changed recently.

Of course, this means that the message from Wine needs to change. Presumably if it's really a problem then it actually needs to be fixed by the user (or the wine install? ... probably a bad idea).

Revision history for this message
zegenie (zegenie) wrote :

This error is back with 0.9.59

Changed in wine:
status: Fix Released → New
Revision history for this message
zegenie (zegenie) wrote :

I get this error when trying to run winecfg on a clean hardy install.

Revision history for this message
Roberto Cássio Jr. (rcsdnj) wrote :

0.9.59 gives the same problem here, too.

Artin (artin)
Changed in wine:
status: New → Confirmed
Revision history for this message
sixtysevenfordpu (stephen-c-moss) wrote :

I have two instances of Hardy Heron, 8.04 Beta, one on AMD system, the other on dual proc Intel P3 1mhz system, both are at the same Linux kernel and same version of Wine:

Neither "wineconfig" nor "winecfg" work on this version:
  Linux badge 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux
  wine-0.9.59

Both "wineconfig" and "winecfg" work on this version after reporting bunch of warnings and messages:
  Linux doubledog 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux
  wine-0.9.59

NOTE: I made the above "vm.mmap_min_addr = 0" change to /etc/sysctl.conf on both systems.

I see that on both systems any Windows application that worked in Gutsy Gibon (wine 0.9.51?) start and run without errors on Hardy Heron (wine 0.9.59).

When I install a new Windows program, I do see:

   $ wine KEYDC6PLMLPC.exe
  preloader: Warning: failed to reserve range 00000000-60000000
  err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report

In the above example, the Windows program installer runs and no further messages like above appear in Konsole. In this example I don't believe the install will complete as it is looking to install "Microsoft DirectX Feb2006 Runtime", "Microsoft Visual C++ 2005 Redistributable Package (x86)", "Microsoft Media Format 9 Series Runtime" and "Microsoft .Net Framework 3.0 x86".

I haven't tried installing other Windows Applications as of yet.

Revision history for this message
In , Austin English (austinenglish) wrote :

(In reply to comment #2)
> > $ sudo sysctl -w vm.mmap_min_addr=0
> >
> > To make this setting permanent, add this line to /etc/sysctl.conf:
> > vm.mmap_min_addr=0
>
> That's very helpful. I think this page
> http://www.linuxinsight.com/proc_sys_vm_mmap_min_addr.html explains the logic
> of this setting and probably why it's changed recently.
>
> Of course, this means that the message from Wine needs to change. Presumably
> if it's really a problem then it actually needs to be fixed by the user (or
> the wine install? ... probably a bad idea).
>

I sent a patch to wine-patches:
http://www.winehq.org/pipermail/wine-patches/2008-April/053264.html

Revision history for this message
Justin M. (legendarysim) wrote :

I get this same here on the latest (0.9.59) version of WIne. Some applications will give me this error and work and some applications will give me this error and not work at all.

Revision history for this message
In , Michael Abbott (michael-araneidae) wrote :

> http://www.winehq.org/pipermail/wine-patches/2008-April/053264.html

The problem with the message in this patch is that it doesn't give the user much help: the key is of course to look in /proc/sys/vm/mmap_min_addr -- I mean, what is the poor user who doesn't already know the answer to do?

I'd suggest changing the text "edit /etc/sysctl.conf" to the more helpful "add the line vm.mmap_min_addr=0 to /etc/sysctl.conf".

Any chance of somebody marking this as CONFIRMED?!

Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

Confirming.

Revision history for this message
Dan Kegel (dank) wrote :

I filed an upstream bug,
http://bugs.winehq.org/show_bug.cgi?id=12548
though it's possible it can't be fixed in wine alone.

Revision history for this message
In , Dan Kegel (dank) wrote :

*** Bug 12548 has been marked as a duplicate of this bug. ***

Revision history for this message
Stephan Rügamer (sruegamer) wrote :

Lowering Importance, because it's not harming anyone or destroying the system ;)
After all, it's right, the error came back with .59 :( At least for wine32 on amd64...
I'll check later on my i386, if it's there, too

Regards,

\sh

Changed in wine:
importance: High → Medium
Revision history for this message
In , Dan Kegel (dank) wrote :

For completeness, here's the summary I wrote in the dup bug:

The problem
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0600
prompted distributions to raise the default for /proc/sys/vm/mmap_min_addr
or even DEFAULT_MMAP_MIN_ADDR to 64K from 0.
This causes the following error message when starting (some?) wine apps:
  Problem with wine preloader: Warning: failed to reserve range
00000000-60000000
See discussion:
https://launchpad.net/bugs/114025
http://kerneltrap.org/Linux/Patching_CVE-2008-0600_Local_Root_Exploit
http://kerneltrap.org/Linux/2.4.36_Stable_Release

You can check to see if you're on an affected system
by doing "cat /proc/sys/vm/mmap_min". If that succeeds, and its value
is nonzero, you're probably running into this.

To work around the problem temporarily, you can change this value
with the command
 sudo sysctl -w vm.mmap_min_addr=0
but that value gets reset at boot. To work around the problem more
persistantly, also edit the file /etc/sysctl.conf like this:

 # protect bottom 64k of memory from mmap to prevent NULL-dereference
 # attacks against potential future kernel security vulnerabilities.
 # (Added in kernel 2.6.23.)
-vm.mmap_min_addr = 65536
+vm.mmap_min_addr = 0

http://kerneltrap.org/Linux/2.4.36_Stable_Release suggests using
a value of 4096 for this.
"Advanced Windows", 3rd edition, says that the memory area 0 to 4095
is not mapped anyway in windows (it's a guard page).
So maybe when Wine is installed, we could somehow change that value
to 4096, and have Wine's preloader happily continue if it can't
map the bottom page of RAM.

Revision history for this message
Richard (rullger) wrote :

It might not be trashing anything but it prevents me from running any Windows programs on my i386. I'm running v0.9.59 packaged with Ubuntu 8.04. Is it possible to drop back to an earlier version that would work with this setup?

Revision history for this message
Dan Kegel (dank) wrote :

Probably not, because the problem comes from a change to the kernel more than from wine.
Have you tried the
   sudo sysctl -w vm.mmap_min_addr=0
workaround?

Revision history for this message
zegenie (zegenie) wrote :

Well, after running that command, trying to run winecfg or any wine app does not produce the address errors which it previously did.
Not sure what's affected by that command (explanation appreciated), but looks like it's "back to normal" again :)

thanks.

Revision history for this message
In , Austin English (austinenglish) wrote :

Alexandre committed a fix today, which makes some progress:

preloader: Warning: failed to reserve range 00000000-00010000

http://source.winehq.org/git/wine.git/?a=commitdiff;h=f02ef19fdbf5d7396f71433bd26b904577e09fe4
http://source.winehq.org/git/wine.git/?a=commitdiff;h=195ca1e85f01ac40695fbb6fcf9e9e130265f091
http://source.winehq.org/git/wine.git/?a=commitdiff;h=16e8633ee597c68336bc1b1561260fa7d0eced2b

Revision history for this message
sixtysevenfordpu (stephen-c-moss) wrote :

A little more investigation on my part. Found that rather than start winecfg from a Linux Shell prompt, I am able to get that to start on either my AMD system or the Dual Proc Intel by using "Kmenu --> Wine --> Configure Wine" option

Revision history for this message
Jeremy Vies (jeremy.vies) wrote :

The proposed workaround (sudo sysctl -w vm.mmap_min_addr=0) worked for me.
A little investigation made me found this new entry in sysctl.conf:

# protect bottom 64k of memory from mmap to prevent NULL-dereference
# attacks against potential future kernel security vulnerabilities.
# (Added in kernel 2.6.23.)
vm.mmap_min_addr = 65536

I guess it is part of the problem...

Bug Watch Updater (bug-watch-updater)
Changed in wine:
status: Unknown → Confirmed
45 comments hidden view all 125 comments
Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

(In reply to comment #30)
> $ wine --version
> preloader: Warning: failed to reserve range 00000000-60000000
> wine-0.9.59

Your Wine version is too old, current release is rc1. If you would carefully
read the comments in this bug I'd notice that.

Revision history for this message
In , Ansus (neptunia) wrote :

Where to get Wine newer than 0.9.58 for Fedora Core 9 or newer than 0.9.59 for Ubuntu 7.10?

Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

(In reply to comment #32)
> Where to get Wine newer than 0.9.58 for Fedora Core 9 or newer than 0.9.59 for
> Ubuntu 7.10?

Ask that question on the support list of your distribution.

Revision history for this message
In , Alexandre Julliard (julliard) wrote :

*** Bug 13454 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

*** Bug 13444 has been marked as a duplicate of this bug. ***

Revision history for this message
huschy (kannibalenfleisch) wrote :

Had the same message. Was gone when I used root: sudo -i

Revision history for this message
Dan Kegel (dank) wrote :

Right, that's expected, but it's bad to run wine apps as root. For one thing, it contaminates your .wine directory with files owned by root, for another, it makes it easier to get infected with rootkits and the like.http://www.jensroesner.de/wgetgui/

Revision history for this message
Mike Mackintosh (mike-mackintosh) wrote :

Seems to be same bug.

splug@SplugBox:~$ winecfg
preloader: Warning: failed to reserve range 00000000-60000000
wine: creating configuration directory '/home/splug/.wine'...
preloader: Warning: failed to reserve range 00000000-60000000
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
Could not load Mozilla. HTML rendering will be disabled.
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
wine: '/home/splug/.wine' created successfully.
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report

Revision history for this message
In , Austin English (austinenglish) wrote :

*** Bug 13668 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Angel Guzman Maeso (shakaran) wrote :

In rc1, rc2 and rc3 I have not seen this problem in ubuntu 8.04. I think that this solved.

Revision history for this message
In , Austin English (austinenglish) wrote :

(In reply to comment #37)
> In rc1, rc2 and rc3 I have not seen this problem in ubuntu 8.04. I think that
> this solved.
>

Fixes have been put in for most apps, but some dos/win16 apps still trigger it.

Revision history for this message
In , Kevin DeKorte (kdekorte) wrote :

The problem now affects wine on Fedora 8. And picasa 2.7.3736-15 triggers the warning message. The work around for mmap_min_addr does work. Just annoying to have wine working correctly and then to have it break.

Revision history for this message
In , Ansus (neptunia) wrote :

Civilization I for Windows hangs on startup.

The game shows splash screen and plays intro music, but does not react on mouse
clicks (normally mouse click should skip intro). After music is over, the game
simply stucks with its splash screen window still displayed.
In console it displays an error message:
wine: Unhandled page fault on read access to 0x0000000c at address 0x605ad6ae
(thread 0019), starting debugger...
Unhandled exception: page fault on read access to 0x0000000c in 32-bit code
(0x605ad6ae).

The game ran well under Wine 1.0-rc1 after the mmap_min_addr workaround (although with some minor bugs) on the same system, so this bug is either because of post-rc1 changes or because of Fedora 9 post-release updates (regression testing did not help, the bug was present in all test attempts). Under Ubuntu 8.04 with Wine 1.0-rc4 also works well.

Revision history for this message
In , Kristian Rasmussen (krasmussen) wrote :

I've applied the vm.mmap_min_addr fix, but after the update my dictionary (Gyldendals Danish-English) now crashes with this - I'm guessing its related to this bug (full log attached):

wine: Unhandled page fault on read access to 0xffffffff at address 0x12cf:0x0000143c (thread 0031), starting debugger...
Unhandled exception: page fault on read access to 0xffffffff in 16-bit code (12cf:143c).

Revision history for this message
In , Dan Kegel (dank) wrote :

Nah, that looks like a different problem, please create a new bug for it.

Revision history for this message
Scott Ritchie (scottritchie) wrote :

Is there a proper way to configure a system such that ONLY Wine has access to this memory? This would be an ideal default.

Revision history for this message
Dan Kegel (dank) wrote :

Not that I know of.

FWIW, other similar apps are also affected:
qemu: http://lists.scratchbox.org/pipermail/scratchbox-users/2008-April/001218.html
dosemu: http://ubuntuforums.org/showthread.php?t=781052

So whatever solution you go for, coordinate it with the owners of those other packages.

Revision history for this message
In , Alexandre Julliard (julliard) wrote :

*** Bug 14396 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Brian Walker (bfuzze) wrote :

Re: Comment #373 and #38:

I did encounter this error in Ubuntu 8.04 Hardy, running any command thusfar.

Comment #1 seems to resolve:
$ sudo sysctl -w vm.mmap_min_addr=0
To make this setting permanent, add this line to /etc/sysctl.conf:
vm.mmap_min_addr

Revision history for this message
Dr D J Clark (djc-online) wrote :

I have a old 16bit Win program NewSOED that I don't use often. Starting it with the following script prevents the workaround being too permanent but removes some of the inconvenience.

# mmap_min_addr=`sysctl -n vm.mmap_min_addr`
# echo $mmap_min_addr
# if [ $mmap_min_addr != '0' ]
# then
# echo "*** 16bit windows program, setting: ***"
# echo " sysctl -w vm.mmap_min_addr=0"
# sudo sysctl -w vm.mmap_min_addr=0
# fi
# wine "c:\PROGRAMS\NewSOED\NEWSOED.EXE"

Revision history for this message
In , Scott Ritchie (scottritchie) wrote :

Distro packagers should have a new way to workaround this problem if their system is using the newest procps.

You can place your own custom file to override /etc/sysctl.conf settings in /etc/sysctl.d/

So, here we put a small file containing:
vm.mmap_min_addr = 0

The problem, however, is that this exposes a bug in sysctl - namely, it loads the /etc/sysctl.d/ folder BEFORE /etc/sysctl.conf, making the new folder useless. Hopefully this will be fixed soon: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/256025

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package wine - 1.0.0-1ubuntu8

---------------
wine (1.0.0-1ubuntu8) intrepid; urgency=low

  * create debian/wine.sysctl.conf
    - now Wine can access the lower 64k of memory (LP: #114025)
  * debian/rules: add rules for installing wine.sysctl.conf
  * debian/wine.dirs.*: add /etc/sysctl.d folder
  * debian/wine.install.*: add /etc/sysctl.d install folder
  * remove non arch-specific .install and .dirs files.
  * debian/wine.postinst: add invoke-rc.d procps start
    - so no reboot is required for Wine's sysctl.conf setting

 -- Scott Ritchie <email address hidden> Thu, 07 Aug 2008 04:28:31 -0700

Changed in wine:
status: Confirmed → Fix Released
Revision history for this message
Scott Ritchie (scottritchie) wrote :

Unfortunately, the above package doesn't quite fix this in Intrepid, due to this bug in procps: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/256025

Revision history for this message
In , Austin English (austinenglish) wrote :

What's the current status of this bug? Haven't heard much about it lately...

Revision history for this message
In , JeremiahFlerchinger (flerchjj) wrote :

I don't experience this error with every run of Wine (nor have I ever). Still I encountered the "Preloader Page Zero Problem" on some apps. The issue may relate to DOS, Win3.1, or Win98 apps that try to access VGA directly.

I am using Ubuntu 8.04 and running "sudo sysctl -w vm.mmap_min_addr=0" still corrects the issue after any restart.

Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

(In reply to comment #47)
> I don't experience this error with every run of Wine (nor have I ever). Still
> I encountered the "Preloader Page Zero Problem" on some apps. The issue may
> relate to DOS, Win3.1, or Win98 apps that try to access VGA directly.

And Wine can do nothing about this.

> I am using Ubuntu 8.04 and running "sudo sysctl -w vm.mmap_min_addr=0" still
> corrects the issue after any restart.

That's the only way to fix it, in order to avoid doing this after a restart
follow the suggestion in the comments above.

Revision history for this message
In , JeremiahFlerchinger (flerchjj) wrote :

> And Wine can do nothing about this.
I didn't say Wine could or should. I was just replying to Austin that the condition still exists.

It is not a big concern of mine, just a minor annoyance and possibly a concern for individuals unaware of the issue or how to work around it.

Revision history for this message
In , Austin English (austinenglish) wrote :

This doesn't show up too much anymore, and for the few times it's needed, it's not a Wine bug. Marking invalid.

Revision history for this message
In , Austin English (austinenglish) wrote :

Closing.

Revision history for this message
In , Scott Ritchie (scottritchie) wrote :

Wouldn't Wine, in an ideal world, be able to run these applications even with the memory restrictions? I could be wrong, but I thought Dosbox manages to do it somehow.

Revision history for this message
In , Vincent Povirk (madewokherd) wrote :

(In reply to comment #52)
> Wouldn't Wine, in an ideal world, be able to run these applications even with
> the memory restrictions? I could be wrong, but I thought Dosbox manages to do
> it somehow.

DOSBox does CPU emulation so its own memory layout isn't essential.

Bug Watch Updater (bug-watch-updater)
Changed in wine:
status: Confirmed → Invalid
Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

*** Bug 20880 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Esd45 (esd45) wrote :

This technically is a bug in wine, now that wine includes kernel API emulation.

This is actually part of a much larger limitation of not being able to access underlying hardware functions.

Obviously going full emulation would not be an option.

However, the better options would be to utilize a modified variant of Xen to handle the remapping of memory, IO and processor functions to the state and location of a standard win32 system.

Both the APIC and the Virtualization extensions can do this very efficiently, and it's not like we would be remapping standard program memory, or even emulating all the hardware.

No matter what the solution is remapping-based emulation of these functions is the ideal solution.

This would provide a lot of added features for hardware-reliant programs including the ability to secure device access for programs

Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

(In reply to comment #55)
> This technically is a bug in wine, now that wine includes kernel API emulation.

Wine does not include the kernel API emulation, why do you think it does?

Revision history for this message
In , Esd45 (esd45) wrote :

I should clarify that, I should say that now there is implementation of some essential kernel API functions.

Emulating the full kernel API would be a ridiculous waist of time, especially since a huge portion of it is completely hidden from programs. Clearly kernel emulation is far from the way to describe it.

However, come to think of it a full fix for the cause of this bug, as I described, enable doing a bug for bug memory map replication, something that would be classified as an enhancement.

It would allow for more efficient handling of Direct X, and better isolation of platform specific code relating to Host OS kernel memory mapping.

Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

This bug is about running DOS applications which is impossible without
an ability to access page 0. I have no idea why you think this somehow
may improve DirectX or anything else.

Revision history for this message
In , Esd45 (esd45) wrote :

What I meant to say was not this limitation was interfering with Direct X performance, but the larger limitation it is symptomatic of.

Basically Wine's entire memory mapping and memory access capabilities on all modes is entirely limited by the Host OS.

While this is fine for now, it will not be good in the long term, as this limitation puts Wine at the mercy of the host OS when choosing how programs see memory, and what shared memory methods are used.

While this is all fine if the host OS is providing optimal methods for doing things. Wine should create a universal means to direct the OS on how to handle memory remapping for Wine, and a variety of transparent fall-backs for when the Host OS is incapable of doing what is necessary to properly match bug for bug Win32 specifications. Without this, bug for bug matching of the memory mapping of all access modes used by drivers and programs will be literally impossible.

Basically, I'm saying it's better to stomp one big bug, than stomp out all it's children. We have the first small bug here that is symptomatic of a much larger limitation. Making plans to defeat that limitation in the long run, could save us hassles down the road, and greatly improve performance.

As of how this relates to Direct X. The current Direct X drivers are greatly limited by Wine's shared memory access. By improving the memory mapping methods used in all segments of Wine, we can pave the way for improvements in that department. It's basically that some of the limitations on how Direct X is implemented are limited by memory mapping capabilities as well. Just like this bug is caused by those same limitations, even if the limitation is impacting a completely different subsection.

Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

It appears to me that you have no idea what you are talking about, just like
you don't know where the message in the summary of this bug is printed and why.
Please stop confusing yourself and others.

Revision history for this message
In , Dan Kegel (dank) wrote :

Agreed... Robert, you seem to be throwing out the baby with the bathwater,
or prematurely optimizing, or something. Please pick some more measurable
problem to work on.

Revision history for this message
In , Esd45 (esd45) wrote :

You are probably right, since we don't know the nature of other limitations we will encounter in memory access.

The first bug one may not represent the nature of future ones, so making a universal preemptive fix for this and all future related issues may not be worth the effort if it doesn't necessarily prevent future bugs, or even lay groundwork for fixing them. Until we see a pattern in Host OS limitation bugs, we won't know what would be effective other than workarounds

Bug Watch Updater (bug-watch-updater)
Changed in wine:
importance: Unknown → Medium
Displaying first 40 and last 40 comments. View all 125 comments or add a comment.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.