Step-into behaves as step-over (jumps over function)

[artem-ogre]

OS: Ubuntu 20.04 VSCode version: VSCodium

Version: 1.62.3
Commit: ccbaa2d27e38e5afa3e5c21c1c7bef4657064247
Date: 2021-11-19T00:20:00.672Z
Electron: 13.5.2
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.11.0-40-generic

CodeLLDB version: 1.6.10 Compiler: gcc Debuggee: c++ binary

When I attempt to step-into a function the debugger will not enter it but jump to the next line at the call-site instead.

When setting a break-point inside the function it is hit without problems. Also it is possible to step-into the function after multiple thread step-inst commands in the debugger console.

My launch.json has nothing special:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug (LLDB)",
            "type": "lldb",
            "request": "launch",
            "program": "${command:cmake.launchTargetPath}",
            "args": [],
            "cwd": "${workspaceFolder}/gfl",
        }
    ]
}

Verbose log after issuing `thread step-in`

  [2021-11-25T10:24:48.802Z DEBUG codelldb::dap_codec] --> {"command":"completions","arguments":{"frameId":1001,"text":"t","column":2,"line":1},"type":"request","seq":15}
[2021-11-25T10:24:48.803Z DEBUG codelldb::dap_codec]  {"command":"evaluate","arguments":{"expression":"thread step-in","frameId":1001,"context":"repl"},"type":"request","seq":16}
[2021-11-25T10:24:52.340Z DEBUG codelldb::debug_session::variables] thread step-in -> SuccessContinuingNoResult, Error:  Success
[2021-11-25T10:24:52.340Z DEBUG codelldb::debug_session] Debug event: 0x7fbc440036c0 Event: broadcaster = 0x5609a308f348 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x5609a308f310 (pid = 30222), state = running}
[2021-11-25T10:24:52.340Z DEBUG codelldb::dap_codec]  {"command":"scopes","arguments":{"frameId":1001},"type":"request","seq":17}
[2021-11-25T10:24:52.345Z DEBUG codelldb::dap_codec]  {"command":"threads","type":"request","seq":18}
[2021-11-25T10:24:52.345Z DEBUG codelldb::dap_codec]  {"command":"variables","arguments":{"variablesReference":1027},"type":"request","seq":19}
[2021-11-25T10:24:52.347Z DEBUG codelldb::dap_codec] ::element_type @ 0x0000555555647400","variablesReference":1031},{"evaluateName":"offsettedLine","memoryReference":"0x7FFFFFFFD670","name":"offsettedLine","type":"const Model::ILinePtr","value":"std::__shared_ptr<:iline __gnu_cxx::_s_atomic>::element_type @ 0x000055555564e140","variablesReference":1032}]}}
[2021-11-25T10:24:52.348Z DEBUG codelldb::dap_codec] --> {"command":"stackTrace","arguments":{"threadId":30222,"startFrame":0,"levels":1},"type":"request","seq":20}
[2021-11-25T10:24:52.348Z DEBUG codelldb::dap_codec]  {"command":"scopes","arguments":{"frameId":1033},"type":"request","seq":21}
[2021-11-25T10:24:52.767Z DEBUG codelldb::dap_codec]  {"command":"variables","arguments":{"variablesReference":1034},"type":"request","seq":22}
[2021-11-25T10:24:52.772Z DEBUG codelldb::dap_codec] ::element_type @ 0x0000555555647400","variablesReference":1038},{"evaluateName":"offsettedLine","memoryReference":"0x7FFFFFFFD670","name":"offsettedLine","type":"const Model::ILinePtr","value":"std::__shared_ptr<:iline __gnu_cxx::_s_atomic>::element_type @ 0x000055555564e140","variablesReference":1039}]}}
[2021-11-25T10:24:52.778Z DEBUG codelldb::dap_codec] --> {"command":"stackTrace","arguments":{"threadId":30222,"startFrame":1,"levels":19},"type":"request","seq":23}
[2021-11-25T10:24:52.779Z DEBUG codelldb::dap_codec] (std::__invoke_memfun_deref, void (OffsetLineTest::*&)(), OffsetLineTest*&)","source":{"name":"invoke.h","path":"/usr/include/c++/9/bits/invoke.h"}},{"column":40,"id":1041,"line":95,"name":"std::__invoke_result::type std::__invoke(void (OffsetLineTest::*&)(), OffsetLineTest*&)","source":{"name":"invoke.h","path":"/usr/include/c++/9/bits/invoke.h"}},{"column":24,"id":1042,"line":400,"name":"void std::_Bind::__call(std::tuple&&, std::_Index_tuple)","source":{"name":"functional","path":"/usr/include/c++/9/functional"}},{"column":24,"id":1043,"line":484,"name":"void std::_Bind::operator()()","source":{"name":"functional","path":"/usr/include/c++/9/functional"}},{"column":37,"id":1044,"line":300,"name":"std::_Function_handler >::_M_invoke(std::_Any_data const&)","source":{"name":"std_function.h","path":"/usr/include/c++/9/bits/std_function.h"}},{"column":14,"id":1045,"line":688,"name":"std::function::operator()() const","source":{"name":"std_function.h","path":"/usr/include/c++/9/bits/std_function.h"}},{"column":22,"id":1046,"line":175,"name":"CppUnit::TestCaller::runTest()","source":{"name":"TestCaller.h","path":"/usr/include/cppunit/TestCaller.h"}},{"column":0,"id":1047,"line":14,"name":"CppUnit::TestCaseMethodFunctor::operator()() const","presentationHint":"subtle","source":{"name":"@CppUnit::TestCaseMethodFunctor::operator()() const","sourceReference":1000}},{"column":0,"id":1048,"line":18,"name":"CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&)","presentationHint":"subtle","source":{"name":"@CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&)","sourceReference":1001}},{"column":0,"id":1049,"line":187,"name":"CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&)","presentationHint":"subtle","source":{"name":"@CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&)","sourceReference":1002}},{"column":0,"id":1050,"line":41,"name":"CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::__cxx11::basic_string, std::allocator > const&)","presentationHint":"subtle","source":{"name":"@CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::__cxx11::basic_string, std::allocator > const&)","sourceReference":1003}},{"column":0,"id":1051,"line":70,"name":"CppUnit::TestCase::run(CppUnit::TestResult*)","presentationHint":"subtle","source":{"name":"@CppUnit::TestCase::run(CppUnit::TestResult*)","sourceReference":1004}},{"column":0,"id":1052,"line":28,"name":"CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*)","presentationHint":"subtle","source":{"name":"@CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*)","sourceReference":1005}},{"column":0,"id":1053,"line":15,"name":"CppUnit::TestComposite::run(CppUnit::TestResult*)","presentationHint":"subtle","source":{"name":"@CppUnit::TestComposite::run(CppUnit::TestResult*)","sourceReference":1006}},{"column":0,"id":1054,"line":28,"name":"CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*)","presentationHint":"subtle","source":{"name":"@CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*)","sourceReference":1005}},{"column":0,"id":1055,"line":15,"name":"CppUnit::TestComposite::run(CppUnit::TestResult*)","presentationHint":"subtle","source":{"name":"@CppUnit::TestComposite::run(CppUnit::TestResult*)","sourceReference":1006}},{"column":0,"id":1056,"line":15,"name":"CppUnit::TestResult::runTest(CppUnit::Test*)","presentationHint":"subtle","source":{"name":"@CppUnit::TestResult::runTest(CppUnit::Test*)","sourceReference":1007}},{"column":0,"id":1057,"line":22,"name":"CppUnit::TestRunner::run(CppUnit::TestResult&, std::__cxx11::basic_string, std::allocator > const&)","presentationHint":"subtle","source":{"name":"@CppUnit::TestRunner::run(CppUnit::TestResult&, std::__cxx11::basic_string, std::allocator > const&)","sourceReference":1008}},{"column":17,"id":1058,"line":114,"name":"main","source":{"name":"Main.cpp","path":"/home/artem/data/dev/leica/polaris_dev_env/polaris/gfl/Test/gcc/Main.cpp"}}],"totalFrames":22}}

