Swift breakpoints do not work with bazel sandboxing

[robbertvanginkel]

I generated a simple ios project with tulsi. I have a single main.swift file, and put a breakpoint in it. The debugger doesn't stop on this breakpoint, but the debugger was attached correctly because I could pause the app.

The dsym patcher is invoked with:

['/Users/robbertvanginkel/test/.tulsi/Utils/post_processor', '-d', '-v', '/Users/robbertvanginkel/Library/Developer/Xcode/DerivedData/App-fbkovlbzufvrizfxxpeuwgmqyffl/Build/Products/Debug-iphonesimulator/App.app.dSYM/Contents/Resources/DWARF/App', '/private/var/tmp/_bazel_robbertvanginkel/44f6264deb03d7ebd91b8dc407ba5747/execroot/__main__', '/Users/robbertvanginkel/test/']

Inspecting the dsym, it looks like bazel is using a different sandboxed path for swift by default:

$ dwarfdump /Users/robbertvanginkel/Library/Developer/Xcode/DerivedData/App-fbkovlbzufvrizfxxpeuwgmqyffl/Build/Products/Debug-iphonesimulator/App.app.dSYM | less
...
AT_name( "/private/var/tmp/_bazel_robbertvanginkel/44f6264deb03d7ebd91b8dc407ba5747/bazel-sandbox/be16c42f-4eac-4d28-b9b2-5abccdd93664-20/execroot/__main__/main.swift" )
...

I added the flag --strategy=SwiftCompile=standalone to the compile options, and then the patcher seems to correctly replace the path, which makes the breakpoint work.

[lswith]

I've got the same problem using the latest version of bazel.

[lswith]

bump. Any update on this @dmishe ?

[dmishe]

Sorry, no updates so far.

[rismay]

Are there any plans to support debugging in Xcode for Swift and Objc?

[DavidGoldman]

ObjC debugging should work with sandboxing but Swift debugging currently does not due to Swift limitations which may or may not be fixed in Swift 5. For now you can add --strategy=SwiftCompile=standalone to your build flags to help workaround this issue.

[enrique-money]

Have anyone figure this out? I been using bazel 2.0 and latest tulsi. Current project is ios (swift and objc)
I tried adding the --strategy=SwiftCompile=standalone and --apple_generate_dsym into 'build' options in the tulsi shared options. Tried starting fresh with bazel clean --expunge
and breakpoint still does not work.

[tinder-maxwellelliott]

I got this working with Bazel 2.2.0 and Tulsi 0.20200219.88 by adding the two follow flags:

--strategy=SwiftCompile=standalone
--apple_generate_dsym

Into build options

[DavidGoldman]

AFAIK you should just need --strategy=SwiftCompile=standalone, it should work without dSYMs. Please attach a small example project to reproduce if you're still seeing this so I can look into it.

[tinder-maxwellelliott]

Oddly enough I removed all my swift other compile flags and Tulsi breakpoints worked again, not sure what happened there

[tinder-maxwellelliott]

Oddly enough I can see this flag on by default on Tulsi 0.20200219.88.

https://gist.github.com/tinder-maxwellelliott/ee477ca31247225138e1c7e9678dd046

Now it appears like the debugger can stop working and then start working again

[DavidGoldman]

Hmm, Tulsi does use an lldbinit file which is created upon the first build. I think after that point you might need to re-open Xcode and re-add your breakpoints. Are you still seeing breakpoints intermittently break?

[tinder-maxwellelliott]

They are looking stable again

[acecilia]

I coudnt get breakpoints to work in a swift+objc project with the recommended approach. I have used --strategy=SwiftCompile=standalone and --strategy=SwiftCompile=local without luck.

I could verify that the option was being picked up because I could seeing in the build logs:

Showing All Messages
INFO: Reading rc options for 'build' from .../.bazelrc:
  'build' options: --verbose_failures --test_output=errors --strategy=SwiftCompile=standalone

Finally I got it working by also adding --apple_generate_dsym

[keith]

Thanks for submitting this issue but this tool is being deprecated. Please checkout rules_xcodeproj for a more complete and maintained Xcode integration.