Comment # 27 on bug 1206359 from Jiri Slaby

Created attachment 863541 [details]
full log incl. smaps

From another run (I dumped even more), IIUC:

> mapmem(130):      map=0x7ff717f7f000     (old=(nil)              osz=0        nsz=1056768  prot=3 fd=4 off=868352  )

off in hex=0x0d4000
nsz in hex=0x102000

So mmap mapped this part of the file (Index.db):
0x0d4000-0x1d6000

> mapmem(130):    remap=0xffffffffffffffff (old=0x7ff717f7f000     osz=1056768  nsz=1060864  prot=3 fd=4 off=868352  )

Now it wants:
0x0d4000-0x1d7000

but fails:

> error: remapslot (240): mapped=0x7ff717f7f000 shift=0 mapmem(old=0x7ff717f7f000, osz=1056768, nsz=1060864, prot=3, fd=4, off=868352) failed 12

The original mapping (mmap above):

> 7ff717f56000-7ff718081000 rw-s 000ab000 fd:00 656385                     /usr/lib/sysimage/rpm/Index.db

This mapping provides:
0x0ab000-0x1d6000

BTW, this was requested earlier by another mmap:
> mapmem(130):      map=0x7ff717f56000     (old=(nil)              osz=0        nsz=167936   prot=3 fd=4 off=700416  )

and was not released until now.

The above mapping cannot be enlarged, because this vma follows:
> 7ff718082000-7ff718087000 rw-s 00047000 fd:00 656385                     /usr/lib/sysimage/rpm/Index.db

So the question is why remap did not apply the MAYMOVE rule. Provided it's
shared, it should create a new mapping (and preserve the old for the older
mmap) and return it. Or not? (I don't know the rules here.)