Skip to content

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

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
update-chrome-version-6134002264
Open

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

Conversation

@github-actions
Copy link
Copy Markdown

No description provided.

a74nh pushed a commit that referenced this pull request May 17, 2024
…#102133)

This generalizes the indir reordering optimization (that currently only
triggers for loads) to kick in for GT_STOREIND nodes.

The main complication with doing this is the fact that the data node of
the second indirection needs its own reordering with the previous
indirection. The existing logic works by reordering all nodes between
the first and second indirection that are unrelated to the second
indirection's computation to happen after it. Once that is done we know
that there are no uses of the first indirection's result between it and
the second indirection, so after doing the necessary interference checks
we can safely move the previous indirection to happen after the data
node of the second indirection.

Example:
```csharp
class Body { public double x, y, z, vx, vy, vz, mass; }

static void Advance(double dt, Body[] bodies)
{
    foreach (Body b in bodies)
    {
        b.x += dt * b.vx;
        b.y += dt * b.vy;
        b.z += dt * b.vz;
    }
}
```

Diff:
```diff
@@ -1,18 +1,17 @@
-G_M55007_IG04:  ;; offset=0x001C
+G_M55007_IG04:  ;; offset=0x0020
             ldr     x3, [x0, w1, UXTW #3]
             ldp     d16, d17, [x3, #0x08]
             ldp     d18, d19, [x3, #0x20]
             fmul    d18, d0, d18
             fadd    d16, d16, d18
-            str     d16, [x3, #0x08]
-            fmul    d16, d0, d19
-            fadd    d16, d17, d16
-            str     d16, [x3, #0x10]
+            fmul    d18, d0, d19
+            fadd    d17, d17, d18
+            stp     d16, d17, [x3, #0x08]
             ldr     d16, [x3, #0x18]
             ldr     d17, [x3, #0x30]
             fmul    d17, d0, d17
             fadd    d16, d16, d17
             str     d16, [x3, #0x18]
             add     w1, w1, #1
             cmp     w2, w1
             bgt     G_M55007_IG04
```
a74nh pushed a commit that referenced this pull request Sep 9, 2024
* 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)
a74nh pushed a commit that referenced this pull request Dec 1, 2025
Currently, offsets are incorrectly treated as indices which is
leading to incorrect code being emitted.

e.g., `ScatterWithByteOffsets<long>` emits
`ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]`
instead of,
`ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`
a74nh pushed a commit that referenced this pull request May 15, 2026
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants