[Solved] Lldb 7: most frame variables unavailable

#1

Using Ubuntu 18.04, lldb 7 (remote via lldb-server v7), I managed to get the debugger going. It’s not showing me the values of my variables. It is doing a good job of symbolicating, and it occasionally can tell me the value of a variable, but for the most part my variable’s values are “not available”. A similar issue was filed about lldb 3.8, but that was resolved years ago. I’m on lldb 7 both client and server.

The biggest clue to the problem may be this output from lldb:

error: hist {0x0002feaa}: unhandled type tag 0x0033 (DW_TAG_variant_part), please file a bug and attach the file at the start of this error message

To give you the flavor of what I’m seeing, here is a frame where almost none of my stack variables have resolved values, even though I’m well past the point in the function where they should have values. I don’t have a good understanding of the kinds of optimizations that a debug build is capable of applying, but I find it very hard to believe that most of these variables are optimized out (actually, hard to believe that any of them are).

frame variable
(seraphim::search::SearchTree<seraphim::tictactoe::state::State, unsigned long> *) self = <variable not available>

(seraphim::search::&mut GameExpert<seraphim::tictactoe::state::State, usize>) game_expert = <variable not available>

(unsigned long) max_actions = <variable not available>

(seraphim::search::SearchTree<seraphim::tictactoe::state::State, unsigned long> *) self_ptr = <no location, value may have been optimized out>

(alloc::vec::Vec<(&seraphim::search::Edge<usize>, petgraph::graph_impl::NodeIndex<u32>)>) child_edges = (9) vec![{...}, {...}, {...}, {...}, {...}, ...] {
  [0] = {
    action = 8
    prior = 0.0892010629
    scaled_prior = 0.111111112
    raw_prior = 0.111111112
    visit_count = 54
    total_value = 36.5
    average_value = 0.67592591
  }
  [1] = {
    action = 18446744069414584327
    prior = 0
    scaled_prior = 0.0000000000000000000000000000000000000000000126116862
    raw_prior = 0.00000000000000000000000000000000000000000000140129846
    visit_count = 0
    total_value = 0.00000000000000000000000000000000000000000000140129846
    average_value = 0
  }
  [2] = {
    action = 4466710411999786948
    prior = 0.109405831
    scaled_prior = 0.0000000000000000000000000000000000000000000168155816
    raw_prior = 5
    visit_count = 1054168405
    total_value = NaN
    average_value = NaN
  }
  [3] = {
    action = 42949672961
    prior = 0.00000000000000000000000000000000000000000000140129846
    scaled_prior = 0
    raw_prior = 0.00000000000000000000000000000000000000000000280259693
    visit_count = 0
    total_value = 0.095519118
    average_value = 0.12445543
  }
  [4] = {
    action = 22513043571
    prior = 1
    scaled_prior = 0.200000003
    raw_prior = 0.0000000000000000000000000000000000000000000126116862
    visit_count = 4294967295
    total_value = 0.00000000000000000000000000000000000000000000140129846
    average_value = 0.0000000000000000000000000000000000000000000154142831
  }
  [5] = {
    action = 1
    prior = 0.00000000000000000000000000000000000000000000420389539
    scaled_prior = 0
    raw_prior = 0.161088377
    visit_count = 1039987060
    total_value = 0.109405831
    average_value = 0.00000000000000000000000000000000000000000000700649232
  }
  [6] = {
    action = 0
    prior = 0.0000000000000000000000000000000000000000000140129846
    scaled_prior = NaN
    raw_prior = 0.00000000000000000000000000000000000000000000140129846
    visit_count = 12
    total_value = 0.00000000000000000000000000000000000000000000140129846
    average_value = 0
  }
  [7] = {
    action = 4
    prior = 0.117116839
    scaled_prior = 0.125137165
    raw_prior = 0.1108495
    visit_count = 3
    total_value = 0
    average_value = 0
  }
  [8] = {
    action = 18446744069414584331
    prior = 0.00000000000000000000000000000000000000000000140129846
    scaled_prior = 0.00000000000000000000000000000000000000000001821688
    raw_prior = 0.00000000000000000000000000000000000000000000140129846
    visit_count = 0
    total_value = 0.00000000000000000000000000000000000000000000700649232
    average_value = 0
  }
}
(alloc::vec::Vec<float>) results = <variable not available>

(unsigned int) total_visit_count = <no location, value may have been optimized out>

(float) prob = <variable not available>
[Solved] 30 secs to compile 1200 lines of code?
#2

Same issue is present in lldb-4.0, lldb-5.0, and lldb-6.0, local or remote debugging.

I’ve also spot checked versions from nightly 1.34 all the way back to 1.0, and see the same thing.

#3

UGH!

The manifest file included

[profile.dev]
opt-level = 2

And the debug builds had optimizations in them.

1 Like
#4

Does this solve the problem? I would hope so because debug builds aren’t supposed to be optimized, and last time I used lldb with my rust program it worked fine. In fact I remember reading somewhere that there was better support with a newer version of rust, but don’t quote me on that.w

#5

Yes, that was the issue. I’m seeing all my frame variables now.