Thanks for reporting. Yeah, I didn't think of the situation where Distrod's shell is invoked by the debugger. I'll fix it.

By the way, I appreciate it if you could follow the template from next time for a bug report. This time I was able to guess the cause regardless of the environment, but I can't do that every time.

I created a fix for this in #48

It turns out that my fix does not completely fix the issue. While the debugging is somewhat working, for example setting breakpoints before running is not.

I found the reason for that. And an old comment gives some information of why it doesn't work.

/* If STARTUP_WITH_SHELL is set, GDB's "run"
will attempts to start up the debugee under a shell.
This is in order for argument-expansion to occur. E.g.,
(gdb) run *
The "*" gets expanded by the shell into a list of files.
While this is a nice feature, it turns out to interact badly
with some of the catch-fork/catch-exec features we have added.
In particular, if the shell does any fork/exec's before
the exec of the target program, that can confuse GDB.
To disable this feature, set STARTUP_WITH_SHELL to 0.
To enable this feature, set STARTUP_WITH_SHELL to 1.
The catch-exec traps expected during start-up will
be 1 if target is not started up with a shell, 2 if it is.

I don't think there's an easy for that, but perhaps there's a way to redefine the $SHELL environment variable to the real shell once wsl-distrod is stared.

But there are a few workarounds that users can do.

1. Add set startup-with-shell off' to either the user or system gdbinit`
2. Run the command inside gdb before running the executable
3. Start gdb with another shell for example SHELL=/bin/bash gdb
4. Export the real shell in the '.profile`

Note that these workarounds can be applied without the linked pull request.

Hi thanks so much for trying to fix it and the workaround, @fredizzimo !

Yes actually it needs two fixes; one is fix drop privilege, the another is bind-mounting the real shell on /opt/distrod/alias/usr/bin/*sh. I was working on it before getting busy, and now I have time and am resuming the work.

Has this problem been fixed now?
I need to debug through clion + WSL, but I still report an error.
I use distrod version 0.1.4
The error message is:
com. jetbrains. cidr. execution. debugger. backend. gdb. GDBDriver$GDBCommandException: Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1e216

this problem still persists. When will it be resolved?