Change:
"^core::num::([a-z_]+::)*NonZero.+$", ]; <ins> // In newer versions of lldb, persistent results (the `$N =` part at the start of // expressions you have evaluated that let you re-use the result) aren't printed, but lots // of rustc's debuginfo tests rely on these, so re-enable this. // See <https://reviews.llvm.org/rG385496385476fc9735da5fa4acabc34654e8b30d>. script_str.push_str("command unalias printn"); script_str.push_str("command alias print expr --n"); script_str.push_str("command unalias pn"); script_str.push_str("command alias p expr --n"); </ins> script_str .push_str(&format!("command script import {}n", &rust_pp_module_abs_path[..])[..]); script_str.push_str("type synthetic add -l lldb_lookup.synthetic_lookup -x '.*' ");

Discussion:
CI on macOS sometimes fails due to this failure: You can find the full log here: The failure occurs on , , and (at least).
Oh, I just found the related Zulip topic: https://rust-
Please ping me if another failure happens again.
This just happened in .
Another instance:
Not sure if this is useful: I always get the first error about DWTAGbasetype on my Linux box (Linux debby 4.19.0-11-amd64 SMP Debian 4.19.146-1 (2020-09-17) x8664 GNU/Linux), just like others reported in . For my purpose, the workaround was to .
Copying the full log from a recent failure: The is normal, this happens on Linux, too (not sure why). The error is also normal, this happens on Linux. The issue here is that the function isn't imported. The lldb script interpreter has a "session" dictionary, and functions need to be specifically to it to be called. I'm not sure how it worked previously (maybe older versions of lldb worked differently). Regardless, I suspect it is unrelated (this error is ignored). I've tried running the test in a loop locally, but have been unable to get it to fail. It looks like it is failing while trying to print out , which normally should display something like this:
Another instance:
I'm not sure if anyone else is looking into this issue. I've tried many experiments with little success. I've never been able to reproduce locally, but I can pretty reliably reproduce on GitHub Actions. The only change that seems to reliably avoid the error is to when building the test. I don't have any theories as to why that is. If you search for the error messages on Google, you can find many other people running into similar situations. It seems like most of them are related to somehow dynamically linking the wrong LLVM. I'm not sure how that fits for this situation. I'm also unsure if lldb is somehow linking the wrong LLVM, why it doesn't fail 100% of the time. I'm also uncertain exactly how the error is originating (does lldb launch clang somehow?).
Failed again and again in and
I should get an actual macOS device to investigate this more productively early next week.

Failed in
Minor update of other clues I've discovered: Downgrading to Xcode 11.7 makes the problem go away (Xcode 12.0, 12.1, and 12.2 all seem to fail) from the debugger script makes the problem go away (or just changing it to ). That involves a fairly large amount of Python code, but none of it seems particularly fishy to me. What's really strange is that when it fails, none of my debug print statements appear (even though all buffering should be disabled). as the author of the lldbproviders, do you have much experience with debugging lldb issues? Do you think you could provide any insight or help here? Just to summarize, there is a test () which is periodically failing on the macOS builders with this error: This happens when calling which launches the . I haven't been able to reproduce it locally, only on GitHub Actions. I'm at a loss as to what could be different about their environment.
Failed in . Are you sure that is the problem, other than it is the only from the 3 errors displayed not yet debunked here? In my experience - with gdb, not lldb! - stderr is suppressed if the test succeeds, so you need to explicitly fail the test to see whether this error is also normal on that platform. What is displayed in the report is the contents of a file, that earlier in the test execution contains other messages - at least rustc warnings about the test case code compiled. I had the impression there were 5 stages, each of which might be overwriting useful diagnostics from an earlier stage.
Looks like the problem occurs only when using LLDB without native Rust support, isn't it? If so, it may be helpful to disable this specific test from for such LLDB by deleting line right after command. If this doesn't help, you can also try to disable all the tests on macOS by adding line. Regarding removing , it just disables all the LLDB pretty-printers responsible for children formatting (like vector or map elements), and so the elements will not be printed by the debugger. I think the problem is probably related to LLDB itself, but not to Python pretty-printers implementation.

But it might be helpful to debug the pretty-printers code using logging: just insert to and add something like this to
Thanks for the tip on the logger, I was assuming setting would allow stderr to print, but I guess not. I'm concerned about just disabling the test, as it feels like sweeping the problem under the rug without understanding what is wrong. It does seem likely it is an issue with lldb, but I think it would be good to at least have some vague understanding of what is wrong, and why it only affects this test. Sorry, I'm not too familiar with lldb or the Rust integration. What do you mean by "LLDB without native Rust support"? What little information I can find at https://rustc-dev- seems to point to a repository that is archived and hasn't been updated in 3 years. AFAIK, building a custom lldb was removed over a year ago (). I can see a small amount of rust support in upstream LLDB, but it seems to be . It is a bit difficult to compare, but the lldb in rust-lang/llvm-project is a fair bit different from apple/llvm-project. With logging, the last line printed is consistently just before . Looking through the LLDB source, if I'm reading it correctly, this triggers creating a TypeSystem which I believe for Rust is TypeSystemClang. Unfortunately that is a pretty large amount of code.
a new data point that they were able to reproduce on the Apple DTK (), which helps rule out anything special about GitHub's environment. I'm going to be away for a week or two, so I won't be able to look at this anymore. I would recommend that if nobody wants to investigate this further, that someone should add just to avoid the CI errors. I suspect that doing that means it will likely never get fixed, but I suspect it's an issue deep inside lldb and a bit out of our control anyways.
This also reproduced locally on a pratically clean macOS 10.15 installation by running (before I was running it with ).
The test file already has ignore-windows, ignore-freebsd, ignore-android... I think an ignore-macos won't be much of an issue.
→
You're right, seems like "LLDB with native Rust support" (which is basically LLDB with Rust support patches) is not used in anymore.

However, it is used in IntelliJ Rust and AFAIK. BTW, probably could tell something about error regarding LLDB? Was this problem fixed in the Rust-enabled LLDB? There are really lots of ignored debugging tests, so I agree with you that disabling these tests on macOS won't make it much worse.
Yes, but maybe not in the way you may be thinking. In LLDB, each language provides its own code to analyze DWARF. So, the Rust-specific DWARF analysis handles this case without issuing an error. See for the DWARF-reading bit. Offhand I would expect it to use , and digging through the LLDB patches a bit supports this, but I'm not sure. This kind of difference is trivial to handle though.
I think an unintended consequence of is that pretty-std-collections is no longer tested on any platform, and it has been broken over time ().
my PR only ignored the test on Mac OS. It should still be tested on Linux, no?
See .
oh that's unfortunate. It was definitely not my intent when doing that. The gdb tests should still be run. At least when I change something in the gdb related text on my local Linux machine I get a test failure (otherwise a success). For some reason I don't get such a reaction when altering the lldb related text tho.
(To make it clear, the premise of was that it does still run all the tests on linux, but apparently the lldb ones were only run on mac OS.... I installed lldb locally on my Linux and it's broken.... maybe the solution is really to make the Linux box do somewhere)