2

I have a very straightforward rust function which just simply wants to get the first value of the list that is passed into it.

use std::fmt::Debug;
use std::ops::Add;

fn main() {
    fn calculate<T:Debug + Add::<Output=T>, const N: usize>(data_set: [T; N]) -> (i32, i32) {
        // Key Code 
        let _var = data_set.get(0);
        println!("Output_1: {:?}", data_set.get(0)); 

        // Ignore
        return (0, 0)
    }

    let data = [1509, 1857, 1736, 1815, 1576];
    let result = calculate(data);
    println!("Output_2: {:?}", result);
}

I have been trying to debug it in VS Code with rust-analyser, but the local variables in the debug panel are being shown to be duplicated 3 times over which I don't understand why is happening.

Memory Stack/Pile/Heap before function:

data: {1509, 1857, 1736, 1815, 1576}

Memory Stack/Pile/Heap immediately after entering function:

data_set: {1509, 1857, 1736, 1815, 1576}
data_set: {1509, 1857, 1736, 1815, 1576}
data_set: {1509, 1857, 1736, 1815, 1576}

I have deduced that the problem is caused by the line println!("Output_1: {:?}", data_set.get(0)); because by removing it, the duplicate data_set's disappear. However, I frankly have no understanding why it causes the problem.

Furthermore, whilst executing the line println!("Output_1: {:?}", data_set.get(0));, the values go random and extreme, changing the memory stack/heap to

data_set: {1509, 1857, 1736, 1815, 1576}
data_set: {-445645856, 223, -445645856, 223, -445645856} // numbers are different each execution.
data_set: {1509, 1857, 1736, 1815, 1576}

Can someone explain why this happens?

kmdreko
  • 42,554
  • 6
  • 57
  • 106
Gunty
  • 1,841
  • 1
  • 15
  • 27
  • I suspect that the `println` macro creates some internal variables that shadow yours, and that what you see in the debugger are those internal variables. – Jmb Nov 17 '21 at 09:32
  • use `rust-lldb`, debug manually and confirm if this is an issue with the debugger or vscode extension (most likely). another thing is that compiler back-end (llvm most likely) does some optimizations for code result: explained here https://doc.rust-lang.org/std/sync/ – Ivan Temchenko Nov 17 '21 at 10:15
  • I have debugged manually with lldb, i think. feel free to correct me if im wrong. Here is a screenshot of me doing it and the error still occuring. https://imgur.com/qErQkMf . I am still yet to delve into the optimizations part mentioned above. – Gunty Nov 17 '21 at 11:48
  • all time spend using a debugger is lost forever, get `tracing` crate and do a proper logging that will help you for all futur debugging. – Stargateur Nov 17 '21 at 13:36
  • "optimizations for code result" - further testing with some very simple for loops and stuff which also yielded absurd results, making it highly probable that the debugger shows code optimizations of some kind. I am now going to look into `tracing` as an alternative – Gunty Nov 17 '21 at 23:59
  • @Stargateur https://stackoverflow.com/questions/70013172/rust-tracing-debugger-want-simple-explanation-of-how-to-use – Gunty Nov 18 '21 at 01:09
  • Time spent using a debugger *is not* lost forever. Proficiency in using them is one of the tools all good developers should have as part of their skill set. As is logging, the two are not always interchangeable. – Todd Nov 20 '21 at 04:35
  • can someone take 3 minutes and confirm that this issue is reproducable? – Gunty Nov 20 '21 at 07:43

1 Answers1

3

This is a bug in the LLDB debugger that seems to have been introduced in version 1.6.9. I have filed an issue to address this behavior.

As a workaround, you can roll back the version to version 1.6.8 or earlier (or it appears to have since been fixed so you should update to a newer version).

kmdreko
  • 42,554
  • 6
  • 57
  • 106
Gunty
  • 1,841
  • 1
  • 15
  • 27