$ the-wire · showcase
ExecuTorch fixes a Python-side deadlock and zero-stride export failures
By RepoJournal · Filed · About PyTorch · Composed from the cited sources · methodology
14 people shipped this
shoumikhin
@shoumikhin
3 cited
albanD
@albanD
1 cited
jathu
@jathu
1 cited
huydhn
@huydhn
1 cited
Richard Barnes
@r-barnes
mcremon-meta
@mcremon-meta
Chinmay Kuchinad
@chinmaydk99
Aditya Venkataraman
@aditvenk
Jeff Daily
@jeffdaily
peterdsharpe
@peterdsharpe
github-actions[bot]
@github-actions[bot]
izaitsevfb
@izaitsevfb
can-gaa-hou
@can-gaa-hou
Ben Sprenger
@bsprenger
ExecuTorch's Python runtime no longer hangs when a backend logs while holding a lock, and its exporter now handles zero-stride constants and inputs that previously failed outright.
Python runtime: stop a backend's log from deadlocking 2 threads pytorch/executorch
Two threads could previously hang forever when a backend logged while holding a lock, as XNNPACK does on a failed load: the logging thread's write to sys.stderr releases the GIL, and the thread that grabs it then blocks on the same lock. The fix removes that cycle, so a failed XNNPACK load on a threaded runtime returns instead of stalling both threads.
Fix export of zero-stride constants and inputs, and of constants that delegates share pytorch/executorch
Export used to fail with `0 in strides is not supported for ExecuTorch.` whenever a size-1 dimension carried a zero stride, because `contiguous()` does not normalize size-1 strides; the tell is `torch.tensor(2.0).expand(1).contiguous().stride()` still returning `(0,)`. The pass now handles zero-stride constants and inputs, along with constants shared between delegates.
Fix wrong dtypes and values in Core ML conversion pytorch/executorch
coremltools lowered several ops differently from PyTorch, so conversion either failed or produced wrong values: `sqrt`, `exp` and `sin` on int or bool tensors, `floor`/`ceil`/`round`/`relu`/`relu6`/`hardtanh` on int tensors, and int-into-float copies of the `y[:, i] = v` form. The conversion now matches PyTorch's dtype and value behavior for those cases.
[mobile] Bounds-check operator index in applyUpgrader (#202626) pytorch/pytorch
`applyUpgrader()` in `torch/csrc/jit/mobile/parse_bytecode.cpp` indexed `code.op_names_[inst.X]` for every OP instruction without checking the index, so both the ZIP and FlatBuffer loaders could read out of bounds while loading a model whose operator version is older than the current one. The author describes it as a small security improvement: loading such model files is now bounds-checked.
[alerts] Split the autoscaled queue alert by runner fleet, add a P1 rule pytorch/test-infra
The "Jobs are Queued - autoscaled-machines" alert now splits by runner fleet (`mt-`, `lf-`, Windows, other) and excludes GitHub-hosted runners, because the old rule fired on any single job waiting 60 minutes, roughly three times a day. The Nov 2 SEV stayed at P2 while about 2,000 jobs queued on `mt-` runners for 7 hours; replaying 61 days of queue data, the new P2 fires about 6 times a week.
Optimize test queries for performance pytorch/test-infra
`GET /api/tests` got substantially faster in torchci: the default page drops from 8.7 s to 1.4 s, the cursor page from 8.1 s to 1.3 s with its boundary probe from 5.4 s to 0.9 s, and saved views from 4.4 to 10.1 s down to 0.6 to 1.4 s. Quiet elsewhere: test-infra shipped an automated-review feedback link and a `late-report` event for post-hoc triage verdicts, tensordict fixed one-element stride...
