Not doing this causes gtest to issue these warnings:
[WARNING] ../../third_party/gtest/gtest/src/gtest-death-test.cc:825::
Death tests use fork(), which is unsafe particularly in a threaded
context. For this test, Google Test detected 4 threads.
The gtest documentation recommends giving the test case a name ending in
DeathTest. Test cases named according to this convention run before all
other tests. Other death tests in Crashpad also follow this convention.
https://code.google.com/p/googletest/wiki/AdvancedGuide#Death_Tests_And_Threads
TEST=util_test HTTPMultipartBuilderDeathTest.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/694963002
This change was generated mechanically by running:
find . \( -name \*.cc -or -name \*.mm -or -name \*.h \) \
-and -not -path ./third_party/\* -and -not -path ./out/\* \
-exec sed -i '' -E -e 's/(^|[^_])NULL/\1nullptr/g' {} +
Further manual fix-ups were applied to remove casts of nullptr to other
pointer types where possible, to preserve the intentional use of NULL
(as a short form of MACH_PORT_NULL) in exception_port_tool, and to fix
80-column violations.
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/4mijeJHzxLg/discussion
TEST=*_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/656703002
This uses THREAD_NULL, TASK_NULL, and HOST_NULL in preference to
MACH_PORT_NULL and kMachPortNull. These constants are correctly-typed
(thread_t, task_t, and host_t) and result in more readable source code,
especially where thread and task parameters appear together as they do
in exc_*_variants.
TEST=util_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/649713002
amount of time spent sleeping.
Even with the slop, this wound up being flaky, specifically on virtual
machines. And guess what our automated test infrastructure runs on?
TEST=util_test Clock.SleepNanoseconds
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/640373003
ExpectProcessIsRunning() goes to a lot of trouble to deal with the flaky
{CTL_KERN, KERN_PROCARGS2} API exposed by ProcessArgumentsForPID(). It
retries that call inside an inner loop until it succeeds, because it may
fail while a process is mid-exec(). Once it succeeds, it should use the
argv it obtained. Waiting for success and then attempting to call
ProcessArgumentsForPID() again to get argv can be flaky when the first
attempt succeeds because it’s pre-exec(), and the second one catches the
process in the middle of the exec() and fails.
The existence of the inner loop was intended to protect against this
problem, and the subsequent call outside of the inner loop appears to be
left behind from before the inner loop existed. It should have been
removed when the inner loop was added.
TEST=util_test ServiceManagement.SubmitRemoveJob
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/644473005
7dda7b322881 accidentally moved the libbsm.dylib dependency from
util_test_lib to util_test. It is only used by
test/mac/mach_multiprocess.cc in util_test_lib.
Meanwhile, util_test should link against Foundation.framework, which is
used by three tests in util/mac: launchd_test.mm, mac_util_test.mm, and
service_management_test.mm.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/612923004
This includes ClockMonotonicNanoseconds() and SleepNanoseconds().
SleepNanoseconds() is like base::PlatformThread::Sleep(), but
PlatformThread is not in mini_chromium and I’m not keen on adding it
because I’m not sold on the interface. I’m not convinced Sleep() belongs
there, and I don’t want to have to bring all of base::Time* along for
the ride.
TEST=util_test Clock.*:MachMessageServer.*:ServiceManagement.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/597533002
This will be used in the upcoming Minidump context structures.
This also updates mini_chromium to ba9b15f1b6a7 to pick up:
ba9b15f1b6a7 Make bit_cast available in C++11 mode.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/583283003
The queue length of a new receive port appears to be 2 on Mac OS X 10.10
DP8 14A361c. The value of MACH_PORT_QLIMIT_DEFAULT in the 10.10 SDK is
still 5, so a read of the kernel source should be interesting, if we
ever get to see it.
In the meantime, mach_port_set_attributes() can be used to set a
traditional queue length.
TEST=util_test MachMessageServer.PersistentNonblockingFourMessages
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/584293003
This reverts commit 63fd3ae47d2513ef4390c3d8c0dde3fa95152480.
SMJobRemove() still performs a 1-second sleep() when its |wait|
parameter is true. Radar 18398683 is filed. In the mean time, the
launchd-based implementation of these functions does not have this
undesirable property.
The comments have been revised to not reflect operating systems before
Mac OS X 10.6. Comments describing bugs in earlier 10.10 seeds that have
since been fixed have been removed.
TEST=util_test Launchd.*:ServiceManagement.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/579083003
On 10.6, the main executable does not show up at index 0, but appears
elsewhere in the list. Modules are now scanned to ensure that the
MH_EXECUTE one is first in the list. This means that ProcessReader is
now responsible for creating a MachOImageReader object for each module,
rather than having its callers perform that task.
TEST=util_test MachOImageReader.*:ProcessReader.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/586123002
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
Review URL: https://codereview.chromium.org/584223002
exception handler ports.
task_t, thread_t, and exception_handler_t are typedefs for mach_port_t.
They are more descriptive than mach_port_t, and are already in use in
exc_server_variants.
TEST=util_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/577293002
mach_exception_data_type_t is more generic and is used for any element
of a codes[] array. For individual elements, the typedefs
mach_exception_code_t and mach_exception_subcode_t are available. Using
mach_exception_code_t when possible gives slightly more descriptive
code.
No functional change.
TEST=util_test ExcServerVariants.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/585473003
This includes the functions ExceptionBehaviorHasState(),
ExceptionBehaviorHasIdentity(),
ExceptionBehaviorHasMachExceptionCodes(), and ExceptionBehaviorBasic().
TEST=util_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/565793005
This also puts kMachExceptionCodes into mach_extensions.h, because a
form of MACH_EXCEPTION_CODES that’s the right type
(exception_behavior_t) has now shown its use in more than one file.
TEST=util_test ExcClientVariants.UniversalExceptionRaise
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/567283002
until the server is done handling its request.
In most tests, this is handled automatically because the client expects
a reply from the server, and waits for this reply. This test is
different because the server does handle the message, but does not send
a reply, so the client does not wait for one. When the child process
exits before the parent has had a chance to inspect the message it
received, the parent will find a dead name where it expects the remote
port to be, causing this test to be flaky based on the outcome of this
race.
The potential for a similar race existed in the
MachMessageServer.ComplexNotDestroyedNoReply test because it also
involved a request without a reply. In that test, the situation was
handled by not allowing the child to exit until signaled to do so by the
parent. The same logic should be used for both no-reply tests.
TEST=util_test MachMessageServer.ReturnCodeNoReply
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/569953002
Kernel bugs prevent debug thread state flavors from being delivered to
exception handlers properly. Through luck, things work out for
x86_DEBUG_STATE and x86_DEBUG_STATE64, but a handler registered to
receive the x86_DEBUG_STATE32 thread state flavor will never be called.
For the x86 family, the only thread state flavors that can be delivered
to exception handlers are the thread, float, and exception flavors.
Radar 18312067 is filed.
TEST=util_test ExcServerVariants.ThreadStates
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/558503006
