Problems with VirtualAlloc/Lock

[MIchael Ost]

There are major differences in the handling of virtual memory in Wine vs
WinXP that are causing problems for my winelib application. Can someone
provide background and/or workarounds for these issues?

As near as I can tell the main differences are:
* VirtualLock does nothing in Wine
* Wine makes no distinction between MEM_RESERVE and MEM_COMMIT
* Wine has no implementation of Windows' process working sets
* Wine limits MEM_RESERVE to 1GB, but WinXP goes up to 2GB

The above problems seem relatively harmless on systems with < 1GB RAM.
But when our units go greater than 1GB we are seeing spectacular
crash-and-burn failures. The code-only DLLs we are running on such
systems are crashing at a stage when I suspect they are attempting to
lock RAM. 

I suspect that they are confused by the report from GlobalMemoryStatus
that more than 1GB of RAM is installed, but that they are only able to
VirtualLock up to 1GB. And in this unexpected situation, they are
crashing.

Further, these DLLs are audio processing plugins. The apparent fact that
VirtualLock doesn't _actually_ lock memory into RAM for real time
processing is a disaster for our system, in that it causes audio
glitches when a page fault is handled. But that is not a problem which
crashes the system.

Any suggestions on what to do? Is there any pending work on this area
out there?

I've attached a little table that describes what I found. It shows the
differences in how Wine and WinXP handle memory related calls. I have
also attached a simple program which can be run to see these
differences.

Thanks for any help... mo

[Raphael]

Hi,

interesting

seems we have a bug report about that problem (behavior differences)
 http://bugs.winehq.org/show_bug.cgi?id=890

Regards,
Raphael

[MIchael Ost]

On Mon, 2005-03-14 at 13:16, Raphael wrote:
> seems we have a bug report about that problem (behavior differences)
>  http://bugs.winehq.org/show_bug.cgi?id=890

I guess I am adding VirtualLock and VirtualAlloc to the list of APIs
that don't work the same in Wine vs Windows. Bug #890 is about
VirtualQuery and seems to have been patched/fixed...? 

The diff is that  the issues I raise aren't bugs, but behaviors that
just haven't been implemented like actually locking virtual memory, and
using the win32 working sets.

That bug dates back to 2002! Oh, no. I guess this must be a low priority
issue for Wine. Bad news for me. ... mo

PS: thanks for the hint about the bug db, tho. I didn't think to check
there! Ooops... %)

[Kuba Ober]

> * VirtualLock does nothing in Wine
> VirtualLock does nothing in win95,98,ME as well :)

I bet the correct behaviour for wine is to do anything in VirtualLock only if 
you set windows version to NT/2000/XP. Did you do it?

Anyway, mlock() seems to work fine, so this should be implementable.
> * Wine makes no distinction between MEM_RESERVE and MEM_COMMIT
> Assuming that we're talking about VirtualAlloc().

It would use mmap():
MAP_PRIVATE must be set. Always.
MEM_RESERVE translates to MAP_NORESERVE (sic!)
MEM_COMMIT translates to nothing, but it should zero the page and methinks 
linux would do it by default (?)
MEM_TOP_DOWN translates maybe to MAP_GROWSDOWN (?)
MEM_WRITE_WATCH can be implemented by mmapping a PROT_READ region, handling 
SEGSIGVs and then mprotect()ing it back to PROT_READ | PROT_WRITE

It would also use madvise():
MEM_RESET translates to MADV_DONTNEED

I wonder to what extent Wine really does any of that. Too busy to take a look 
at the actual code.
> * Wine has no implementation of Windows' process working sets
> Linux doesn't either. At least I don't know of a documented API that could 
> reliably implement semantics of Windows working sets. Maybe it could be 
> implemented on other OSes like some BSDs if they have such APIs. Maybe 
> there's something in /proc/sys/vm or somesuch to tweak those, but then it 
> would probably be system-wide. I'm no expert here I'm afraid :(
> * Wine limits MEM_RESERVE to 1GB, but WinXP goes up to 2GB
> Wine? Maybe linux, but I doubt wine would do anything like that.
> Further, these DLLs are audio processing plugins. The apparent fact that
> VirtualLock doesn't _actually_ lock memory into RAM for real time
> I didn't look into the code, but anyway a prerequisite for it would be to set 
> windows version to NT/2000/XP. Or at least wine should behave like that, 
> assuming that MSDN doesn't lie here.

Apart from that, I bet you didn't raise ulimits for your processes. On my FC3 
system, ulimit -l gives a meager 32 pages. So that's how many mlock() could 
lock anyway.

So, in order for VirtualLock to be able to potentially screw up your 
rock-stable linux system, you have to let it first :)

Cheers, Kuba

[Uwe Bonnes]

> > > > > "Kuba" == Kuba Ober <kuba(a)mareimbrium.org> writes:

>> * VirtualLock does nothing in Wine
    Kuba> VirtualLock does nothing in win95,98,ME as well :)

    Kuba> I bet the correct behaviour for wine is to do anything in
    Kuba> VirtualLock only if you set windows version to NT/2000/XP. Did you
    Kuba> do it?

    Kuba> Anyway, mlock() seems to work fine, so this should be
    Kuba> implementable.

    >> * Wine makes no distinction between MEM_RESERVE and MEM_COMMIT
    Kuba> Assuming that we're talking about VirtualAlloc().

In this context, the different allocation strategy with 2.6 ("flexible
mmap") and the chance of handling out Heappointers above 0x80000000 should
be noted.

-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------