I am (unfortunately) on a Macintosh. A program is segfaulting, and I need to run in a debugger to find out why. I run lldb executable-name, and then "run". It prints:
error: the platform is not currently connected.
I do not know what this means. Googling for this error message turns up various things involving iOS and XCode, but I am not using either of those things, I am using lldb at the command line.
@mcc Hey... is... is your shell x86_64 (Rosetta) for some reason?
I can repro your failure mode if I do this:
(I start in my normal terminal)
$ arch
arm64
$ arch -x86_64 zsh
$ arch
i386
$ lldb ./bin/Debug/net8.0/abcd
(lldb) r
error: the platform is not currently connected
so um... maybe try this:
$ arch -arm64 zsh
$ lldb ...
(lldb) r
@lambdageek The shell. Hm. I don't know how to answer that question so maybe it is. The test machine will be unavailable for a few hours so I'm going to test that afterward. Thank you!
@mcc also try running dotnet --info
and see if there's anything suspicious in the "Runtime Environment" section of the output or the "Other Architectures Found" section (if you have one)
Also
$ file which dotnet
/usr/local/share/dotnet/dotnet: Mach-O 64-bit executable arm64
Note: Several people recommended running xcodebuild -license accept before running lldb, I tried this and it made no difference. Same error message. @dylan@onyxraven
Something I did not mention before: The application I was trying to attach to was the dotnet executable. (The crash is occurring inside a p/invoke call.)
I tried making a tiny a.out, and lldb could attach to that fine. The problem is dotnet. I can imagine that being an "odd" executable in various ways (although file insists it's ARM64). I wonder if there's some special process for running C# programs in a C debugger on Mac.
@mcc the "dotnet" executable does a bunch of different jobs. assuming you just want to do something like:
lldb dotnet -- ./bin/Debug/..../MyApp.dll
that should work just fine.
I would actually start by doing something like:
mkdir MyApp && cd MyApp
dotnet new console
dotnet run # should print "Hello World"
lldb dotnet -- ./bin/Debug/net8.0/MyApp.dll
and just verify that LLDB does a reasonable thing.
@mcc if lldb just refuses to attach for some reason, sometimes it helps to ad-hoc codesign the affected binary
sudo codesign -s - -f /usr/local/share/dotnet
(note, I would reinstall dotnet when you're done with the ad-hoc binary. I'm not sure if there's any issue running an ad-hoc signed dotnet, but it seems better to get back to a clean slate)
@lambdageek Thanks for this information. At the moment, I am running dotnet in lldb with no arguments, just to test (eg i'd expect it to print a --help or something). It's failing, and based on the output of platform select host I believe it is somehow misdetecting dotnet as x86_64. As noted the error I am getting with dotnet, I do not get when I build a random a.out.
DEEPLY CURSED TWIST ENDING: What it turned out was happening here is that this was all being run in a copy of "fish" (the shell) that was, at some point immediately after this laptop was purchased, installed as an x86_64 executable. On ARM mac, x86_64 executables report they're on a x86_64 machine, and when they invoke fat executables they'll preferentially invoke the x86_64 slice. So x64 "fish" invoked an x64 profile lldb, which then freaked out trying to attach to the arm64 dotnet executable
@mcc Amazing. I will notch another mark into the "always ask the user to uninstall fish before proceeding with support" stick. This is definitely the most unusual reason I have yet seen to ban fish though
@glyph@mcc I wonder how general that is for other shells as well? It's pretty surprising to me that the architecture that a shell was written against should constrain the architecture of any programs launched by that shell, if I'm understanding upthread correctly?
@glyph@mcc (Saying this as someone whose primary shell is nushell, and as someone who has had to run PowerShell as a primary shell on macOS before. For reasons.)
@xgranade@mcc It's not really a feature of the shell, it's a feature of Rosetta2. If you are in x86_64-compatibility world, then from the perspective of the executing program, the computer "is" an Intel machine for most purposes. This is to ensure that if you have a bundle with x86_64 helper programs and arm64 helper programs, that when you test it in x86_64 mode it lets you exercise the whole code path, rather than switching back to arm builds any time you call exec().
@xgranade@mcc Yeah. Accidentally having a wrong-architecture shell or terminal installed leads to a whole cascade of interactions. I think if it's the wrong build of iTerm it's even weirder, because of the ways it might be apparently inconsistent from the user perspective, unless you're manually inspecting every path in every settings field
@xgranade@mcc The way that Apple thinks about this stuff is that if you're in this particular zone, you did it to yourself. You are supposed to be able to avoid the footgun by doing things the "right" way, which is to say, developing apps exclusively within Xcode, not doing esoteric UNIX-ish CLI stuff. (Of course this fiction begins to fall apart when you look at stuff like their first-party Game Porting Toolkit which is literally just a homebrew formula, or any actual large apps.)
@xgranade@glyph My understanding from what I've seen in the last 24 hours is it's not related to shells and is built in behavior of exec() or something. Apparently if you accidentally install, for example, an x86_64 version of iTerm2, then that's gonna launch an x86_64 bash (or fish or whatever) even if you have an arm64 bash available.
However: It gets worse! How did it come to be the x86_64 "fish" got installed? Well, that's simple: "fish" was installed by homebrew, and the copy of homebrew on the laptop was somehow x86_64. Every homebrew-installed program on the system was x86_64. Which means some unknown number of software programs built on this system are also x86_64, because although clang was not homebrew and was vended by XCode, the cmake was homebrew and therefore was x86_64.
@mcc This can easily happen if the user did a Migration Assistant setup on their shiny new Apple Silicon machine, or restored from a Time Machine backup from an Intel machine. I was lucky to have developed a "always do a fresh homebrew reinstall" tic long before Apple Silicon but this is a good thing to remember to check!
@glyph@mcc yeah, I recommend always setting up new Macs from scratch. Even without silicon changes, I’ve had so many problems like this with cruft leftover from older OS versions…
@swiftcoder@mcc I used to be absolutely militant about this advice, but the big problems used to be junk left over that actually modified the system in /usr/ or whatever, but nowadays SIP prevents those sorts of modifications and a post-install clean-up of /Library and /usr/local can reliably get you to a functionally "pristine" state. But I did do a manual re-install when I got my M1 machine, and haven't gotten a new mac since :)
Now, it turns out that— this is also a little cursed, but is a good decision— if you install a x86_64 copy of homebrew it installs into /usr/local, whereas if you install an arm64 copy of homebrew it installs into /opt/homebrew (where, arguably, it should have been to begin with. "fink" was right!). This means you can install x86_64 and arm64 homebrew on the same computer. So now this computer is "fixed" insofar as it has an arm64 homebrew containing fish and cmake, and an x86_64 with… stuff
Which means that we can proceed with today's tasks (such as running lldb on dotnet) without problems, but also the laptop's owner has a really miserable day looming at some point in her future when she's going to have to clear out the x86_64 homebrew and install all those packages onto arm64, which is going to mean killing her Python, which will mean breaking stuff throughout the system that hardcoded a path to the now-gone x86_64 cmake, Python, or whatever else.
Thanks to @misty and @lambdageek for helping us figure out this weird situatoin
People often reply to my cursed computer problems with "ha ha, mcc, you always wind up running software in the weirdest configurations!" or whatever. I want to stress this was not my laptop and I had nothing to do with it. This one is all on Apple
@mcc This is purely a guess, but every year or so I have to go through a dance where I download and install/update XCode and XCode's command line tools, and agree to Apple's EULA for them. And like you, I never use XCode, and never will.
I have no idea about the segfault problem, but this smells like the XCode Command Line Tools BS.
Add comment