Closed DenisRumyantsev closed 3 years ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
There is no way that OSPlatform..ctor(System.String)
should AV. The process state is probably already corrupted. That is then causing a second AV in FilterCustomAttributeRecord.
some ideas
@AaronRobinsonMSFT any other thoughts? Nominally this type is yours, although the connection to your code (and indeed this type) is tenuous
@danmoseley I agree with your analysis here – at least conceptually. My one question would be regarding CrossGen, Linker, or any post-build processing impact. I could imagine a case where IL was removed in some scenarios and this causes a cascade of failures for Linux on a non-Linux platform (i.e., macOS). Other than the comment on procdump – which is Windows only I believe – I think your ideas are the most appropriate.
Oops yes not Windows. I'd be interested to know if there's a tool similar to procdump on Mac or Linux.
@danmoseley I believe the equivalent on macOS would be dtruss
. On other unix platforms I would typically start with strace
.
that's procmon ? I meant procdump. Essentially, a tool to capture dumps based on unhandled exceptions, events, timers etc.
@danmoseley Doh. Sorry about that. I honestly don't know if there is a ProcDump equivalent. Perhaps @janvorli knows of something.
On Linux, there is a gcore tool, but all it can do is to take a dump of a running process when started. gdb can be used to catch AV and take a dump.
On macOS, you have two options:
process save-core
LLDB command). It looks like the error above happens early during startup, so running it under lldb would be easy.To enable dumps, it is needed to:
wheel
group)ulimit -c unlimited
from the shell where the application will be launched from (or from the same script before launching the application)bash
shell and not the now default zsh
for some reason.@AaronRobinsonMSFT I run a process under lldb, and after the error occurred, made a core dump using process save-core
lldb command. I sent you a link to the core dump in Microsoft Teams, could you please take a look?
@DenisRumyantsev I did take a look and have responded on Teams. I am quoting the response below:
I loaded the shared coredump file. Unfortunately it wasn't done with the .NET createdump binary. We found some issues regardless and recorded them at https://github.com/dotnet/symstore/issues/289. I will set aside some time today to debug this but I'm not sure what is going on here and the stack doesn't really make a lot of sense. Also, this is a preview version of the macOS so it is entirely possible there is a bug here that we are sensitive to. It is also possible this will require a servicing fix for .NET Core 3.1 to service so the problem here could be an early warning of that. The short answer is there are limited details here and I have few abilities to actually root cause this issue with the current environment. I assume this is an early pass on a preview OS and not a production blocking issue though. Please correct me if I am wrong. Using createdump might actually help here - https://docs.microsoft.com/dotnet/core/diagnostics/debug-linux-dumps.
@DenisRumyantsev can you confirm that/which of these work?
@danmoseley I am currently building and testing agents with different dotnet runtime versions and checking if there is this issue on macOS 12 for them. I will provide you the results when I'm done with this.
@danmoseley @AaronRobinsonMSFT I have upgraded the dotnet version to the latest compatible one, with which our agent successfully passes the build for macOS (dotnet runtime 3.1.15 version instead of 3.1.0 which we are currently using), and the error is no longer reproduced on macOS 12 Beta. It looks like this issue has already been fixed and we need to upgrade the agent to a higher version of dotnet. So I'm closing this issue.
@DenisRumyantsev thanks for the update. great.
BTW, 3.1.15 is out of date. The latest version is 3.1.18 https://dotnet.microsoft.com/download/dotnet/3.1
Description
Hi, I am currently working on the issue which Azure DevOps customers face trying to configure ADO agent on Mac devices running on
macOS 12 Monterey Beta 3
platform.Here are steps to reproduce the issue:
macOS 12 Monterey Beta 3
(build version: 21A5284e)bin
directory of an agent):./Agent.Listener configure --unattended --replace --url "https://<organization_name>.visualstudio.com" --pool "<pool_name>" --agent "<agent_name>" --work "_work" --runasservice --auth "PAT" --token "<actual_token>"
The error message which customers get after running the command mentioned above:
The main idea is that ADO agent uses
dotnet 3.1
and is run onmacOS 12 Monterey Beta 3
platform, and the error occurs here when trying to executeRuntimeInformation.IsOSPlatform(OSPlatform.Linux)
, or more detailed:so please see at the string
at System.Runtime.InteropServices.OSPlatform.get_Linux()
and above it in the error logs.