Attach to process .net core azure function runtime

Elements Fire
22

I have the arm64 version of .net core installed

23

That still gives me the same error

~> Attached to dotnet.
~> The process failed to start with the following error: System.Exception: Could not load .the NET Core dbgshim library at /usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.3/libdbgshim.dylib. Error: 
~>   at RemObjects.Oxygene.CoreDebugEngine.CLR.DotNetCorUtilities.LoadLibrary (System.String s) [0x0005c] in <9cf90225475440668b0ddc0c5a883ada>:0 
~>   at RemObjects.Oxygene.CoreDebugEngine.CLR.DotNetCorUtilities.GetInfo (System.String aPath) [0x00044] in <9cf90225475440668b0ddc0c5a883ada>:0 
~>   at RemObjects.Oxygene.CoreDebugEngine.CLR.DotNetCorUtilities.AttachProcess (System.String aDotNetPath, System.UInt32 pPid, System.Action`2[T1,T2] aCallback) [0x00014] in <9cf90225475440668b0ddc0c5a883ada>:0 
~>   at RemObjects.Oxygene.CoreDebugEngine.CLR.CLRDebugEngine.Start () [0x00263] in <9cf90225475440668b0ddc0c5a883ada>:0 
~>   at a.a (System.String[] a) [0x004c8] in <888b33318f3f4a06b95e2e72f4e7d3a0>:0
24

That’s not the same error.

Does /usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.3/libdbgshim.dylib exist? what does

# file /usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.3/libdbgshim.dylib

emit as architecture for that file?

25

I get this output

/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.3/libdbgshim.dylib: Mach-O 64-bit dynamically linked shared library arm64
26

Was your output also from an m1 mac with arm64 .net core ?

27

ok, so far so good.

Yes.

28

Can you open the Activity Window before attaching and then post the log output from there? just to be sure, i case there is anything helpful in there.

29

I get this in the activity window

platformsPopup.itemAtIndex(i).title Island (Native Debugger)
platformsPopup.itemAtIndex(i).title Echoes (.NET Core Debugger)
parameters {
  "AttachToPID": 14763,
  "MonoExePathOverride": "/Applications/Fire.app/Contents/Resources/Mono/bin/mono-sgen",
  "Mode": "Echoes",
  "SubMode": ".NETCore",
  "DebuggerExePathOverride": "/Applications/Fire.app/Contents/Resources/RemObjects.Elements.Debugger.exe",
  "NetCore": true,
  "Architecture": "x86_64",
  "CrossBox": "Local"
}

Isn’t the architecture wrong ?

30

Hmm, i doubt that matters. The fix that mattered (for me) was the “MonoExePathOverride”: “/Applications/Fire.app/Contents/Resources/Mono/bin/mono-sgen”. The embedded mono supports arm64, but the external ones still don’t.

THAT said, i got a clean error before this fix that explicitly said “dylib is arm but i need x86_64”, which you don’t.

Stupid question: you are running Fire natively as arm, right? You haven’t manually toggled it to run as x86_64, in Finder?

31

I dont think I have, Im not sure where the toggle is :slight_smile:

If I do get info on Fire it says Kind : Application (Intel), something like music says kind: application (universal)

32

Hmmmm.

damn, i know what’s happening. you have a non-“setups” build from CI. i think those don’t build both architectures, only local one (and the build machine is Intel). I apologize for that, i did not think of that at all. Can you retest with today’s official build (which should be building in the next hour or so)?

FWIW, this doesn’t matter for .NET COre, but would for attaching natively, and i just fixed that to properly detect the process architecture for Rosetta vs native, so with vNext you’ll see “arm64” here. But it doesnt matter for how the .NET Core attach works, it ignores this info.

33

Thanks it works now. Will the non setup builds continue to be intel only ?

1 Like
34

I’ll see if I can change that; it’s mainly to keep build times down, but I don’t think it would make a big difference in the grand scheme of things…