[wasm] Bump chrome for testing - linux: 116.0.5845.179, windows: 116.0.5845.180 by github-actions[bot] · Pull Request #2 · eduardo-vp/runtime

github-actions · 2023-09-10T00:41:11Z

No description provided.

Fixes dotnet#95367. Relevant part of the JitDump: ``` Using `if true` assertions from pred BB02 Assertions in: #1 fgMorphTree BB04, STMT00021 (before) [000070] DA--------- * STORE_LCL_VAR ubyte V10 tmp9 [000057] ----------- \--* CAST int <- ubyte <- int [000006] ----------- \--* EQ int [000004] ----------- +--* LCL_VAR ref V02 tmp1 (last use) [000055] H---------- \--* CNS_INT(h) ref 'Frozen EmptyPartition`1<Int32> object' Assertion prop for index #1 in BB04: [000006] ----------- * EQ int GenTreeNode creates assertion: [000070] DA---+----- * STORE_LCL_VAR ubyte V10 tmp9 In BB04 New Local Constant Assertion: V10 == [0000000000000001], index = #2 fgMorphTree BB04, STMT00021 (after) [000070] DA---+----- * STORE_LCL_VAR ubyte V10 tmp9 [000055] H----+----- \--* CNS_INT(h) int ``` The JitDump is unfinished because the compiler crashes when trying to dump the last line. Clearly, the `CNS_INT` is no longer a handle at that point because we just bashed it to a constant 1.

…tnet#95292) * Add IndentText json option * Add IndentText for json source generator * Add tests * IndentText must be non-nullable * Improve performance * Add extra tests * Cleanup * Apply suggestions from code review Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com> * Fixes following code review * Fixes following code review #2 * Add tests for invalid characters * Handle RawIndent length * Move all to RawIndentation * Update documentation * Additional fixes from code review * Move to the new API * Extra fixes and enhancements * Fixes from code review * Avoid introducing extra fields in JsonWriterOptions * Fix OOM error * Use bitwise logic for IndentedOrNotSkipValidation * Cache indentation options in Utf8JsonWriter * Add missing test around indentation options * New fixes from code review * Update src/libraries/System.Text.Json/src/System/Text/Json/Writer/Utf8JsonWriter.cs * Add test to check default values of the JsonWriterOptions properties * Fix comment --------- Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>

* [wasm] Bump emscripten to 3.1.56 * Replace Module.asm with Module.wasmExports Module.asm was removed, use wasmExports instead. Context: emscripten-core/emscripten#19816 * Updates for .native.worker.js -> mjs rename Context: emscripten-core/emscripten#21041 * Update deps * Add general testing feed * Update mode deps * Update path * Use current python packages for now, we don't have newer ones The current names 3.1.34 are new enough * Keep using llvm 16 for runtime and aot compiler * Add -Wno-pre-c11-compat only for browser * Temporarily disable version checks to get further * Temporarily disable version checks to get further #2 * Disable -Wunused-command-line-argument * Update emsdk deps * Update icu dependency * Revert "Temporarily disable version checks to get further #2" This reverts commit 3f8834f. * Revert "Temporarily disable version checks to get further" This reverts commit fe1e5c6. * Fix emsdk check We use system python on osx too * Workaround wasm-opt crash * Workaround wasm-opt crash * Workaround wasm-opt crash * Fix WBT test * Feedback * Update ICU dependency * Update emscripten deps * Revert "Workaround wasm-opt crash" This reverts commit 200cf3b. * Revert "Workaround wasm-opt crash" This reverts commit 4530edf. * Revert "Workaround wasm-opt crash" This reverts commit 3593c41. * Increase tests timeout * Show test progress * Increase MT library tests timeout * Disable WBT tests with SkiaSharp * Increase helix tests timeout on browser * Increase WBT timeout * Increase initial heap sizes * Fix mono_wasm_load_runtime cwrap signature Fixes: `Uncaught ExitStatus: Assertion failed: stringToUTF8Array expects a string (got number)` * Enable XunitShowProgress for threading tasks tests * Try to reduce number of parallel AOT compilations To check whether it will improve memory issues on CI * Use new docker image for helix/windows tests * Revert "Try to reduce number of parallel AOT compilations" This reverts commit 5d9a6d2. * Reduce the timeouts * Reduce intitial heap size * use active issues for MT * Remove testing channel from nuget config, update deps * Update emsdk and icu dependencies --------- Co-authored-by: Larry Ewing <lewing@microsoft.com> Co-authored-by: pavelsavara <pavel.savara@gmail.com>

* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)

…otnet#124642) ## Summary Fixes dotnet#123621 When a constant-folded operand appears **after** a non-constant operand in a short-circuit `&&` expression (e.g., `v == 2 && Environment.NewLine != "\r\n"`), callee inlining can leave dead local stores in the return block. The `isReturnBool` lambda in `fgFoldCondToReturnBlock` required `hasSingleStmt()`, which caused the optimization to bail out when these dead stores were present, resulting in suboptimal branching codegen. ### Changes - **`src/coreclr/jit/optimizebools.cpp`**: Relax the `hasSingleStmt()` constraint in `isReturnBool` to allow preceding statements as long as they have no globally visible side effects (`GTF_GLOBALLY_VISIBLE_SIDE_EFFECTS`). This enables `fgFoldCondToReturnBlock` to fold the conditional into a branchless return even when dead local stores from inlining remain in the block. ### Before (ARM64, `Inline_After`) ```asm cmp w0, #2 bne G_M4495_IG04 mov w0, #1 ret G_M4495_IG04: mov w0, #0 ret ``` ### After (ARM64, `Inline_After`) ```asm cmp w0, #2 cset x0, eq ret ``` ## Test plan - [x] Added regression test `Runtime_123621` covering the original issue pattern - [x] Verified `Hoisted`, `Inline_Before`, and `Inline_After` all produce identical branchless codegen (`cset` on ARM64) - [x] Verified existing `DevDiv_168744` regression test still passes - [x] Verified side-effect-ful blocks are correctly excluded from the optimization

…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixes dotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

An Android production app reported a native abort while building an X.509 chain on arm64. The available tombstone snippet showed the process aborting in `AndroidCryptoNative_X509ChainBuild` from `pal_x509chain.c`, with the native guard reporting that parameter `ctx` was not a valid pointer. The report did not include a repro or full tombstone, but the observed failure mode means managed code reached the native build entry point with a null `X509ChainContext*`. ``` Thread /__w/1/s/src/native/libs/System.Security.Cryptography.Native.Android/pal_x509chain.c:113 (AndroidCryptoNative_X509ChainBuild): Parameter 'ctx' must be a valid pointer *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** pid: 0, tid: 31609 >>> com.app.name <<< backtrace: #00 pc 0x000000000002232c /system/lib64/libc.so (abort+116) #1 pc 0x0000000000021fe8 [removed]-KwPZdoEumri00C7kBm3pQw==/lib/arm64/libSystem.Security.Cryptography.Native.Android.so #2 pc 0x00000000000220b0 [removed]-KwPZdoEumri00C7kBm3pQw==/lib/arm64/libSystem.Security.Cryptography.Native.Android.so (AndroidCryptoNative_X509ChainBuild+88) #3 pc 0x000000000000cfcc ``` `X509ChainContext` is created by `AndroidCryptoNative_X509ChainCreateContext`. That initialization can fail if Android certificate store setup or PKIX parameter construction throws, or if required JNI global references cannot be created. Previously, the managed Android chain path stored the returned `SafeHandle` without checking whether context creation failed, so a later build could pass a null native context to `AndroidCryptoNative_X509ChainBuild` and terminate the app process. This change makes context creation fail gracefully: - The native create path checks Java exceptions around object creation and method calls more consistently. - Partial native contexts are destroyed if global-reference creation fails. - The Android interop wrapper checks the returned chain context immediately, including a null safe-handle return, and throws `CryptographicException` if initialization failed. No regression test is included because the reliable failure modes depend on Android platform/provider state or artificial fault injection, and a test hook would be fragile and not representative. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Kevin Jones <kevin@vcsjones.com>

