Can I avoid debugger to stop in assembly code?

Question

I'm debugging some Rust code and it pass throw places like:

I think this is some assembly code from rust libraries. Is there any way to avoid to stop here? And just go throw readable code? I already unflagged the option

Disassembly View: Show Source Code
Show Source Code in Disassembly View.

My launch.json is a very default one:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "launch",
            "cargo": {
                "args": [
                    "build",
                    "--bin=myproject",
                    "--package=myproject"
                ],
                "filter": {
                    "name": "myproject",
                    "kind": "bin"
                }
            },
            "args": [],
            "cwd": "${workspaceFolder}",
            "env": {}
        }
    ]
}

Answer 1

I note that the picture you posted shows Local Variables for self and cx in the Locals window. If that Locals window is for the current frame - the one showing assembly instead of source - then you must have debug info for that frame (*).

If that's all true, it's much more likely be that you just don't have a local copy of the source files for this function. Maybe you downloaded a debug version of the rust standard libraries and that's why it has debug info? You can tell for sure by running the command:

(lldb) image lookup -va $pc

when stopped here. If there are entries for CompileUnit and Function, etc. then you do indeed have debug info for this frame.

All of lldb's tests for "don't stop in code with no debug info" are about the presence of debug info, not whether we can find the associated sources. So if you have debug info for a function, and your program gets into that function in the course of stepping, lldb will stop there.

You can modify this behavior on a library by library basis by adding the library name to the lldb setting target.process.thread.step-avoid-libraries. It's a colon separated list of library names or paths. If a step (but not step-instruction) operation ends up in a library on that list, lldb will step back out again regardless of whether it has debug info or not - which is I presume the behavior you want.

Alternately, if you want to step into this function provided you can see the sources, you can surely download the sources for the rust libraries that match the ones you have installed. You will likely also have to use the target.source-map setting to tell lldb where the sources are on your local system.

(*) Note, local variables can show up in non-debug functions if you have a "frame recognizer" registered for that function. lldb has no built-in recognizers for Rust, so you would have had to add that by hand which makes this possibility unlikely. It doesn't sound like you were doing special things for this function.

Answer 2

I guess what could be happening here. I have no time to test my guess, so please forgive me if I'm saying something wrong.

When you change a state in a context, the provider and its children are re-rendered. In this case, the UserContextProvider and its children.
So first thing, please be sure that SignIn is rendered inside a UserContextProvider, e.g. embedding all the app inside a . I generally do this in the index.js file.

ReactDOM.render(
    <UserContextProvider>
        {/* ... app here, that includes SignIn ... */}
    </UserContextProvider>,
    document.getElementById('root')
);

Second thing, since you are including the console.log() so that are executed in the same rendering in which you change the state, it's clear that they won't reflect the new value that will be available in the successive rendering only.
I suggest that you put the console.log(user) at the beginning of the SignIn component, say immediately after useNavigate(), outside the handleSubmit function.

const SignIn = () => {
  const { signIn, setUserValidation, user } = useAuth();
  const [ errorMessage, setErrorMessage ] = useState(null);
  const navigate = useNavigate();

  console.log(user)

  // ...ecc...
}

If I'm right, this console.log will be executed (at least) twice, one for the initial rendering, one for the subsequent rendering triggered by setUser (you can also include a console.log in the handleSubmit just to detect the re-rendering triggered by setUser). In the last rendering, you should see the user data.

If this works as I expect, I guess that you can handle the signIn with something like this

const SignIn = () => {
  const { signIn, setUserValidation, user } = useAuth();
  const [ errorMessage, setErrorMessage ] = useState(null);
  const navigate = useNavigate();

  // in the first rendering, the userName will be '', so it won't navigate
  // if the component is re-rendered after the setUser in signIn,
  // in this rendering there will be a userName, hence the navigation will proceed
  if (user.userName !== '') {
    navigate('/');
  }

  const handleSubmit = async (e) => {
    e.preventDefault();
    setErrorMessage(null);
    
    signIn().catch(err => {
      setErrorMessage('Error singing in, please try again.', err);
    });
  }

  return (
    // ... as before ...
  );
}

Happy coding! - Carlos