Justus Winter, le Sat 26 Apr 2014 08:53:08 +0200, a écrit :
> task130(pid1182)->vm_map (0 49880 0 1 133<--160(pid1182) 0 1 5 7 1) = 0
> 2453504
>
> We map that somewhere.
>
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0
>
> Deallocate the port. Again, for some strange reason 133 == pn{ 25}.
>
> 158<--157(pid1182)->io_map_request () = 0 133<--162(pid1182) (null)
>
> Some more io_map.
>
> task130(pid1182)->vm_map (2498560 8192 0 0 133<--162(pid1182) 40960 1 3 7
> 1) = 0x3 ((os/kern) no space available)
> task130(pid1182)->vm_deallocate (2498560 8192) = 0
>
> Hum?
>
> task130(pid1182)->vm_map (2498560 8192 0 0 133<--162(pid1182) 40960 1 3 7
> 1) = 0 2498560
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0
>
> Success!
See the logic in elf/dl-load.c's _dl_map_object_from_fd and
sysdeps/mach/hurd/mmap.c. _dl_map_object_from_fd first gets somewhere
to map the SO (first __mmap call), and then, if bss is big, it maps
anonymous pages for it with MAP_FIXED, replacing the bss part of the SO:
2453504 + 49880 = 0x2632d8
2498560 + 8192 = 0x264000
So this seems like just normal behavior.
Samuel
