In locations that observe daylight saving time, this method now probes
different times to determine the offset when DST observance is (or is
not) in effect. This replaces a hard-coded one-hour offset, accounting
for Lord Howe Island, Australia, which is at a 30-minute offset.
TEST=snapshot_test SystemSnapshotMacTest.TimeZone
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/626093005
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 fixes a sloppy compliation error: “Redefinition of enumerator
'kMinidumpContextX86Xstate'”. It also fixes CONTEXT_FULL, which should
contain floating-point registers but not segment registers unlike the
its 32-bit x86 equivalent.
Some comments are revised to provide better, um, context.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/620663002
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
Update mini_chromium to 313bd83d6d9d, picking up:
313bd83d6d9d Use close$NOCANCEL on Mac, as in Chrome r23369.
15a69caf735f Add some things from base/synchronization:
ConditionVariable and Lock.
Also, udpate GYP to 46282cedf40f (r1977), picking up:
r1977 android: Add a way to override build system variables.
r1976 android: Don't emit useless info into generated makefiles.
r1975 Fix indentation for emacs and add missing keyword.
r1974 Changes ninja generator to only output empty names if not already
output
r1973 Changes the ninja generator to output phony targets for
uninteresting targets
r1972 Makes matching of build files work when absolute
r1971 Support for custom NM/readelf binaries in your toolchain.
r1970 android: Support host multilib builds.
r1969 Makes analyzer output names of all executable target types
r1968 android: Make buildbot able to use a custom manifest.
r1967 ninja win: don't expect pdb to be generated when
GenerateDebugInformation: false
r1966 Makes the analyzer output the set of targets needing a build
r1965 Removes old way to specify files to look for
r1964 Provide a way to suppress implicit MIDL generation rules for
actions
r1963 Style changes for analyzer __ -> _ and lots of single newlines to
double newlines.
r1962 Changes for analyzer
r1961 Pull in relevant targets when using xcode-ninja
r1960 Guard against configurations without 'xcode_settings'
r1959 Updates analyzer to output to a file
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/590033002
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
catch_exception_tool catches Mach exceptions. Currenlty, it simply
prints a message with some information about each exception it handles.
In the future, it will be tied to the minidump generator as well.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/579443005
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
library support.
When building with support for Mac OS X 10.6, C++11 library support is
not available, because Mac OS X uses libc++ for C++11 support, and Mac
OS X 10.6 does not provide libc++ as a runtime library. gtest and gmock
have a hard time distinguishing between C++11 language and library
support (which is not really their fault, having one but not the other
is an odd situation). The currently-released trunk versions of gtest and
gmock do not work in this configuration. I’ve submitted patches upstream
to fix this, but they may take a while to make it to the released
verions. For now, it’s fine to roll gtest and gmock back to versions
from December 2013 that do work cleanly with C++11 language support but
only C++03 library support.
TEST=Compile and run all tests in both 10.6 and native builds
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/572613002
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
