Quoting Svante Signell (2014-04-26 13:59:57)
> > For reference, here are my notes about one of these crashes (Svante,
> > is this still current?):
>
> Yes it is, thanks for your help so far. Is the rpctrace bug you
> mentioned that the wrong ports are reported?
>
> > ~~~ snip ~~~
> > [...]
> > task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0
> >
> > Here, we deallocate the port. Note how the port name (pn?) says 23,
> > even though it's clearly port 158 that is getting deallocated [...]
Reading the source revealed that 'pn{ 23}' makes it explicit that this
is a port name, not a right. And indeed:
routine mach_port_deallocate(
task : ipc_space_t;
name : mach_port_name_t);
For port rights, which we know are valid in the tracee, we translate
the name so that the name used by the tracee is displayed in the log.
A comment in the source correctly states:
/* Note that MACH_MSG_TYPE_PORT_NAME does not indicate a port right.
It indicates a port name, i.e. just an integer--and we don't know
what task that port name is meaningful in. If it's meaningful in a
traced task, then it refers to our intercepting port rather than
the original port anyway. */
We could try to be clever here, at least for the reference counting
RPC.
Justus
