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
