Re: Question about mmap issues on FreeBSD/NetBSD

[Yorick Hardy]

Thanks for the response.

I must be doing something wrong, since wine-kthread gave the same error.
Anything I may have missed? I copied wine-kthread from loader/wine-kthread.

It does not appear to be correct, but is there any chance
madvise(..., MADV_DONTNEED) could help?

Also in libs/wine/mmap.c line 119 the result of mincore is never tested,
should it not be

if ( (mincore( (caddr_t)addr + i, pagesize, &vec ) != -1) && (vec&1) )

(with a slight variation for FreeBSD), although I think this will not
resolve the current problem.
> You need MAP_NORESERVE support otherwise we can't control the address
> space correctly (unless you have a ton of virtual memory): if you run
> wine-kthread directly it should still work though unless you have
> execshield type address space randomisation active.
>
> On Thu, 29 Jul 2004 09:13:25 +0200, Yorick Hardy wrote:
> > Just a question about the mmap issues experienced on FreeBSD, i.e.
> >  http://www.winehq.org/?issue=230#Wine%20on%20FreeBSD
> >
> > I encountered the same on NetBSD. It seems the error message is set from
> > ld.elf_so in NetBSD and ld-elf.so.1 in FreeBSD, when the address space
> > is mapped for the run time linking? Since MAP_NORESERVE is not documented
> > (and not supported?) for mmap on FreeBSD and NetBSD, it would appear
> > that wine and the ld.elf_so together require too much memory for all the mmap
> > calls.

Kind regards,

Question about mmap issues on FreeBSD/NetBSD

[Mike Hearn]

On Fri, 2004-07-30 at 09:36 +0200, Yorick Hardy wrote:
> Thanks for the response.
>
> I must be doing something wrong, since wine-kthread gave the same error.
> Anything I may have missed? I copied wine-kthread from loader/wine-kthread.

In that case I guess it's the code which reserves the top 2gig which is
bailing out rather than the preloader, sorry ...
> It does not appear to be correct, but is there any chance
> madvise(..., MADV_DONTNEED) could help?

Possibly, I don't know ... it sounds like it'd do something similar to
MAP_NORESERVE though. Try it?

FWIW I think in FreeBSD ports that code is simply commented out.
> Also in libs/wine/mmap.c line 119 the result of mincore is never tested,
> should it not be
>
> if ( (mincore( (caddr_t)addr + i, pagesize, &vec ) != -1) && (vec&1) )
>
> (with a slight variation for FreeBSD), although I think this will not
> resolve the current problem.

thanks -mike

Question about mmap issues on FreeBSD/NetBSD

[Yorick Hardy]

On Fri, Jul 30, 2004 at 02:30:14PM +0100, Mike Hearn wrote:
> > I must be doing something wrong, since wine-kthread gave the same error.
> > Anything I may have missed? I copied wine-kthread from loader/wine-kthread.
>
> In that case I guess it's the code which reserves the top 2gig which is
> bailing out rather than the preloader, sorry ...

Thanks for the suggestion anyway.
> > It does not appear to be correct, but is there any chance
> > madvise(..., MADV_DONTNEED) could help?
>
> Possibly, I don't know ... it sounds like it'd do something similar to
> MAP_NORESERVE though. Try it?

Does not work. I can't think of anything else at the moment, thanks for
your comments.

Kind regards,

Question about mmap issues on FreeBSD/NetBSD

[Alexandre Julliard]

Yorick Hardy  writes:
> Also in libs/wine/mmap.c line 119 the result of mincore is never tested,
> should it not be
>
> if ( (mincore( (caddr_t)addr + i, pagesize, &vec ) != -1) && (vec&1) )

No, the goal is to check if something is mapped there, we don't
actually care whether it's in core or swapped out.

Question about mmap issues on FreeBSD/NetBSD

[Joe Gainey]

I've got some cross platform issues i cannot resolve. There are some 
obvious issues like the assumption that round() is in the math library 
and not linking in the math library itself. i've worked passed those. 
Currently, I'm working with a patched version of the latest cvs source 
on Solaris 9x86. After applying Robert Lunnon's patch kit to the latest 
cvs course and substituting rint for the round function in 
wine/dlls/dsound/mixer.c and add the math library to EXTRALIBS, I got a 
clean compile. however running the wine binary results in the following:

try_mmap_fixed: vfork: Resource temporarily unavailable

I'm not intimately familiar with how wine manages it's memory so I 
hesitate to guess what is going on. I've attached the output of the 
truss if anyone has any ideas on what it going on or how to fix it 
please let me know.

Joe Gainey

Questions about vfork/memory issues on Solaris x86

[Joe Gainey]

Joe Gainey wrote:
> I've got some cross platform issues i cannot resolve. There are some 
> obvious issues like the assumption that round() is in the math library 
> and not linking in the math library itself. i've worked passed those. 
> Currently, I'm working with a patched version of the latest cvs source 
> on Solaris 9x86. After applying Robert Lunnon's patch kit to the 
> latest cvs course and substituting rint for the round function in 
> wine/dlls/dsound/mixer.c and add the math library to EXTRALIBS, I got 
> a clean compile. however running the wine binary results in the 
> following:
>
> try_mmap_fixed: vfork: Resource temporarily unavailable
>
> I'm not intimately familiar with how wine manages it's memory so I 
> hesitate to guess what is going on. I've attached the output of the 
> truss if anyone has any ideas on what it going on or how to fix it 
> please let me know.
>
> Joe Gainey