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