>> If I'm understanding Andrew right, the difference is that stack mappings
>> have different growth semanitcs from non-stack mappings. The former (well
>> the lowest one) can grow when the stack hits its bottom. The latter can
>> only grow as a result of explicit system calls to map more memory. Thus if
>> you access just below a mapping, you either want to grow it or return an
>> error, depending on if it's a stack or not.
>
>it doesn't quite work that way.  there are potentially multiple map entries
>involved in both stack and non-stack mappings, and the entries which actually
>have amaps allocated for them can grow in either case.  the amap code tries
>to coalesce amaps where possible to keep the number of map entries low.
>previously the coalescing would only work in some cases, a while back
>andrew made it work in a lot more cases.  there are still some bugs in that,
>though, so I'm thinking that the stack problem might really be a bug in the
>amap merging code.

here's the problem.  this sequence of vmcmds:

    vmcmd[0] = 0x8048000/0x1a000 fd@0 prot=05 flags=4
    vmcmd[1] = 0x8062000/0x7f4 fd@0x19000 prot=03 flags=4
    vmcmd[2] = 0x8063000/0x1000 fd@0 prot=03 flags=0
    vmcmd[3] = 0xbdbf5000/0xa000 fd@0 prot=05 flags=2
    vmcmd[4] = 0xa000/0x488 fd@0xa000 prot=03 flags=1
    vmcmd[5] = 0xbdc00000/0x2000000 fd@0 prot=03 flags=0

currently leads to this vm_map:

    MAP 0xcf490180: [0x0->0xbfc00000]
	    #ent=5, sz=33718272, ref=1, version=9, flags=0x41
	    pmap=0xcf491098(resident=7)
     - 0xcf4cad00: 0x8048000->0x8062000: obj=0xcf4d5004/0x0, amap=0x0/0
	    submap=F, cow=T, nc=T, prot(max)=5/7, inh=1, wc=0, adv=0
     - 0xcf4cadc0: 0x8062000->0x8064000: obj=0x0/0x0, amap=0xcf4cb2f8/0
	    submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0
     - 0xcf4cabc0: 0xbdbf5000->0xbdbff000: obj=0xcf4b05c4/0x0, amap=0x0/0
	    submap=F, cow=T, nc=T, prot(max)=5/7, inh=1, wc=0, adv=0
     - 0xcf4caa40: 0xbdbfe000->0xbdbff000: obj=0xcf4cc000/0x0, amap=0x0/0
	    submap=F, cow=F, nc=F, prot(max)=5/5, inh=0, wc=0, adv=1
     - 0xcf4cac80: 0xbdbff000->0xbfc00000: obj=0x0/0x0, amap=0xcf4cb5a0/0
	    submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0

the problem is the entry at 0xcf4caa40.  it seems to have been both
merged with the stack (pulling the stack "top" back one page), and
also allocated (meaning it's still in the map) in the wrong place.  if
it was one page later (at 0xbdbff000->0xbdc00000 instead), it would be
in the right place, though it should still not be there.

note that the entry at 0xcf4cac80 was initially part of the large
0xbdbff000-0xbfc00000 entry, yet got faulted and chunked off when the
stack information to complete the exec got copied out.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."