Entering debugger: Cannot create Swift scratch context (couldn't create a ClangImporter)

Question

idcrook OP

Created Jan ’21

Replies 6

Boosts 0

Views 4.9k

Participants 7

similiar to

which do not resolve this issue that I am encountering

Description of problem

I am seeing an error which prevents using lldb debugger on Swift code/projects. It is seen on any Swift or SwiftUI project that I've tried. This is the error displayed in lldb console when first breakpoint is encountered:

Code Block Cannot create Swift scratch context (couldn't create a ClangImporter)(lldb)

Xcode Version 12.3 (12C33)
macOS Big Sur
- Intel
- M1

Troubleshooting

I originally thought this was also working on an Intel Mac running Big Sur/Xcode 12.3, but was mistaken. Using my customized shell environment on the following setups, I encounter the same couldn't create a ClangImporter.

M1 Mac mini, main account (an "Admin" account)
same M1 Mac mini, new "dev" account (an "Admin" account)
Intel MBP, main account

They are all using an Intel Homebrew install, and my customized shell environment if that provides a clue?

I captured some lldb debugging info by putting expr types in ~/.lldbinit but the outputs were basically identical (when discounting scratch file paaths and memory addresses) compared to the "working clean" account log (described below)

Code Block log enable -f /tmp/lldb-log.txt lldb expr types

works in a "clean" user account

I created a new, uncustomized "Standard" testuser account on the M1 Mac mini, and launched the same system Xcode.app. There was no longer this error message, and was able to inspect variables at a swift program breakpoint in Swift context, including po symbol.

Impact

Effectively this makes the debugger in Swift on Xcode projects on my systems essentially unable to inspect Swift contexts' state.

Answered by idcrook in 658667022

After hours and days of attempting to narrow down the cause, after I remove all zsh customizations (in dotfiles) on an account, the LLDB Swift debugging finally works again. Swift structure state can be inspected, and po symbol works.

(the lldb startup error Cannot create Swift scratch context (couldn't create a ClangImporter) is gone too)

I haven't isolated the specific root cause of why this is, but that is the general case.

Boost

Answer 1

idcrook OP

Jan ’21

Accepted Answer

After hours and days of attempting to narrow down the cause, after I remove all zsh customizations (in dotfiles) on an account, the LLDB Swift debugging finally works again. Swift structure state can be inspected, and po symbol works.

(the lldb startup error Cannot create Swift scratch context (couldn't create a ClangImporter) is gone too)

I haven't isolated the specific root cause of why this is, but that is the general case.

1

Answer 2

idcrook OP

Jan ’21

I isolated it finally to a very very old (mid-1990s) csh-backed shell utility that was being used to add PATH components.

I replaced its functionality with ZSH's built-in way to do this, and everything seems to be working as it should be.

It's not completely clear what exactly was breaking the LLDB invocation by Xcode, but I am fine with modified way.

Code Block shell# put at end of path
path+=/new/path
# put at front of path
path=(/first/path $path)

1

Answer 3

JChen37 OP

Jan ’21

Hey @idcrook ive tried removing all my .zsh files in my home directory but still getting the same issue. Where exactly did you find your csh-backed shell utility? was that in your homre directory?

0

Answer 4

JChen37 OP

Jan ’21

@idcrook thanks for your post! I ended up changing my shell from zsh to bash and the debugger started to work again.

2

Answer 5

SimonKravis OP

May ’22

This problem appeared during development in a new account which was created after the problem appeared in the original development account without any changes to the shell, which is bash (both default and running as shown by ps -o comm= $$ and echo $SHELL)

0

Answer 6

PGHM OP

Jan ’23

I managed to get similar problem fixed, in my case the root cause was a library that was distributed in binary form and had somehow managed to put extra framework searchpaths in the library configuration. The search paths were relative to the developers computer home folder so they did not work properly. There were also some extra flags that were used for their internal debugging.

I managed to find the root cause by using swift-healthcheck on the debugger and comparing it to a version that did not have this problem.

There is not too much information about the swift-healthcheck available currently, but you can just type it in the debugger and see the output. Debug Swift with LLDB (WWDC 2022) session had some information.

1