…dotnet#129280) (dotnet#129591) ## Problem `Wasm.Build.Tests.WasmTemplateTests.TypeScriptDefinitionsCopiedToWwwrootOnBuild(config: Debug, emitTypeScriptDts: True)` fails its `dotnet build -question` rebuild check with: ``` MSBUILD : error : Building target "_BuildCopyStaticWebAssetsPreserveNewest" partially, because some output files are out of date with respect to their input files. [_BuildStaticWebAssetsPreserveNewest: Input = obj\Debug\net11.0\compressed\{hash}-{0}-{fp}-{fp}.gz, Output = bin\Debug\net11.0\wwwroot\_framework\dotnet.{fp}.js.gz] Input file is newer than output file. ``` This is the same family of bug as dotnet#129280 (different surface: upstream variant where MSBuild flags `_WriteBuildWasmBootJsonFile` itself as stale; ours is the downstream cascade through compression). ## Root cause Binlog analysis: 1. `_WriteBuildWasmBootJsonFile` runs `GenerateWasmBootJson` (uses `ArtifactWriter.PersistFileIfChanged`, preserves old mtime on unchanged content) followed by `<Touch Files="$(_WasmBuildBootJsonPath)" />` (added in dotnet#125367 to keep MSBuild's I/O check on this target happy). 2. `$(_WasmBuildBootJsonPath)` — `obj/{cfg}/{tfm}/dotnet.js` — is also a source for the StaticWebAssets compression pipeline (`GenerateBuildCompressedStaticWebAssets` → `GZipCompress`). 3. `GZipCompress.cs` skips when `input.mtime < output.mtime` (strict `<`). When `Touch` lands close enough in time to the `.gz` write (or any subsequent target re-stamps dotnet.js), equal/newer mtimes send the next build's compression task down the re-compress path. 4. Re-compression on build #2 bumps `obj/.../{0}.gz` mtime past `bin/.../dotnet.{fp}.js.gz` (which was copied during build #1 and isn't touched since), so `_BuildCopyStaticWebAssetsPreserveNewest` reports its input newer than its output. `-question` fails. This is a regression of dotnet#118637 (Aug 2025, *"Override boot config only when the content changes"*), which fixed the exact same `_BuildCopyStaticWebAssetsPreserveNewest` symptom in dotnet/aspnetcore#63207 by introducing `ArtifactWriter.PersistFileIfChanged`. PR dotnet#125367's `<Touch>` undid that protection. ## Fix Touch a separate `wasm-bootjson-{build,publish}.complete.stamp` file rather than the boot JSON itself, and use the stamp as the target's `Outputs=`. MSBuild's incrementality check on the boot-JSON target stays correct (its declared output has a current mtime after every successful run), while the boot JSON's mtime remains content-derived — preserving dotnet#118637's invariant for downstream consumers. Applied to both: - `_WriteBuildWasmBootJsonFile` (build) - `GeneratePublishWasmBootJson` (publish) Both have identical shape and the same downstream consumers (StaticWebAssets compression / Copy targets). ## What's not fixed here - `_ConvertBuildDllsToWebcil` (line 431) uses the same `<Touch>` pattern but on per-item-batched `@(_WasmConvertedWebcilOutputs)`. It is *probably* exposed to the same cascade for the webcil files; not addressed here pending a per-item analysis. - Defense-in-depth in `dotnet/sdk`: `GZipCompress`/`BrotliCompress` `<` mtime check could become `<=` to harden the entire StaticWebAssets pipeline against this class of cascade. Worth a separate dotnet/sdk PR. ## Verification - Reproduces on `dotnet/runtime` PR dotnet#129454 build https://dev.azure.com/dnceng-public/public/_build/results?buildId=1470806 (`browser-wasm windows Release WasmBuildTests`, workitem `WBT-NoWebcil-MONO-ST-Wasm.Build.Tests.WasmTemplateTests`). - The WBT theory case `TypeScriptDefinitionsCopiedToWwwrootOnBuild(Debug|Release, emitTypeScriptDts:True)` exercises the `dotnet build -question` second-build check that this fix addresses. Fixes dotnet#129280 > [!NOTE] > This pull request was created with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…stem (dotnet#131877) Replaces the hardcoded struct-size table in the CoreCLR wasm P/Invoke generator with crossgen2's real field-layout engine. ## The problem `ManagedToNativeGenerator` computed wasm ABI signature strings from `System.Reflection.MetadataLoadContext`, which has no field-layout engine. Struct sizes came from a 7-entry hardcoded table, and anything outside it was a hard build error: ``` error WASM0067: SignatureMapper: unknown multi-field struct 'X' (fields: N) - add its size to s_knownStructSizes in SignatureMapper.cs ``` Size matters because the CoreCLR interpreter lays struct arguments out inline across 8-byte slots — `TokenToSlotCount` returns `max((size + 7) / 8, 1)` for an `S<N>` token. A wrong `N` misaligns the interpreter frame. Mono's generator needs none of this: its alphabet has no `S`, and it encodes every struct as a pointer. ## The change crossgen2 gains `--generate-portable-callhelpers <dir>`, which writes the three C++ call-helper files directly. It sets up its type system as for a real wasm compilation, scans the input assemblies and emits — no JIT, no R2R image. The option requires `--targetarch wasm` with `--targetos browser|wasi`. The CoreCLR half of the MSBuild task is deleted rather than adapted: `ManagedToNativeGenerator`, `PInvokeCollector`, `PInvokeTableGenerator`, `SignatureMapper`, `InternalCallSignatureCollector`, `InterpToNativeGenerator`. `_CoreCLRGenerateManagedToNative` keeps its name and position in the target graph; its final step changes from `<UsingTask>` to `<Exec>`. The regeneration scripts move next to their output under `src/coreclr/vm/wasm/` and drive `generate-coreclr-helpers.proj`. Mono's generator is untouched. **−2269 lines under `src/tasks`, +1541 under `ILCompiler.ReadyToRun/PortableCallHelpers`.** A move, not an addition: the second implementation of wasm ABI lowering is gone, and the one that remains is the one the JIT interface itself calls. Sizes are computed, not enumerated. The only change to `WasmLowering` is widening `WasmValueTypeToSigChar` from `private` to `internal`. ### Naming Portable entry points exist for any platform that cannot generate code at run time; wasm is the only one today. Per [review feedback](dotnet#131877) nothing in this functionality is named after wasm. Symbols shared by the runtime and the generated tables were renamed on both sides at once: | before | after | |---|---| | `StringToWasmSigThunk` | `StringToPortableSigThunk` | | `g_wasmThunks[Count]` | `g_portableCallHelperThunks[Count]` | | `wasm_ret_S<n>` | `portable_callhelper_ret_S<n>` | What keeps wasm in its name is what is genuinely about wasm: the ABI in `WasmLowering`, the `--targetos browser|wasi` requirement, and the wasm-specific corerun the runtime tests link. ### Finding crossgen2 Three paths, tried in order: - **Override** — `$(PortableCallHelpersGeneratorPath)`, which must name a crossgen2 executable. - **In repo** — `$(Crossgen2InBuildDir)`; crossgen2 is built unconditionally by the `clr` subset. - **Out of repo** — the `wasm-tools` workload declares the existing `Microsoft.NETCore.App.Crossgen2.<host-rid>` pack, whose `Sdk/Sdk.props` defines `$(Crossgen2ToolPath)`. ~12.5 MB. The SDK resolves this pack only when `PublishReadyToRun` is set, which wasm CoreCLR apps never set — hence the workload. dotnet/sdk#56119 proposes acquiring it directly instead, which would let the workload entry go. If none of the three resolve, the targets error rather than passing an empty path down. The pack is named for the machine that *runs* crossgen2, not the target: generation never loads the JIT, so a host-targeting crossgen2 answers wasm ABI questions correctly. The workload-testing legs do not set `$(BuildHostTools)`, so nothing produced a crossgen2 pack for their local package feed. (The perf browser-wasm leg does produce one, but only because it opts in — dotnet#133143.) `Microsoft.NETCore.App.Crossgen2.Host.sfxproj` pins the RID to the build host, and is now built by the CoreCLR browser-wasm leg behind `$(BuildCrossgen2HostPackForWorkloadTesting)`, guarded on `$(BuildHostTools)` being unset so the two paths can never emit the same package id twice. The official build is untouched — it already publishes this pack from the host platform legs. ## Behaviour changes **`WASM0066` is removed.** The old task warned for every `DllImport` whose module did not resolve to a linked-in native library — a CoreCLR-only divergence that fires on ordinary cross-platform code never executed on wasm (dotnet#131874 reports ten from SkiaSharp alone on a shipped Preview 7 SDK). In-tree it had already accumulated two `NoWarn` suppressions and a `WarnOnUnresolvedPInvokeModules=false`; all three go, along with the `--no-warn-unresolved-directpinvoke` opt-out that existed only to silence it. An unresolved module is not knowably wrong at build time: `callhelpers_pinvoke_override` returns `nullptr` on a miss, so a call that actually happens throws `DllNotFoundException` naming the module, as on every other platform. Dropping a warning is strictly loosening. **`WASM0065` is added, as a message.** Per module, when it declares P/Invokes without `[assembly: DisableRuntimeMarshalling]`, since the generated helpers assume signatures cross unmarshalled. A message rather than a warning: it reports something the app author often cannot fix, and as a warning it would fail `-warnaserror` builds. Four fire across the 181 framework assemblies. **Exported callbacks with an ambiguous name are rejected.** An export wrapper resolves its `MethodDesc` through `LookupUnmanagedCallersOnlyMethodByName`, which takes the first `[UnmanagedCallersOnly]` method of matching name and compares no signature — so two exported overloads resolve to the same method and one wrapper calls it with the wrong arguments. Everything the generator controls carries the arity, so the existing duplicate-key and duplicate-symbol checks both pass. Generation now fails instead, naming both signatures. Only exports: a non-exported callback is found by the arity-aware key and never reaches the name lookup. ## Known limitations - **wasi has no out-of-repo acquisition path.** `wasi-experimental` extends `microsoft-net-runtime-mono-tooling`, not `wasm-tools`, so it picks up no crossgen2 pack; the targets error explicitly there. Browser is the shipping wasm/CoreCLR target. - **Reverse thunks allocate one `int64_t` slot per managed parameter**, while a by-value struct argument occupies `ceil(size/8)` interpreter slots. No `[UnmanagedCallersOnly]` callback in CoreLib or the libraries takes a by-value struct, so nothing exercises this. The old generator rejected such callbacks with `WASM0067`; this one accepts them, so user code would get a bad thunk rather than a diagnostic. - **`'V'` (v128) has no case in the C++ emission helpers.** Pre-existing; fails loudly. - **Multi-slot types (`Int128`, `Vector256`, …) are rejected at the thunk emitter** rather than at the interop boundary, so the diagnostic differs from the old `WASM0068`. Still a clean `crossgen2 : error :` with exit 1. No such P/Invoke exists today. - Does not re-enable the tests disabled in dotnet#131811 (dotnet#133187), and does not address gaps #3–#7 there. ## Verification - **Regeneration reproduces the committed helpers byte for byte**, apart from the rename above, with zero `WASM0001`/`WASM0060`/`WASM0061`/`WASM0062` warnings across a full CoreLib+libraries scan. (The checked-in P/Invoke table is already slightly stale against `main` independently of this PR; that drift is left alone.) - `WasmArgumentLayoutTests` goes from 17 to 22 test methods. The two covering the rejection above were checked against a disabled check, so they test it rather than agree with it. - `clr+libs` builds clean for `browser` and `wasi`; `WasmAppBuilder` still builds for both `net11.0` and `net472`. - Both flavors build end to end from the in-tree samples, with per-architecture native payloads, a non-PE file and duplicate-culture satellites injected into the bundle. - The renamed runtime contract was checked by building: `libcoreclr_static.a` exports `g_portableCallHelperThunks` and no `g_wasmThunks`, and the browser sample links its generated tables against it. Contributes to dotnet#131811, closing blocking gap #1 and the struct half of gap #2: a 3-int and a 5-double struct in `[UnmanagedFunctionPointer]` signatures now resolve to `vS12` / `S12i` / `vS40i`, where all three previously threw `NotSupportedException`. > [!NOTE] > This pull request description was drafted with the help of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com> Copilot-Session: f6d6e5a4-5b25-4198-b42d-d5b2dc781f47

Automated bump of chrome version

3b6df50

github-actions Bot added arch-wasm area-infrastructure-mono labels Sep 10, 2023

eduardo-vp pushed a commit that referenced this pull request Feb 8, 2024

Late cast expansion: more improvements #2 (dotnet#97480)

34bf05f

Navigation Menu

[wasm] Bump chrome for testing - linux: 116.0.5845.179, windows: 116.0.5845.180 - #2

[wasm] Bump chrome for testing - linux: 116.0.5845.179, windows: 116.0.5845.180#2
github-actions[bot] wants to merge 1 commit into
mainfrom
update-chrome-version-6134047099

github-actions Bot commented Sep 10, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

github-actions Bot commented Sep 10, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants