Diego Nieto Cid, le mer. 03 sept. 2025 00:45:41 +0100, a ecrit:
> On Mon, Sep 01, 2025 at 12:18:51AM +0200, Samuel Thibault wrote:
> >
> > I'm thinking that probably the __vm_set_size_limit call, since it is
> > directed to the host port, does not actually go through rpctrace
>
> Ok
>
> > Do you actually see the RPC call?
>
> No, there's no entry for the vm_set_size_limit in the rpctrace
> output when I use the setrlimit function.
So it's getting to the kernel directly, thus no surprise that it's
confused.
Does the proc_getprivports call show up?
> But, with the atttached program (which calls vm_set_size_limit directly)
> it is shown correctly in rpctrace:
>
> ...
> 38<--44(pid3837)->proc_getprivports_request () = 0 60<--55(pid3837)
> 31<--62(pid3837)
> task9(pid3837)->mach_port_mod_refs (pn{ 20} 0 1) = 0
> 49<--25(pid3837)->io_write_request ("task=0x1; host=0x14\n" -1)task=0x1;
> host=0x14
> = 0 20
> 60<--55(pid3837)->vm_set_size_limit ( task9(pid3837) 2147483648
> 2147483648) = 0
Then that's surprising as well :)
If the setrlimit call doesn't show proc_getprivports in rpctrace, it'd
mean that the process is getting the host port another way, thus no
surprise that rpctrace can't wrap it to make the call work.
> task9(pid3837)->mach_port_deallocate (pn{ 20}) = 0
> 38<--44(pid3837)->proc_mark_exit_request (0 0) = 0
> task9(pid3837)->task_terminate () = 0
>
> That lead me to suspect of the GLIBC implementation (or the installation).
> Just in case, I will try again after addressing the review of the gnumach
> part.
