Chromium Code Reviews Chromium Code Reviews
Issue
584223002:
ExceptionPorts test: accept a port of MACH_PORT_NULL as “no handler.” (Closed)
DescriptionExceptionPorts::GetExceptionPorts(): don’t return ExceptionHandler
elements whose handler port would be MACH_PORT_NULL.
For most exception targets, *_get_exception_ports() will normally return
an exception port of MACH_PORT_NULL when no handler is registered.
However, as of Mac OS X 10.9, thread_get_exception_ports() will return
an empty list when no handler is registered for any exception type on a
thread.
Consequently, a caller would have to do additional processing to
determine whether a specific exception port is registered: an
unregistered port will either appear but have a handler port of
MACH_PORT_NULL, or it will not appear at all. This is confusing for
callers. The behaviors are unified, and when a handler port of
MACH_PORT_NULL is found, it will not be returned to the caller. This is
expected to be the simpler of the two possible behaviors for callers to
make use of.
The change in the kernel can be seen by comparing 10.8.5
xnu-2050.48.11/osfmk/kern/ipc_tt.c thread_get_exception_ports() to the
same function in 10.9.4 xnu-2422.110.17. The 10.9 version has a special
check for thread->exc_actions being NULL, which short-circuits the rest
of the function without returning any exception ports. In 10.8.5,
thread->exc_actions can never be NULL. This new check is only present
for thread targets, presumably because it’s very common for threads to
not have any exception ports set, and not having to initialize this data
is an optimization. Typical user-level tasks in Mac OS X always have at
least some exception ports set at the task level.
TEST=util_test ExceptionPorts.TaskAndThreadExceptionPorts
R=rsesek@chromium.org
Committed: https://chromium.googlesource.com/crashpad/crashpad/+/51e696ade94dd2b71fae487afe8a02c109fdcf2b
Patch Set 1 #
Total comments: 1
Patch Set 2 : Address review feedback #
Messages
Total messages: 6 (1 generated)
|
||||||||||||||||||||||||||||
