This tests that JS holders get marked gray by GC and updated when moved by
compacting GC. The latter would have caught the problem reported in bug
1731432.
Differential Revision: https://phabricator.services.mozilla.com/D127670
This tests that JS holders get marked gray by GC and updated when moved by
compacting GC. The latter would have caught the problem reported in bug
1731432.
Differential Revision: https://phabricator.services.mozilla.com/D127670
objdir/dist/include/mozilla/Queue.h:251:31: error: use of undeclared identifier 'moz_xcalloc'
xpcom/base/nsCOMPtr.h:436:5: error: static_assert failed due to requirement '1 < sizeof (TestForIID<nsIEventTarget>(nullptr))' "nsCOMPtr only works for types with IIDs. Either use RefPtr; add an IID to your type with NS_DECLARE_STATIC_IID_ACCESSOR/NS_DEFINE_STATIC_IID_ACCESSOR; or make the nsCOMPtr point to a base class with an IID."
xpcom/tests/gtest/TestDelayedRunnable.cpp:16:28: error: field has incomplete type '(anonymous namespace)::ReleaseDetector'
xpcom/tests/gtest/TestDelayedRunnable.cpp:16:3: error: 'explicit' can only appear on non-static member functions
xpcom/tests/gtest/TestDelayedRunnable.cpp:16:40: error: expected ')'
xpcom/tests/gtest/TestDelayedRunnable.cpp:16:61: error: use of undeclared identifier 'aActive'
xpcom/tests/gtest/TestDelayedRunnable.cpp:28:3: error: no template named 'Atomic'; did you mean 'mozilla::Atomic'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:34:3: error: no template named 'Atomic'; did you mean 'mozilla::Atomic'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:36:18: error: use of undeclared identifier 'TaskQueue'; did you mean 'taskQueue'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:36:18: error: variable 'taskQueue' declared with deduced type 'auto' cannot appear in its own initializer
xpcom/tests/gtest/TestDelayedRunnable.cpp:36:48: error: use of undeclared identifier 'MediaThreadType'
xpcom/tests/gtest/TestDelayedRunnable.cpp:36:48: error: use of undeclared identifier 'MediaThreadType'; did you mean 'mozilla::MediaThreadType'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:38:51: error: no matching conversion for functional-style cast from 'Atomic<bool> *' to '(anonymous namespace)::ReleaseDetector'
xpcom/tests/gtest/TestDelayedRunnable.cpp:54:3: error: no template named 'Atomic'; did you mean 'mozilla::Atomic'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:58:51: error: no matching conversion for functional-style cast from 'Atomic<bool> *' to '(anonymous namespace)::ReleaseDetector'
xpcom/tests/gtest/TestDelayedRunnable.cpp:88:3: error: use of undeclared identifier 'Unused'; did you mean 'mozilla::Unused'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:104:3: error: use of undeclared identifier 'Unused'; did you mean 'mozilla::Unused'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:109:10: error: unknown type name 'SharedThreadPool'; did you mean 'mozilla::SharedThreadPool'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:109:35: error: use of undeclared identifier 'SharedThreadPool'
xpcom/tests/gtest/TestDelayedRunnable.cpp:109:35: error: use of undeclared identifier 'SharedThreadPool'; did you mean 'mozilla::SharedThreadPool'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:110:25: error: use of function template name with no prior declaration in function call with explicit template arguments is a C++20 extension [-Werror,-Wc++20-extensions]
xpcom/tests/gtest/TestDelayedRunnable.cpp:110:36: error: unknown type name 'TaskQueue'; did you mean 'mozilla::TaskQueue'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:112:36: error: unknown type name 'TaskQueue'; did you mean 'mozilla::TaskQueue'?
xpcom/tests/gtest/TestFileNTFSSpecialPaths.cpp:18:28: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFileNTFSSpecialPaths.cpp:26:28: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFileNTFSSpecialPaths.cpp:39:28: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFileNTFSSpecialPaths.cpp:279:28: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFilePreferencesWin.cpp:113:26: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFilePreferencesWin.cpp:140:26: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFilePreferencesWin.cpp:156:31: error: use of undeclared identifier 'NS_OS_TEMP_DIR'
xpcom/tests/gtest/TestJSHolderMap.cpp:50:28: error: unknown type name 'JSHolderMap'
xpcom/tests/gtest/TestJSHolderMap.cpp:52:35: error: use of undeclared identifier 'i'
xpcom/tests/gtest/TestJSHolderMap.cpp:52:45: error: use of undeclared identifier 'i'
xpcom/tests/gtest/TestJSHolderMap.cpp:52:8: error: use of undeclared identifier 'JSHolderMap'
xpcom/tests/gtest/TestJSHolderMap.cpp:52:8: error: use of undeclared identifier 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:53:24: error: use of undeclared identifier 'i'
xpcom/tests/gtest/TestJSHolderMap.cpp:54:24: error: use of undeclared identifier 'i'
xpcom/tests/gtest/TestJSHolderMap.cpp:68:3: error: unknown type name 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:73:3: error: unknown type name 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:99:3: error: unknown type name 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:104:9: error: use of undeclared identifier 'JSHolderMap'
xpcom/tests/gtest/TestJSHolderMap.cpp:104:9: error: use of undeclared identifier 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:125:41: error: use of undeclared identifier 'MakeUnique'
xpcom/tests/gtest/TestJSHolderMap.cpp:147:3: error: unknown type name 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:151:41: error: use of undeclared identifier 'MakeUnique'
xpcom/tests/gtest/TestRWLock.cpp:92:3: error: no template named 'Maybe'; did you mean 'mozilla::Maybe'?
xpcom/tests/gtest/TestRWLock.cpp:95:23: error: use of undeclared identifier 'SyncRunnable'; did you mean 'mozilla::SyncRunnable'?
xpcom/tests/gtest/TestRWLock.cpp:103:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:107:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:111:7: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:120:7: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:130:5: error: unknown type name 'AutoWriteLock'; did you mean 'mozilla::AutoWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:133:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:137:7: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:142:3: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:146:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:155:5: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:159:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:163:7: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:172:7: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:182:5: error: unknown type name 'AutoReadLock'; did you mean 'mozilla::AutoReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:184:5: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:188:7: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:194:5: error: unknown type name 'AutoWriteLock'; did you mean 'mozilla::AutoWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:197:5: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:201:7: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
Differential Revision: https://phabricator.services.mozilla.com/D127042
xpcom/tests/gtest/TestAvailableMemoryWatcherWin.cpp(130,22): error: variable 'x' set but not used [-Werror,-Wunused-but-set-variable]
volatile uint8_t x = 0;
^
xpcom/tests/gtest/TestAvailableMemoryWatcherWin.cpp(152,12): error: variable 'consumed' set but not used [-Werror,-Wunused-but-set-variable]
size_t consumed = 0;
^
xpcom/tests/gtest/TestSTLWrappers.cpp:48:7: error: variable 'rv' set but not used [-Werror,-Wunused-but-set-variable]
int rv = 1;
^
Differential Revision: https://phabricator.services.mozilla.com/D126462
When adding new gtests I came across this build failure:
```
0:12.59 In file included from Unified_cpp_xpcom_tests_gtest2.cpp:2:
0:12.59 /home/kriswright/src/mozilla-unified/xpcom/tests/gtest/TestMultiplexInputStream.cpp:349:45: error: no viable conversion from 'nsCOMPtr<nsIThread>' to 'nsIEventTarget *'
```
It looks like this file needs to include nsIThread in its #includes.
Differential Revision: https://phabricator.services.mozilla.com/D125851
The goal here is to ensure we can always rely on `AppShutdown::GetShutdownPhase` to be in sync with the "real" application status, mainly this was needed for xpcshell tests to not break if we add assertions on our shutdown state on some global singletons.
We keep the existing observer notification topics but force them (on the parent process) to be issued through the new `advanceShutdownPhase` function of the startup service using the `ShutdownPhase` enum. This way we can synchronize `AppShutdown`'s internal status accordingly.
Some further notes:
# The `MOZ_ASSERT(AppShutdown::IsNoOrLegalShutdownTopic(aTopic));` in `NotifyObservers` helped a lot to identify missing cases. I think we should keep it in order to stay safe.
# Introducing the `cenum IDLShutdownPhase` helps to keep the knowledge about the mapping from shutdown phases to observer topics exclusively inside AppShutdown.cpp. Still callers must know what they do in order to choose a proper phase, of course.
# However we must be aware that `AppShutdown` this way can be kept in sync with the shutdown notifications only in the parent process and that `GetCurrentShutdownPhase` might not give the correct result in child processes. We might want to file a follow up bug that adds some asserts to avoid improper use of `AppShutdown` functions in child processes (but I do not want to make this patch bigger as needed to solve the blocking dependency for bug 1697972).
# The socket process is one example of a child process that "overloads" shutdown topics. I was wondering if it is the right call to use the very same topic names here to request shutdown to the socket process or if it should have its own topics. Those topics triggered the assert and thus I had to disable it for child processes, for now.
# This goes together with the more general approach to define process type specific shutdown phases (and hence mappings to topics) as drafted very roughly in bug 1697745.
# This patch seemed to trigger a known intermittent more often, thus the change here in `ServiceWorkerManager`.
Differential Revision: https://phabricator.services.mozilla.com/D124350
Add `NS_ConvertUTF16toUTF8::NS_ConvertUTF16toUTF8(const Span<const char16_t>)` and `NS_ConvertUTF16toUTF8::NS_ConvertUTF8toUTF16(const Span<const char>)` explicit constructors.
This is consistent with `NS_ConvertASCIItoUTF16` that already had one.
More importantly, other constructors were calling `AppendUTF{16,8}To{8,16}` functions taking a `Span`, so for cases where the caller already has a `Span` it's most efficient to have constructors accepting that `Span` directly.
Differential Revision: https://phabricator.services.mozilla.com/D125146
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
Add a new encoding mode to be used to encode an already-encoded URL to be compatible with Apple's NSURL.
Add a function for creating an nsIURI with NSURL compatible encoding from a URL string.
Differential Revision: https://phabricator.services.mozilla.com/D122651
The new event is recoreded when we detect the system's memory is no longer low.
Each event object contains three numbers:
1) how many times a tab was unloaded during the low-memory situation
2) how many memory-pressure events were dispatched during the low-memory
situation
3) how long we were in the low-memory situation in seconds
These need to be collected as the event ping because the memory situation
may repeatedly be switched between low-memory and high-memory. We want to
collect it every time the memory situation gets back to normal. If we collect
it as the main ping (like Histogram), all numbers are summed up and we cannot
evaluate each low-memory period.
Differential Revision: https://phabricator.services.mozilla.com/D120021
When the physical memory is low, Windows OS triggers the memory notification callback,
but we don't take any action if the commit space is not low because it is not the case
of a potential OOM crash. The problem is in that case, we unregister the wait handle
and exit from the callback. This means we lose a way to watch memory after that.
The proposed fix is to start a timer before exiting the callback. We could re-register
the callback, but it could be triggered too quickly if the low-physical-but-high-commit-space
situation lasts long. After the timer starts, the first timer handler (interval: 10 sec)
checks the commit space again, and if the commit space is still not low at that time,
we re-register the callback and stop the timer.
One tricky situation we need to consider is we don't actually start the timer while
the user is inactive. In that case, we mark the flag `mNeedToRestartTimerOnUserInteracting`
and start the timer when the user becomes active later. With that, `OnHighMemory` can
be executed even when we didn't in the low-memory situation. So we need to check another
flag `mUnderMemoryPressure` and record the telemetry and send a memory-pressure-stop event
only when we were in the low-memory situation.
Differential Revision: https://phabricator.services.mozilla.com/D120022
We had `NS_DispatchMemoryPressure` and `NS_DispatchEventualMemoryPressure`
to dispatch a memory-pressure event which took `MemPressure_New` and
`MemPressure_Ongoing` to translate into "low-memory" and "low-memory-ongoing"
message respectively.
With that model, we could end up sending a wrong message if somebody
called the API with `MemPressure_Ongoing` without sending `MemPressure_New`.
To avoid that, this patch removes `MemPressure_Ongoing` and makes
the API decide whether it should dispatch a "new" event or "ongoing" event.
Differential Revision: https://phabricator.services.mozilla.com/D119122
We had `NS_DispatchMemoryPressure` and `NS_DispatchEventualMemoryPressure`
to dispatch a memory-pressure event which took `MemPressure_New` and
`MemPressure_Ongoing` to translate into "low-memory" and "low-memory-ongoing"
message respectively.
With that model, we could end up sending a wrong message if somebody
called the API with `MemPressure_Ongoing` without sending `MemPressure_New`.
To avoid that, this patch removes `MemPressure_Ongoing` and makes
the API decide whether it should dispatch a "new" event or "ongoing" event.
Differential Revision: https://phabricator.services.mozilla.com/D119122
In the gtest for these patches, we can encounter a hang in the following steps:
- Monitor waits in the main thread (for async steps to finish)
- Offthread, monitor waits for the timer to fire
- Timer notifies the waiting monitors
- Monitor on the main thread continues first, wrapping up the test. It assumes all async steps are finished.
- The offthread monitor wait follows, but at this point the main thread has dereferenced the monitor. Because of this race, we run into a UAF and hang on the offthread monitor.
My solution for this is to use two monitors, and notify the outer one after we have=completed all of the async steps including the wait for the timer notification. This should avoid a race between the inner `monitor.wait()` and the free at the end of the tests.
Tentative try push for the fix: https://treeherder.mozilla.org/jobs?repo=try&revision=307960b2899b320ef5a82d276b86d633a9653941
Differential Revision: https://phabricator.services.mozilla.com/D116163
Jon Coppeard
Csoregi Natalia
Jens Stutte
Marian-Vasile Laza
Mike Hommey
Byron Campen
kriswright
Gerald Squelart
Andreas Pehrson
Iulian Moraru
Cristian Tuns
Andi-Bogdan Postelnicu
Kagami Sascha Rosylight
Haik Aftandilian
Valentin Gosu
Toshihito Kikuchi
Tooru Fujisawa
Paul Bone
Butkovits Atila
Nika Layzell
Alexandru Michis
Brindusan Cristian