It's a very general mechanism for replacing the implementation of
printf_stderr().
It's primarily used by the profiler, sparingly, and not in an important way.
Worse, it prevents us from using MOZ_LOG in the profiler, which is something I
want. Because if any code that locks gPSMutex also calls MOZ_LOG, that then
calls printf_stderr(), which calls profiler_log(), which locks gPSMutex, which
deadlocks.
The only other use of set_stderr_callback() is for the ultra-hacky,
for-local-use-only copy_stderr_to_file() function, which was added for B2G
debugging and is no longer necessary.
This patch removes set_stderr_callback() altogether.
--HG--
extra : rebase_source : d31ecb482fe5899f62dc56a38e87d91f9271bab0
This tracks TlsAlloc() and TlsFree() calls on Windows for diagnosing crashes when a proces reaches
its limit (1088) for TLS slots. Tracking of TLS allocation is done by intercepting TlsAlloc() and
TlsFree() in kernel32.dll. After initialization, we start tracking the number of allocated TLS
slots. If the number of observed TLS allocations exceeds a high water mark, we record the stack
when TlsAlloc() is called, and the recorded stacks gets serialized in a JSON string ready for
crash annotation.
MozReview-Commit-ID: 5fHVr0eiMy5
This patch changes the crashreporter client code as well as the crash service
code to compute a SHA256 hash of a crash' minidump file and add it to the
crash ping. The crash service code computes the hash on the fly before handing
over the crash to the crash manager; the crash manager will then add it to the
crash ping. The crashreporter client on the other hand sends the hash via the
ping it generates but it also adds it to the event file so that the crash
manager can pick it up and send it along with its own crash ping. On Fennec
the crashreporter activity takes care of computing the hash.
SHA256 hash computation uses nsICryptoHash in the crash service, the
java.security.MessageDigest class in Fennec, the bundled NSS library in the
crashreporter when running on Windows and Mac and the system-provided NSS
library under Linux. The latter is required because the crashreporter client
uses the system curl library which is linked to NSS and which would thus clash
with the bundled one if used together.
This patch introduces two new methods for the nsICrashService interface:
|getMinidumpForID()| and |getExtraFileForID()|, these reliably retrieve the
.dmp and .extra files associated with a crash and ensure the files exist
before returning. These new methods are used in the CrashService for
processing and will become the only way to reliably retrieve those files
from a crash ID.
MozReview-Commit-ID: 8BKvqj6URcO
--HG--
extra : source : a4d8291c56fcde00238ab3166bbe6af6dd602340
This change moves us away from NSPR primitives for our primary
synchronization primitives. We're still using PRMonitor for
ReentrantMonitor, however.
The benefits of this change:
* Slightly faster, as we don't have to deal with some of NSPR's overhead;
* Smaller datatypes. On POSIX platforms in particular, PRLock is
enormous. PRCondVar also has some unnecessary overhead.
* Less dynamic memory allocation. Out of necessity, Mutex and CondVar
allocated the NSPR data structures they needed, which lead to
unnecessary checks for failure.
While sizeof(Mutex) and sizeof(CondVar) may get bigger, since they're
embedding structures now, the total memory usage should be less.
* Less NSPR usage. This shouldn't need any explanation.
This patch adds a series of fallible methods for the rust ns[C]String
bindings, as well as the `set_length` method, which is the same as the
`SetLength` method in C++. `set_length` is marked as unsafe.
The decision was made to make the fallible methods seperate from the
infallible methods, and to use seperate Rust->C++ bindings for each of
them, rather than only binding the fallible bindings, and unwrapping
them in rust-land. This is to try to match the C++ API as closely as
possible, and to ensure that the behavior matches.
MozReview-Commit-ID: FkSomkFUFGD
This adds release bounds checking to ReplaceElementsAt, InsertElementAt, and
InsertElementsAt to make sure the insertion point is within the current array
bounds.
MozReview-Commit-ID: 1pFr8LuOROI
PseudoContext::sampleContext() is always called immediately after
profiler_get_pseudo_stack(). This patch introduces profiler_set_js_context()
and profiler_clear_js_context(), which replace the profiler_get_pseudo_stack()
+ sampleContext() pairs. This takes us a step closer to not having to export
PseudoStack outside the profiler.
--HG--
extra : rebase_source : 8558d1600eafd395cc696d31f3d21fb52a1a74b0
As of the previous patch, these are now unused and aren't really buying us much.
MozReview-Commit-ID: HGliIFAcBb7
--HG--
extra : rebase_source : f39105fcb15e1c7eccae5088b34352e849f1b2b6
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
This prevents the antipattern found in bug 1341513.
MozReview-Commit-ID: JhxgC7aQDUA
--HG--
extra : rebase_source : b1ff0d240df87b2cbb415183dc93acc8bde7960a
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
This requires some adjustment to Equals(). Previously, when you wrote:
fooString.Equals(barString + bazString)
you'd get a tuple for the operator+, which implicitly converts to nsTSubstring, which resolves into nsTSubstring::Equals(const nsTSubstring&).
Now that Equals has moved one level up:
nsTStringRepr::Equals(const nsTStringRepr&)
The compiler can't make the double-leap from nsTSubstringTuple -> nsTSubstring -> nsTStringRepr.
So I implemented this manually.
MozReview-Commit-ID: 5x8XhndOToJ
--HG--
extra : rebase_source : ab0ec1259af522ea47a237e01f69dd28e593eacd
In the next patch, tuples will work on nsTStringRepr rather than nsTSubstring, so the notions of TO_SUBSTRING and substring_type are not quite right.
MozReview-Commit-ID: LpUwmGQAWVO
--HG--
extra : rebase_source : 6142500a3d4218d74dda11736b94cf08d6f55335
All nsTStringRepr methods must be const, so the mutators remain on nsTSubstring.
I left a small number of const methods on nsTSubstring, e.g. Capacity(), the rationale being that you would only be interested in this method if you intend to mutate the string.
I considered splitting up the typedefs block and leaving behind the ones related to mutation (e.g. nsWritingIterator) but I think it makes for clearer documentation to have them all in one place.
MozReview-Commit-ID: 7dEaRgc8NLK
--HG--
extra : rebase_source : 01b387b7e5bf2f21d6af1afcccf6ec0d7e8a2ac7
I've named it after the similar ns(C)StringRepr in the rust bindings code.
This is just the minimal definition of the structure. Bulk move of methods coming in next patch.
MozReview-Commit-ID: 4aQrpIWRTm7
--HG--
extra : rebase_source : e89d6fbacbaf6e26028e13848ce2877c8f245ba6
Cleanup in preparation for upcoming patches:
- By using an accessor method, nsTPromiseFlatString no longer needs to be a friend.
- The explicit uint32_t constructors are unused.
- The abstract_string_type typedef is unused (and will be potentially confusing in the next patch, so removing).
- The three-param ctor for nsTSubstring no longer needs to be public "for convenience".
- friend class nsTObsoleteAStringThunk_CharT no longer exists.
MozReview-Commit-ID: 4ibJLNzn13k
--HG--
extra : rebase_source : d5a947f398a6dfc801f644f437bae9125424d4d0
As of the previous patch, these are now unused and aren't really buying us much.
MozReview-Commit-ID: HGliIFAcBb7
--HG--
extra : rebase_source : f39105fcb15e1c7eccae5088b34352e849f1b2b6
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
This prevents the antipattern found in bug 1341513.
MozReview-Commit-ID: JhxgC7aQDUA
--HG--
extra : rebase_source : b1ff0d240df87b2cbb415183dc93acc8bde7960a
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
This requires some adjustment to Equals(). Previously, when you wrote:
fooString.Equals(barString + bazString)
you'd get a tuple for the operator+, which implicitly converts to nsTSubstring, which resolves into nsTSubstring::Equals(const nsTSubstring&).
Now that Equals has moved one level up:
nsTStringRepr::Equals(const nsTStringRepr&)
The compiler can't make the double-leap from nsTSubstringTuple -> nsTSubstring -> nsTStringRepr.
So I implemented this manually.
MozReview-Commit-ID: 5x8XhndOToJ
--HG--
extra : rebase_source : ab0ec1259af522ea47a237e01f69dd28e593eacd
In the next patch, tuples will work on nsTStringRepr rather than nsTSubstring, so the notions of TO_SUBSTRING and substring_type are not quite right.
MozReview-Commit-ID: LpUwmGQAWVO
--HG--
extra : rebase_source : 6142500a3d4218d74dda11736b94cf08d6f55335
All nsTStringRepr methods must be const, so the mutators remain on nsTSubstring.
I left a small number of const methods on nsTSubstring, e.g. Capacity(), the rationale being that you would only be interested in this method if you intend to mutate the string.
I considered splitting up the typedefs block and leaving behind the ones related to mutation (e.g. nsWritingIterator) but I think it makes for clearer documentation to have them all in one place.
MozReview-Commit-ID: 7dEaRgc8NLK
--HG--
extra : rebase_source : 01b387b7e5bf2f21d6af1afcccf6ec0d7e8a2ac7
I've named it after the similar ns(C)StringRepr in the rust bindings code.
This is just the minimal definition of the structure. Bulk move of methods coming in next patch.
MozReview-Commit-ID: 4aQrpIWRTm7
--HG--
extra : rebase_source : e89d6fbacbaf6e26028e13848ce2877c8f245ba6
Cleanup in preparation for upcoming patches:
- By using an accessor method, nsTPromiseFlatString no longer needs to be a friend.
- The explicit uint32_t constructors are unused.
- The abstract_string_type typedef is unused (and will be potentially confusing in the next patch, so removing).
- The three-param ctor for nsTSubstring no longer needs to be public "for convenience".
- friend class nsTObsoleteAStringThunk_CharT no longer exists.
MozReview-Commit-ID: 4ibJLNzn13k
--HG--
extra : rebase_source : d5a947f398a6dfc801f644f437bae9125424d4d0
This tracks TlsAlloc() and TlsFree() calls on Windows for diagnosing crashes when a proces reaches
its limit (1088) for TLS slots. Tracking of TLS allocation is done by intercepting TlsAlloc() and
TlsFree() in kernel32.dll. After initialization, we start tracking the number of allocated TLS
slots. If the number of observed TLS allocations exceeds a high water mark, we record the stack
when TlsAlloc() is called, and the recorded stacks gets serialized in a JSON string ready for
crash annotation.
MozReview-Commit-ID: 5fHVr0eiMy5
The code to make a ValidatingDispatcher break cycles when we're done with it
assumes that XPCOM is still up and running. This isn't the case during
shutdown. When XPCOM shuts down, we should avoid do_GetMainThread.
MozReview-Commit-ID: 5Gpko9FbFxl
--HG--
extra : rebase_source : 8c00c83b06e890802ade0d6df2a93f64dc8ea376
This just-so-happened to work because nobody refers to the splitter directly by name.
The added gtest doesn't actually prove that this patch fixes anything, but I figured we could use a wide string for good measure.
MozReview-Commit-ID: 1ADy4X44HO1
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
AbstractThread::GetCurrent() can return null if a thread isn't a
default AbstractThread (MainThread, etc). This doesn't get caught in
MozPromise until we try to check for reliability of dispatching on the
thread. Adding asserts to make things clearer on crashes.
MozReview-Commit-ID: AQJwpdTUiHZ
The profiler can currently handle nested calls to profiler_{init,shutdown}() --
only the first call to profiler_init() and the last call to profiler_shutdown()
do anything. And sure enough, we have the following.
- Outer init/shutdown pairs in XRE_main()/XRE_InitChildProcess() (via
GeckoProfilerInitRAII).
- Inner init/shutdown pairs in NS_InitXPCOM2()/NS_InitMinimalXPCOM() (both shut
down in ShutdownXPCOM()).
This is a bit silly, so the patch removes the inner pairs, and adds a
now-needed pair in XRE_XPCShellMain. This will allow gInitCount -- which tracks
the nesting depth -- to be removed in a future patch.
--HG--
extra : rebase_source : 7e8dc6ce81ce10269d2db6a7bf32852c396dba0e
Hook this into the browser via the XREAppData. This patch does not include the changes to Chromium source code.
--HG--
extra : rebase_source : 4d5637bcdbeae605b0b99e9192598d48f371b698
Added ASSERTions to nsWindowsDllInterceptor in case of a failed detour hook, with an exception for the RET opcode that appears in ImmReleaseContext. Added documentation about TestDllInterceptor.
--HG--
extra : rebase_source : a3c6fe0949f5503979a062bdaa5f35526ddee73b
This includes a near-jump CALL instruction in x64, which expands to a far-jump CALL with a 64-bit address as inline data. This requires us to abandon the method where we memcpy the code block into the trampoline and, instead, build the trampoline function as we go.
--HG--
extra : rebase_source : 7f90ce5ba1a82dff731aff1ac17117c684b7b2cf
This adds a fallible version of |NS_UnescapeURL| that can be used to
gracefully handle allocation failures when the string needs to be unescaped.
MozReview-Commit-ID: 1eXPzeB2yrI
Hook this into the browser via the XREAppData. This patch does not include the changes to Chromium source code.
--HG--
extra : rebase_source : e34e8b50101cc40ded26e80791052123b24c8243
extra : histedit_source : 69c9b2dc91546adbfdad03b5d43842809191ffb9
Added ASSERTions to nsWindowsDllInterceptor in case of a failed detour hook, with an exception for the RET opcode that appears in ImmReleaseContext. Added documentation about TestDllInterceptor.
--HG--
extra : rebase_source : 48a38a09a1feb63600e12eba997a83f646cd1595
extra : histedit_source : 566cec5c47c400402e2e4dfa0cdc6d53d82b0815
This includes a near-jump CALL instruction in x64, which expands to a far-jump CALL with a 64-bit address as inline data. This requires us to abandon the method where we memcpy the code block into the trampoline and, instead, build the trampoline function as we go.
--HG--
extra : rebase_source : f0362c4b8200ba3d05191fdd45c5783dccd444bc
extra : histedit_source : 3018adf0c7d5849f87adc5e5459acf9f0e56301c
Added ASSERTions to nsWindowsDllInterceptor in case of a failed detour hook, with an exception for the RET opcode that appears in ImmReleaseContext. Added documentation about TestDllInterceptor.
This includes a near-jump CALL instruction in x64, which expands to a far-jump CALL with a 64-bit address as inline data. This requires us to abandon the method where we memcpy the code block into the trampoline and, instead, build the trampoline function as we go.
The new names make it clearer that these actions apply to just one thread.
- profiler_sleep_start() --> profiler_thread_sleep()
- profiler_sleep_end() --> profiler_thread_wake()
- profiler_is_sleeping() --> profiler_thread_is_sleeping()
- GeckoProfilerSleepRAII --> GeckoProfilerThreadSleepRAII
- GeckoProfilerWakeRAII --> GeckoProfilerThreadWakeRAII
It's fairly straightforward, and measures the important parts of:
- Sampler, PseudoStack, ProfileBuffer, ThreadInfo.
- LUL, PriMap, SecMap
Coverage isn't perfect, but it gets the major things I found via DMD on Linux.
Example output in about:memory:
├──151.21 MB (49.73%) -- profiler
│ ├──141.49 MB (46.53%) ── lul
│ └────9.72 MB (03.20%) ── sampler
--HG--
extra : rebase_source : 67d2ada42aead43f68f5100a08204a1d1f1cfceb
For components also referencing it in code, see the blockers of bug 1336311.
MozReview-Commit-ID: 4tUZ24HKBWy
--HG--
extra : rebase_source : ec16149f525b9b7eaca7f96f1369929d21497121
Handling potential nsDeque size changes means a bit of extra work.
But if the nsDeque is const, we can assume that it shouldn't get modified, so
we can provide a more optimized iterator that doesn't need to handle size
changes.
Optimizing a range-for loop in which the deque is not modified, can be done
by writing: `for (void* item : const_cast<const nsDeque&>(deque)) {...}`
MozReview-Commit-ID: AFupjoTsoH3
--HG--
extra : rebase_source : a71b09c9cb73787ce686c7c762f92ef0c208e76a
Note that iterators stay at the same index if the deque size changes
(including end-iterators staying at the end).
This means that after front operations, iterators will effectively point at
different elements! (Possibly skipping or re-visiting some.)
But this is consistent with ForEach and hand-crafted index-based for loops.
MozReview-Commit-ID: 5IvazJR68dG
--HG--
extra : rebase_source : c574fd2d2642d784482698c0fc861269200d1059
We can make some assumptions now that the Input method is only called once and never again while a decode is pending.
MozReview-Commit-ID: EmzKEcwNY2J
--HG--
extra : rebase_source : 42ae59878962b425970a60abe25d98c023ef4fdf
Removing the exported symbols is straightforward enough.
The only wrinkle is that PeerConnectionCtx.cpp gets compiled with and
without MOZILLA_INTERNAL_API. When compiling without
MOZILLA_INTERNAL_API, mozilla::services::Get*Service was redirected to
the _external_* symbol variants. But as the _external_* symbols no
longer exist, PeerConnectionCtx.cpp's code no longer worked.
Fortunately, PeerConnectionCtx.cpp already contains a few #ifdef
MOZILLA_INTERNAL_API blocks to handle internal/external compilation;
fixing this newest issue was just a matter of extending existing blocks
and adding new ones. The key observation is that we never added any
observers when compiling without MOZILLA_INTERNAL_API, so we can #ifdef
out the removals of observers, as those would have no effect, and simply
skip getting the observer service for the observer additions if we're
compiling without MOZILLA_INTERNAL_API.