TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
This will prevent the profiler from suspending a target thread while that thread holds the RtlLookupFunctionEntry lock, which the profiler itself also wants to use.
Change mozilla::Smprintf and friends to return a UniquePtr, rather than
relying on manual memory management. (Though after this patch there are
still a handful of spots needing SmprintfFree.)
MozReview-Commit-ID: COa4nzIX5qa
--HG--
extra : rebase_source : ab4a11b4d2e758099bd0794d5c25d799a7e42680
Bug 1350097 points out a case where the assertion in cvt_f, added in
https://bugzilla.mozilla.org/show_bug.cgi?id=1060419#c127, triggers.
Before this addition, code calling this printf variant would end up just
printing something invalid, as the truncated value would be emitted.
This patch increases the buffer size to be sufficient for DBL_MAX.
MozReview-Commit-ID: AVphURGa6jL
--HG--
extra : rebase_source : c7a2dad8e496434a631441ccc25dfee2db1ea71a
For pthreads platforms, we have a terribly large condition for the size
of a MutexImpl that attempts to hardcode the number of words that
pthread_mutex_t takes. This hardcoding isn't always correct. We
originally did this to try and keep <pthread.h> includes out of the
headers, but the PlatformConditionVariable.h header already includes
<pthread.h> anyway, and <pthread.h> isn't so namespace-invasive as
<windows.h>. So go ahead and include <pthread.h> and use the actual
definition of pthread_mutex_t to size the platformData_ member.
Android uses android.os.SystemClock.uptimeMilles for event time and SystemClock.uptimeMilles uses SYSTEM_TIME_MONOTONIC.
So since TimeStamp posix impelemetation uses SYSTEM_TIME_MONOTONIC too, so we can use event time on FromSystemTime.
MozReview-Commit-ID: 5Qb5kmnHHCI
--HG--
extra : rebase_source : 26d1554fa60e3216edfd4b149380910fe2a9d845
With frame pointer omission disabled we should always have usable stacks on Windows. This allows us to remove the MOZ_STACKWALKING define as it will always be enabled.
MozReview-Commit-ID: 54xs3Hf1r4P
--HG--
extra : rebase_source : dfaf13fb4c2185985f4f074c338ccf1fef8f3c94
CLOSED TREE
Backed out changeset 01cfc71ce542 (bug 1322735)
Backed out changeset 84c729c41230 (bug 1322735)
Backed out changeset b419aaefae95 (bug 1322735)
With frame pointer omission disabled we should always have usable stacks on Windows. This allows us to remove the MOZ_STACKWALKING define as it will always be enabled.
MozReview-Commit-ID: 54xs3Hf1r4P
--HG--
extra : rebase_source : 5fe27cdeeb464d81fbedc8c02ac187658bd759e7
Newer versions of clang warn about this construct, as the behavior is
not consistent between compilers. These warnings break
warnings-as-error builds, and seem like reasonable warnings to fix, so
let's do that.
X86_OR_PPC was only used in one place, so inlining it and getting rid of
the definition seemed reasonable.
Without this change, Visual Studio 2015 complains:
mozglue/misc/StackWalk.cpp(261): warning C4477: 'fprintf' : format
string '%s' requires an argument of type 'char *', but variadic argument
2 has type 'LPVOID'
MozReview-Commit-ID: HIAs5L57Nd1
--HG--
extra : rebase_source : 1ac50c03c4d6b14e22f3d55aca026fce15565f5c
This patch introduces a small utility program to extract a guid from a shared library
or executable on windows to identify the correct symbol file to read in fix_stack_using_bpsyms.py.
In order for this to work correctly on windows, the library name provided by
MozDescribeCodeAddress needs to be a full path, so the LoadedImageName field
from the IMAGEHLP_MODULE64 structure is used here instead of the ModuleName
field.
MozReview-Commit-ID: 8zkfLWjKVs2
