Skip to content

[skia-sync] Merge upstream chrome/m148#266

Closed
mattleibow wants to merge 3 commits into
release/4.148.xfrom
skia-sync/release-4.148.x
Closed

[skia-sync] Merge upstream chrome/m148#266
mattleibow wants to merge 3 commits into
release/4.148.xfrom
skia-sync/release-4.148.x

Conversation

@mattleibow

Copy link
Copy Markdown
Collaborator

Automated upstream merge of chrome/m148.

Upstream merge

Merged upstream/chrome/m148 (46f2e16555cac1211f4087cf24728fd741ac6495) into
skia-sync/release-4.148.x on top of the existing release-line tip
(1a155bae3ac86db6d3efbd996f00e774b6a7b722, which was the m148 merge that shipped in 4.148.0).

This is a release-line, bug-fix-only sync (current m148 == target m148).
Two upstream cherry-picks were applied since the last sync (54851b68b):

SHA Subject Files touched Affects SkiaSharp?
46f2e16555 [m148] Resolved a Data Race on fStream in SkTypeface_Mac src/ports/SkTypeface_mac_ct.{cpp,h} Yes (macOS only) — eliminates a TOCTOU race on fStream in the global gTFCache
3a90f6662a [graphite] Use stable collection for static bindings src/gpu/graphite/dawn/DawnGraphicsPipeline.cpp No — Graphite/Dawn-only; SkiaSharp ships Ganesh, not Graphite

Conflicts resolved

None. git merge --no-commit upstream/chrome/m148 reported
"Automatic merge went well; stopped before committing as requested" and git diff --check
showed zero conflict markers. The C API shim (src/c/*.cpp, include/c/*.h,
include/xamarin/**) was untouched by both upstream commits.

C API fixes

None. Neither commit touches headers consumed by src/c/ or include/c/, so no
shim adaptation was needed. SK_C_INCREMENT (in include/c/sk_types.h) is unchanged.

Build verification

  • dotnet cake --target=externals-linux --arch=x64 succeeded (libSkiaSharp 14m04s,
    libHarfBuzzSharp 01m12s, total 15m28s). The resulting libSkiaSharp.so.148.0.0
    links cleanly with the documented dependency set (libfontconfig.so.1, libc++.so.1,
    libc++abi.so.1, libunwind.so.1, libm/libc/ld-linux).
  • macOS / Windows / Android / iOS native builds are NOT exercised by this workflow —
    the actual cherry-pick (SkTypeface_mac_ct) is Mac-only, so the multi-platform CI
    on the resulting PR is the source of truth for that file.

Items needing human attention

  • macOS native validation. The headline fix is macOS-only and cannot be compiled on
    the Linux CI used for this sync. Verify the macOS leg of the resulting PR's
    cross-platform build passes before merging.
  • No DEPS or BUILD.gn changes. This is purely a source-only sync; depot_tools/gn
    metadata is untouched.

Created by skia-upstream-sync.

lhkbob and others added 3 commits June 15, 2026 10:55
Since the layouts are passed by pointer in the `nextInChain` field,
their addresses need to stay valid until the BindGroupLayout is created.
With vector, if it ever grew, that would not remain the case. Since
there are usually only 0 to 1 immutable samplers, this likely never
happened (and also why it uses a built-in storage for 1).

Also removes the include for vector and uses TArray (we had been mixing
both throughout the file).

Bug: 520514458
Fixed: 523531990
Change-Id: I44c9566c68ab0e6c6d659ea77a423ddc50d53c76
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1264157
Reviewed-by: Thomas Smith <thomsmit@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
(cherry picked from commit 6a4be3a)
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1266356
There was a data race in SkTypeface_Mac where `onOpenStream`
and `onOpenExistingStream` would race to read/write `fStream`. While `onOpenStream` would begin initializing `fStream` on one thread, a separate thread could be calling `onOpenExistingStream` to try to read `fStream` before it was done initializing.

The issue was resolved by applying a mutex on `fStream`.

The cl introducing this bug (https://skia-review.git.corp.google.com/c/skia/+/204720) was focused on caching the typefaces received with a global process wide `gTFCache` to save on performance and memory. The issue arose in that since the SkTypeface_Mac could be accessed across threads, it became thread unsafe.

A test was added to this CL but removed as it was too large and took too long. It helps us keep it in the patch history for reference.

Bug: b/520535595
Bug: 520535595
Fixed: 524508854
Change-Id: Id28aeed3d67a5a5246d22681f2c7ab0e6c133558
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1264296
Commit-Queue: Alexis Cruz-Ayala <alexisdavidc@google.com>
Reviewed-by: Kaylee Lubick <kjlubick@google.com>
(cherry picked from commit ba3ee9b)
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1274476
…lease-4.148.x

Picks up 2 upstream bug fixes since 54851b6:
* 46f2e16 [m148] Resolved a Data Race on fStream in SkTypeface_Mac
* 3a90f66 [graphite] Use stable collection for static bindings (graphite-only)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@mattleibow

Copy link
Copy Markdown
Collaborator Author

Closing stale skia-sync validation branch/PR to give the refactored auto-skia-sync workflow a clean slate for a fresh run.

@mattleibow mattleibow closed this Jun 26, 2026
@mattleibow mattleibow deleted the skia-sync/release-4.148.x branch June 26, 2026 20:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants