bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate


From: Justus Winter
Subject: Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Date: Sat, 26 Apr 2014 15:53:53 +0200
User-agent: alot/0.3.4

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]