Bashdb doesn't stop in breakpoints in VSCode when using WSL Ubuntu in Windows

[ZaidaEMtzMo]

I'm having issues debugging a Bash script with bashdb in Visual Studio Code using the WSL extension. Despite setting breakpoints in my Bash script, the debugger runs the script without stopping at any breakpoints. As far as I understand, I have installed all the needed extensions inside the remote WSL: Ubuntu-20.04. I have also set up the bashdb extension as suggested.

Here is the requested information:

Executables

Version of bash-debug: v0.3.9 Version of VSCode: 1.84.2 Version of Ubuntu: Ubuntu 20.04.6 LTS focal Version of WSL: WSL 2 Version of bash: 5.0.17(1)-release

Output of requested commands:

where bash # On PowerShell
C:\Windows\System32\bash.exe
C:\Users\Zaida\AppData\Local\Microsoft\WindowsApps\bash.exe

code --version # On PowerShell and WSL
1.84.2
1a5daa3a0231a0fbba4f14db7ec463cf99d7768e
x64

bash -c 'uname -a; for P in bash bashdb cat mkfifo pkill; do echo ---; which -a \$P; command \$P --version; done'

Linux HOMEPC 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
---
/usr/bin/bash
/bin/bash
GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
---
/usr/bin/bashdb
/bin/bashdb
bashdb, release 5.0-1.1.2
---
/usr/bin/cat
/bin/cat
cat (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund and Richard M. Stallman.
---
/usr/bin/mkfifo
/bin/mkfifo
mkfifo (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
---
/usr/bin/pkill
/bin/pkill
pkill from procps-ng 3.3.16

Debug output

Paste here outputs in DEBUG CONSOLE (ctrl+shift+D or command+shift+D) with "showDebugOutput": true and "trace": true in launch.json. Your launch.json may looks like: The summarized output of DEBUG CONSOLE including only the lines that contain word "breakpoint":

To client: {"seq":0,"type":"response","request_seq":1,"command":"initialize","success":true,"body":
{"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":false,"supportsEvaluateForHovers":
true,"supportsStepBack":false,"supportsSetVariable":false}}

##1 sourceFrom client: setBreakpoints({"source":{"name":"Debugging_test.sh","path":"../Debugging_test.sh"},
"lines":[7,13,19],"breakpoints":[{"line":7},{"line":13},{"line":19}],"sourceModified":false})

To client: {"seq":0,"type":"event","event":"output","body":{"category":"stdout","output":
"No breakpoints have been set.\n"}}

No breakpoints have been set.

To client: {"seq":0,"type":"response","request_seq":6,"command":"setBreakpoints","success":true,"body":
{"breakpoints":[{"verified":true,"line":null,"id":null},{"verified":true,"line":null,"id":null},{"verified":
true,"line":null,"id":null}]}}

From client: setExceptionBreakpoints({"filters":[]})

To client: {"seq":0,"type":"response","request_seq":7,"command":"setExceptionBreakpoints","success":true}

My launch.json file:

{
    // 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": "bashdb",
            "request": "launch",
            "name": "Bash-Debug (simplest configuration)",
            "program": "${file}",
            "showDebugOutput": true,
            "terminalKind": "integrated",
            "trace": true
        }
    ]
}

Details

This is the script that I am using to test it, but I have already tried with two others and the result is always the same:

#!/usr/bin/env bash
export NICE_VAR=10
export ANOTHER_VAR=20

for i in {0..25..5}
do  
    export NICE_VAR=$((NICE_VAR+i)) # BREAKPOINT
    echo $NICE_VAR
done

for ((i=1;i<=25;i+=1))
do  
    export ANOTHER_VAR=$((ANOTHER_VAR+i)) # BREAKPOINT
    echo $ANOTHER_VAR
done

if [ $ANOTHER_VAR -gt $NICE_VAR ]
then  
    echo "ANOTHER bigger than nice" # BREAKPOINT
else  
    echo "Nice is bigger or equal"
fi

I have tried changing the terminalKind to debugConsole but it still skips the breakpoints. I have also tried to change some other settings to no avail. Am I missing something to install? Or is it not possible to stop in breakpoints when using WSL? I have tested also a script in Python and WSL, and that one works well, so it seems to be an interaction between bash-debug and WSL/VSCode? Using the same settings, I was able to stop at the breakpoints in an Ubuntu computer, so it's definitely related to the WSL.

However, I have not been able to make bash-debug work without using the remote WSL, as every time I try to run it, I get the message: "Error: BUG: reached to unreachable code while validating environment (code 4294967295,). If it is reproducible, please report..." Right now, I am not that interested in running it directly there, but I am mentioning it in case they are related. In this last case, I have tried different setups of the launch.json, trying to determine which terminal to use and the bash path (either "C:\Program Files\Git\bin\bash.exe" or "C:\Windows\System32\bash.exe", but to no avail...

Anyways, any help is appreciated. Thank you so much!

[JDubbTX]

Extension version: v0.3.9 VSCODE version: v1.86.2 I am also experiencing this issue, both in WSL, and in a docker devcontainer. I'm using the standard launch config:

        {
            "type": "bashdb",
            "request": "launch",
            "name": "Bash-Debug (simplest configuration)",
            "program": "${file}"
        }

[ghost]

I have the same launch configuration and extension version as @JDubbTX , and am having the same issue.

I am not sure if this provides any insight, but I did notice in the call stack that both the "source" used by the debugger and the target "file" have WSL paths. ie. mnt/c/user/~

However, when I set breakpoints and hover over them, the filename that pops up has the Windows C:\Users\~ path instead.

Is there some breakpoint configuration that needs to be corrected?

Thanks.

[rogalmic]

Hi,

I found some time to check that since it seems like interesting issue.

It all seems to revolve around VSCode passing non-absolute file path while signalling new breakpoint ot extension:

setBreakpoints({"source":{"name":"Debugging_test.sh","path":"../Debugging_test.sh"},

In my case it is always absolute for some reason:

setBreakpoints({"source":{"name":"Debugging_test.sh","path":"c:\\Users\\Michal\\src\\Debugging_test.sh"}

In principle relative path should work, since we cd into workspace folder while starting debug session, but you might want to play around with this launch setting:

            "cwd": "${workspaceFolder}", //try setting current folder manually

For now i cannot make VSCode to use/show relative path (as it is in your case), so it is hard for me to find exact root cause (see path while hovering):