x86_64-linux-gcc

[Ingrater]

@vadimcn do you have any details on this? Is there a LLDB bug tracking this issue? I'm currently hitting this as well.

[artem-ogre]

Just stating what's already known I guess, but, yes, it's an LLDB issue as I had the same problem in CLion.

[Ingrater]

LLDB issue is tracked here: https://github.com/llvm/llvm-project/issues/54250

[Ingrater]

As it turns out this issue was introduced in llvm-14 and fixed in llvm-15. To fix this issue in vscode-lldb either roll back to llvm-13 or update to llvm-15 which will come out in a few days.

[ToBoMi]

This extension uses a bundled llvm-15 now. The issue still persists for me on windows.

(base) PS C:\Users\[myusername]\.vscode\extensions\vadimcn.vscode-lldb-1.8.1\lldb\bin> .\lldb.exe --version
lldb version 15.0.0-custom

[ToBoMi]

I fetched an llvm-13 by installing this extension in version 1.6.10. Either version 1.6.10 nor the current version 1.8.1 with llvm-13 works as a workaround.

[ToBoMi]

I made a very small example project and stepping into a function using F11 (Step into) here works. When I now want to step over that function using F10 (Step over) vscode steps into the function, too. So it is just the opposite of what happened in the other project.

[vadimcn]

Please note that the PDB debug info format on Windows is pretty different from "normal" code path in LLDB with its own set of bugs.

[andrewvoznytsa]

Could it be possible to tweak lldb.library handling to support ${workspaceFolder} as part of lldb.so path? Something like

"lldb.library": "${workspaceFolder}/llvm/lib/liblldb.so" ?

I did quick googling and seems like ${workspaceFolder} couldn't be used within settings.json scope, but I'm not fully sure - electron/vscode and related technologies are absolutely out of my scope.

Adding such feature solves two issues:

1. resolves lldb-14 step-into issue on Ubuntu 22.04
2. allows to use portable toolchain in developer-friendly way