Re: Someone using COMPAT_SVR4(_32) ?

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Wed, 13 Sep 2017, Robert Swindells wrote:

> Eduardo Horvath <eeh%NetBSD.org@localhost> wrote:
> >On Wed, 13 Sep 2017, Jerome Ibanes wrote:
> >
> >> 6.0.6 sparc64, 6.1.5 sparc64, 7.1 sparc64 (all GENERIC), fail with the same
> >> behavior (meaning, same ktrace ouput) given the same payload (sparc
> >> solaris 2.6), ktrace shows:
> >> 
> >> [...]
> >>   1119      1 k        CALL  mmap(0x2000,0x80000002,0,0x45f,2,0)
> >>   1119      1 k        RET   mmap 1074167808/0x40068000
> >>   1119      1 k        PSIG  SIGSEGV SIG_DFL: code=SEGV_MAPERR,
> >> addr=0x0, trap=48)
> >
> >Hm.  What binary is this?  Solaris 2.6, so that's 32-bits, right?  
> >That's a really old version.  I should know, I got the tee shirt.  
> >
> >Is that on a 32-bit or 64-bit NetBSD kernel?
> >
> >Compat svr4_32 mmap should be this:
> >
> >115     STD             { netbsd32_voidp|svr4_32_sys||mmap(netbsd32_voidp addr, 
> >                            svr4_32_size_t len, int prot, int flags, int fd, 
> >                            svr4_32_off_t pos); }
> >
> >So according to ktrace, it's requesting some huuuuuuge mapping be added at 
> >address 0x2000 from FD 2.  
> 
> Does the emulated mmap() restrict segment sizes to be less than one of
> the resource limits, it looks to me as if it does.
> 
> Several Lisp systems have to chop up big allocations into smaller chunks
> when running on NetBSD.

Don't think that's what's happenning.  The mmap() succeeds, it just 
mapped at the wrong address.

Eduardo