Normally we expect timer creation/initialization to be infallible, but there appear to be rare cases where it fails.
It would be good to understand the cause, but first of all we should honor the return value in case of error.
Note that allocations during timer init are infallible since bug 1961386, so most likely the cause is not running low on memory.
Original Revision: https://phabricator.services.mozilla.com/D262593
Differential Revision: https://phabricator.services.mozilla.com/D266578
The patch to bug 1979546 refactored the logic that awaits the process
termination. The logic that processes process termination should stop
the poll loop() via updatePollEvents(). This did not happen, because
updatePollEvents() considered a process alive if it is in
`io.processes`, but the updatePollEvents() was not called when
`cleanupProcess` cleared the last reference.
Consequently, the poll loop continued forever if the process's pipes
closed before the process.
Original Revision: https://phabricator.services.mozilla.com/D261060
Differential Revision: https://phabricator.services.mozilla.com/D266338
The current WaitForMultipleObjects-based implementation causes a
deadlock if 16 or more processes are spawned, as explained in the bug.
This patch replaces the use of events and WaitForMultipleObjects with
I/O Completion Ports (IOCP) as the mechanism to monitor I/O progress
and process terminations. This is not subject to the
MAXIMUM_WAIT_OBJECTS (64) limit of WaitForMultipleObjects.
Original Revision: https://phabricator.services.mozilla.com/D258968
Differential Revision: https://phabricator.services.mozilla.com/D266337
- Updated `Cargo.toml` to point to the app-services commit with the fix
- Reverted my default rust to `1.86.0`
- Ran `./mach configure` and `./mach vendor rust`
Differential Revision: https://phabricator.services.mozilla.com/D266197
CanvasTranslator::RemoveTexture delayed the call to RemoveDrawTarget till all keepalives are
gone. However, this may take place long after RecordedTextureDestruction actually called
RemoveTexture. This gives time for subsequent DrawTargets with the same ReferencePtr to be
created, causing the wrong DrawTargets to be removed.
This patch ensures that when RemoveTexture is called from a RecordedTextureDestruction event
that the DrawTarget is always removed then and there, rather than waiting.
Differential Revision: https://phabricator.services.mozilla.com/D265867
CanvasTranslator::RemoveTexture delayed the call to RemoveDrawTarget till all keepalives are
gone. However, this may take place long after RecordedTextureDestruction actually called
RemoveTexture. This gives time for subsequent DrawTargets with the same ReferencePtr to be
created, causing the wrong DrawTargets to be removed.
This patch ensures that when RemoveTexture is called from a RecordedTextureDestruction event
that the DrawTarget is always removed then and there, rather than waiting.
Differential Revision: https://phabricator.services.mozilla.com/D265867
The new XPI file has been generated from this PR [1], and signed by the
AMO -dev instance (which uses the nonprod cert). FTR since this add-on
needs a recommendation state, we must add the add-on to the "By Firefox"
promoted group via the AMO admin before getting the version signed.
Before:
```
$ xpidump old.xpi
MANIFEST:
ID : N/A
Version : 2.0
Enterprise: No
RECOMMENDATION:
[Line]
SIGNATURES:
PKCS7:
└── PRESENT / PRODUCTION / SHA-1 / REGULAR ADD-ON
└── Certificates:
└── Common Name (CN): signingca1.addons.mozilla.org
Organizational Unit (OU): Mozilla AMO Production Signing Service
End Date : 2025-04-04T00:00:00Z
└── Common Name (CN): {811d77f1-f306-4187-9251-b4ff99bad60b}
Organizational Unit (OU): Production
End Date : 2030-09-15T16:50:45Z
COSE:
└── PRESENT / PRODUCTION / ES256 / REGULAR ADD-ON
└── Certificates:
└── Common Name (CN): signingca1.addons.mozilla.org
Organizational Unit (OU): Mozilla AMO Production Signing Service
End Date : 2025-04-04T00:00:00Z
└── Common Name (CN): {811d77f1-f306-4187-9251-b4ff99bad60b}
Organizational Unit (OU): Production
End Date : 2030-09-15T16:50:45Z
```
After:
```
$ xpidump new.xpi
MANIFEST:
ID : recommended-line@test.mozilla.org
Version : 3.0
Enterprise: No
RECOMMENDATION:
[Line]
SIGNATURES:
PKCS7:
└── PRESENT / STAGING / SHA-256 / REGULAR ADD-ON
└── Certificates:
└── Common Name (CN): cas-intermediate-amo-ca-staging
Organizational Unit (OU): Mozilla Staging Signing Service
End Date : 2050-12-31T00:00:00Z
└── Common Name (CN): recommended-line@test.mozilla.org
Organizational Unit (OU): Production
End Date : 2035-09-17T07:29:49Z
COSE:
└── PRESENT / STAGING / ES256 / REGULAR ADD-ON
└── Certificates:
└── Common Name (CN): cas-intermediate-amo-ca-staging
Organizational Unit (OU): Mozilla Staging Signing Service
End Date : 2050-12-31T00:00:00Z
└── Common Name (CN): recommended-line@test.mozilla.org
Organizational Unit (OU): Production
End Date : 2035-09-17T07:29:49Z
```
[1]: https://github.com/mozilla/mozilla-central-test-xpis/pull/15
Differential Revision: https://phabricator.services.mozilla.com/D265576
Use `oneByteOp8` to emit the `REX` prefix for byte registers if needed. This fixes an
issue with our code for `LStringToLowerCase` for certain register combinations/values.
With patches for bug 1986983 this was caught by jit-tests on Win64-debug builds.
Original Revision: https://phabricator.services.mozilla.com/D263972
Differential Revision: https://phabricator.services.mozilla.com/D264208
