Debugger not working when running a unit tests target

[BalestraPatrick]

Possibly related to #12 but there was no clear resolution, so I'm opening a new issue.

I've noticed that in both Swift-only and Objective-C only projects, setting a breakpoint in some code in a swift_library or objc_library and running a unit test target that depends on it, LLDB doesn't stop on breakpoints. Generating a project with a ios_application and the same flags instead makes LLDB stop on the breakpoint.

My BUILD file is pretty standard (simplified it a bit):

load("@build_bazel_rules_swift//swift:swift.bzl", "swift_library")
load("@build_bazel_rules_apple//apple:ios.bzl", "ios_unit_test", "ios_application")

swift_library(
    name = "Library",
    srcs = glob(["Library/**/*.swift"]),
    module_name = "Library",
    visibility = ["//visibility:public"],
)

swift_library(
    name = "LibraryTestLib",
    srcs = glob(["LibraryTests/**/*.swift"]),
    module_name = "LibraryTests",
    deps = [
        ":Library",
    ],
)

ios_unit_test(
    name = "LibraryTests",
    minimum_os_version = "10.0",
    deps = [":LibraryTestLib"],
)

Adding a ios_application that depends on :Library makes LLDB work instead when generating a Tulsi project with the --apple_generate_dsym flag.

Is this a known issue? Any possible workaround?

[DavidGoldman]

Interesting, what about if you don't use the --apple_generate_dsym flag? Can you attach your Xcode/Tulsi build logs when building the test target by itself? Can you run image list when attached with the debugger and see if it can find the dSYMs?

[tinder-maxwellelliott]

I am seeing the same exact issue. When passing --apple_generate_dsym I get breakpoint support in Applications but not in UnitTest targets

[DavidGoldman]

Hmm, I'm bit busy now but will look into this when I get a chance. If you can attach a minimal repro project that would be great.

[xpereta]

I'm having the same issue and trying to solve it I've come across this investigation notes of a similar issue. Maybe it can shed some light on what may be happening:

https://github.com/StevenEWright/tulsi_testbed

[StevenEWright]

Hey! Just chiming in here - this has been a long-running problem - the TL;DR summary of my recollection is that: sandboxing leads to file paths in the debug info of the binary that don't exist (they were the sandbox paths) - and that the strategy for mapping these sandbox paths to workspace paths doesn't work well because ~/.llvminit is only read/applied once per Xcode lifetime (after the first debug session).

The canonical suggestion from Bazel folks is to build with DSYMs - which works around the problem - but isn't a feasible approach for large applications.

I'm curious why the suggestion isn't, instead, "don't build with sandboxing for local debug"? I would think that would also work around the problem (with one obvious downside being it's possible to not realize you have a bazel target config issue (like missing header export or similar) until you actually try to build with sandbox enabled.

(I'm making lots of assumptions here about things being similar to how they were almost two years ago).

[DavidGoldman]

Missed that sandboxing was enabled. See https://github.com/bazelbuild/tulsi/issues/88#issuecomment-491118834, you either need dSYMs or to pass --strategy=ObjcLink=standalone and --strategy=CppLink=standalone to disable sandboxing for linking. We recommend the latter due to speed.

In the near future this should no longer be the case when we add crosstool support for -oso_prefix (see here), but we'll also need to change the working dir of lldb to get debugging working.

[StevenEWright]

Thank you @DavidGoldman ! (Good to hear from you!) Also, great to hear about the new -oso_prefix support!

I'm curious to hear if building with sandboxing disabled resolves your problem @BalestraPatrick - 🤞

[BalestraPatrick]

@StevenEWright For some reason, disabling sandboxing for linking doesn't fix it for me. I tried passing those two flags both via my .bazelrc or the Tulsi configuration, but the breakpoints don't get hit when running unit tests. I verified that the flags are passed in the log as well:

Running "/usr/local/bin/bazelisk build --verbose_failures --bes_outerr_buffer_size=0 --strategy=CppLink=standalone --strategy=ObjcLink=standalone --apple_platform_type=ios --cpu=ios_x86_64 --watchos_cpus=i386 --announce_rc '--override_repository=tulsi=/Users/patrickb/Library/Application Support/Tulsi/0.20200219.88/Bazel' --compilation_mode=dbg --define=apple.add_debugger_entitlement=1 --define=apple.propagate_embedded_extra_outputs=1 --define=apple.experimental.tree_artifact_outputs=1 --features=debug_prefix_map_pwd_is_dot --tool_tag=tulsi:bazel_build --build_event_json_file=/Users/patrickb/Project.xcodeproj/.tulsi/99744_build_events.json --noexperimental_build_event_json_file_path_conversion --aspects @tulsi//:tulsi/tulsi_aspects.bzl%tulsi_outputs_aspect --output_groups=tulsi_outputs,default //base/Project:Tests", patching output for workspace root at "/Users/patrickb/" with project path at "/Users/patrickb/".

[tinder-maxwellelliott]

@StevenEWright For some reason, disabling sandboxing for linking doesn't fix it for me. I tried passing those two flags both via my .bazelrc or the Tulsi configuration, but the breakpoints don't get hit when running unit tests. I verified that the flags are passed in the log as well:

Running "/usr/local/bin/bazelisk build --verbose_failures --bes_outerr_buffer_size=0 --strategy=CppLink=standalone --strategy=ObjcLink=standalone --apple_platform_type=ios --cpu=ios_x86_64 --watchos_cpus=i386 --announce_rc '--override_repository=tulsi=/Users/patrickb/Library/Application Support/Tulsi/0.20200219.88/Bazel' --compilation_mode=dbg --define=apple.add_debugger_entitlement=1 --define=apple.propagate_embedded_extra_outputs=1 --define=apple.experimental.tree_artifact_outputs=1 --features=debug_prefix_map_pwd_is_dot --tool_tag=tulsi:bazel_build --build_event_json_file=/Users/patrickb/Project.xcodeproj/.tulsi/99744_build_events.json --noexperimental_build_event_json_file_path_conversion --aspects @tulsi//:tulsi/tulsi_aspects.bzl%tulsi_outputs_aspect --output_groups=tulsi_outputs,default //base/Project:Tests", patching output for workspace root at "/Users/patrickb/" with project path at "/Users/patrickb/".

Did you ever get this working? This is concerning to see and I would like to have a strategy to deal with this as we are doing some Bazel migrations now

[keith]

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