Segmentation fault when running in emulated amd64 container on M1 Mac

[anthony-c-martin]

Description

This is a stripped down repro of Azure/bicep#10245, which has been reported by a number of our users trying to use a VSCode extension in an amd64 emulated devcontainer image.

It seems like the usage of Regex.Match is causing a segmentation fault when run in an amd64 image emulated on an M1 Mac.

Reproduction Steps

Open a bash prompt in an amd64 Docker container on an M1 Mac:

docker container run -it --platform=linux/amd64 mcr.microsoft.com/vscode/devcontainers/python:0-3.10-bullseye bash

Run the following to repro the issue:

wget https://dot.net/v1/dotnet-install.sh -O dotnet-install.sh
chmod +x ./dotnet-install.sh
./dotnet-install.sh --channel 7.0

git clone https://github.com/anthony-c-martin/dotnet-regex-rosetta-repro.git
cd dotnet-regex-rosetta-repro

/root/.dotnet/dotnet run

Expected behavior

The console app should log "Success!"

Actual behavior

The following is logged:

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

This is a stripped down repro of Azure/bicep#10245, which has been reported by a number of our users trying to use a VSCode extension in an amd64 emulated devcontainer image.

It seems like the usage of Regex.Match is causing a segmentation fault when run in an amd64 image emulated on an M1 Mac.

Reproduction Steps

Open a bash prompt in an amd64 Docker container on an M1 Mac:

docker container run -it --platform=linux/amd64 mcr.microsoft.com/vscode/devcontainers/python:0-3.10-bullseye bash

Run the following to repro the issue:

wget https://dot.net/v1/dotnet-install.sh -O dotnet-install.sh
chmod +x ./dotnet-install.sh
./dotnet-install.sh --channel 7.0

git clone https://github.com/anthony-c-martin/dotnet-regex-rosetta-repro.git
cd dotnet-regex-rosetta-repro

/root/.dotnet/dotnet run

Expected behavior

The console app should log "Success!"

Actual behavior

The following is logged:

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	anthony-c-martin
Assignees:	-
Labels:	area-System.Text.RegularExpressions
Milestone:	-

[vcsjones]

Setting DOTNET_EnableWriteXorExecute=0 fixes it:

DOTNET_EnableWriteXorExecute=0 /root/.dotnet/dotnet run
Success!

But I don't believe that is a stable work around. I am assuming this has something to do with double memory mapping.

If I am not mistaken, Docker uses QEMU emulation to run x86_64 on Apple Silicon, and .NET is not supported in QEMU.

[sergiorru]

@vcsjones

Since docker version 4.25.0 the QEMU is not the default emulation used anymore, it's Rosetta2.

Using the workaround as you proposed (export DOTNET_EnableWriteXorExecute=0) worked for this sample.

Thank you!

[stephentoub]

and .NET is not supported in QEMU.

Yup, this was discussed here:
#78340 (comment)

[anthony-c-martin]

Thanks! I'll make sure we document that qemu is unsupported. It would be amazing if there's a way to detect this and warn the user (not sure how feasible however).

To make sure I'm understanding correctly, the following are both required to support the scenario:

1. Use Rosetta2 emulation (simplest option is to just upgrade to Docker desktop v4.25.0 or higher)
2. Set the DOTNET_EnableWriteXorExecute env var to 0

@stephentoub do you happen to have an explanation for why the env var is required? Is this to work around an issue in Rosetta2? Are you aware of any recommended approaches to detecting an emulated environment?

[mregen]

as a sidenote, I use the docker build in github actions here for .NET 8 armv8 docker build and the build issue was fixed by applying

2: Set the 'DOTNET_EnableWriteXorExecute' env var to 0

in the Dockerfile

[steveisok]

re: why DOTNET_EnableWriteXorExecute=0 is required... I have to guess that the running container can't tell Rosetta is involved. From #70912, it appears double mapping isn't supported when running in Rosetta. If we can't tell, then we'll take the x64 default.

@jkotas does that sound right?

[vcsjones]

Note that this will be better in .NET 9: #102509

[jkotas]

Fixed by #102509