See also https://github.com/llvm/llvm-project/issues/62684

Added test case.

Landed again, with a fix for the test that was failing on Darwin, as https://github.com/llvm/llvm-project/commit/d69518b4e52d527b3f8fcc41e90ae21f1f234555. I'll keep an eye on the build bot.

Sure, I'll revert. Thanks for notifying me of the problem.

Addressed review comments:

Ping.

Ping.

Addressed review comments.

Addressed review comments.

Added a --debugger-pid flag that needs to be passed with --launch-target so
that we can restrict PR_SET_PTRACER to the main lldb-vscode instance instead of
using PR_SET_PTRACER_ANY.

Thanks!

In D147007#4225762, @JDevlieghere wrote:

LGTM. I think it would be worth adding that information to the top of the file to prevent similar mistakes in the future.

In D146590#4225500, @bulbazord wrote:

Yea, after reading the SWIG documentation, this diagnosis looks correct. If you'd like to fix this feel free to upload a patch and list myself and @mib as reviewers. Otherwise let me know and I can take care of it. Thanks for doing that investigation!

I just noticed a minor aesthetic problem with the input of dwim-print when using data formatters. There are some spacing adjustments in this commit but I'm not sure if they are the actual cause (please let me know if you'd prefer me to file a bug instead).

I found the actual reason for the crash I was talking about. This patch only addressed the incorrect OverflowError, but the crash comes from a double free (as @rupprecht mentioned) in the error handling logic. The error path here does both free($1); and SWIG_fail;. The same goes for another error check a few lines below that. In the generated code, the SWIG_fail macro is expanded to goto fail and the fail label also frees the same memory buffer.

I've tried building lldb with this patch applied and it fixes the problem I saw. Thanks for the quick fix!

By the way, I just bisected another problem to this commit: I'm seeing in some cases that prettyprinted values with synthetic children don't show child names when using dwim-print. So print used to show:

(lldb) p c
(MyClass) $0 = MyClass object with children: {
  [0] = 0x0000555555556004 "hello"
}
(lldb) p m
(MyMap) $1 = MyMap object with children: {
  ["my_key"] = 0x0000555555556011 "my_value"
}

but now it shows

(lldb) p c
(MyClass)  MyClass object with children: {
  0x0000555555556004 "hello"
}
(lldb) p m
(MyMap)  MyMap object with children: {
  0x0000555555556011 "my_value"
}

Are you using persistent results? If not, how much effort is it to either 1) change the tools/code that examine the output to not look for $\d+, or 2) use a custom print/p alias? Honest question.

What was the rationale for this change? It changes the output format of a common command (given that print is now an alias for dwim-print) and it breaks basically anything that examines debugger output.

Modified one of the existing test cases for SBData.SetDataFromUInt64Array to add a 2**63 to actually exercise the uint64 range.

There's a comment next to the __libcpp_verbose_abort definition that says

// This function should never be called directly from the code -- it should only be called through
// the _LIBCPP_VERBOSE_ABORT macro.

Does this apply here? For context, we have a libc-free project that uses variant and optional and this change pulls in vfprintf. We'd like to just provide our own _LIBCPP_VERBOSE_ABORT, or build with -D_LIBCPP_HAS_NO_VERBOSE_ABORT_IN_LIBRARY but it doesn't look like we can do that if the code calls __libcpp_verbose_abort directly.

Addressing review comment.

• Clarified help text for --recognizer-function as suggested by reviewer. Instead of "Incompatible with --regex (-x)." now it says "Cannot be specified at the same time as --regex (-x)."
• Rebased on top of current HEAD.

In D137000#3915943, @jingham wrote:

It is a bit odd to follow the what the help summary says is a valid option set and then get an error. But this is a corner case, and since you say explicitly that you can't provide both that's probably good enough. Would you mind changing "Incompatible with" to: "Cannot be specified at the same time as". Incompatible isn't precise - does it mean you can't use them both, or that if you do something weird will happen?

@jingham any comments on https://reviews.llvm.org/D137000#3897162?

• Removed -R short option to avoid confusion with regex. Updated doc, test case, and example.
• Added some logic to make --recognizer-function and --regex mutually exclusive. Specifying both now results in an error being reported to the user.
• Rebased on top of current HEAD.

I'm looking at the option of using a non-printable character for the short flag, and at the same time make --regex and --recognizer-function mutually exclusive using option groups. One problem I see is that the command help gets pretty confusing. Using a non-printable character as the short option name makes the option completely disappear from the "Command Options Usage" summary part of the help.

You can't provide the --regex option and this matcher at the same time

Hi! I've just debugged an issue that brought me to this commit. I'll start preparing a patch tomorrow (not sure how to test it yet) but since it's a recent-ish change I figured I'd ping the commit thread to give you a heads up.

Address review comments.