Attach mode does not work on version 0.2.1 using zsh #277
Comments
|
Unfortunately, I'm not able to reproduce your error so far. |
|
I'd appreciate it if you find a way to reproduce this problem. Thank you. |
|
Same issue here. Intel macOS, zsh, chruby 0.3.9, Ruby 3.2.2. Works with 0.1.0. |
|
All right, let's use another approach. |
|
Could you check the following steps? a=1
b=2
c=3
In my environment, I confirmed it works. |
|
|
@ono-max I have the same issue as @miharekar. rdbg-vscode seems to ignore the terminal setting we set un VSCode and always use the Login Shell setting. For example, If I change my Login Shell to bash: |
|
Thank you for reporting, but I was not able to reproduce the error 🤔 I'm using the following environment:
|
|
Also, this is the first time I've seen this long error message. Usually, when attaching to the debuggee failed, I get the error message such as follows: |
|
Could it be an intel thing? I'm not on arm64 🤔 And I'm on macOS 13.4. Also, if it helps narrowing down, I'm running oh-my-zsh with powerlevel10k theme. Other than that our envs are the same. |
|
Hmm, I confirmed it works with the following environment, too:
Thus, I don't think that it's related to OS. |
|
Could you check the following steps?
I got the following results in my environment: $ rdbg target.rb -O
DEBUGGER: Debugger can attach via UNIX domain socket (/var/folders/5j/z2c9zm7124q81f_py4xmd3scp7w9j7/T/ruby-debug-sock-746464807/ruby-debug-s15236-21955)
DEBUGGER: wait for debugger connection...
I got the following results in my environment: $ rdbg --util=list-socks
/var/folders/5j/z2c9zm7124q81f_py4xmd3scp7w9j7/T/ruby-debug-sock-746464807/ruby-debug-s15236-21955
I got the following results in my environment: $ rdbg -A --sock-path=/var/folders/5j/z2c9zm7124q81f_py4xmd3scp7w9j7/T/ruby-debug-sock-746464807/ruby-debug-s15236-21955
/var/folders/5j/z2c9zm7124q81f_py4xmd3scp7w9j7/T/ruby-debug-sock-746464807/ruby-debug-s15236-21955
DEBUGGER (client): Connected. PID:21955, $0:target.rb
[1, 10] in target.rb
=> 1| def foo(a, b)
2| [a, b]
3| end
4| def bar(c, d)
5| foo(1, 2);foo(3, 4)
6| end
7|
8| here = "--- set a breakpoint here ---"
9| bar 10, 20 # trace "bar" method here.
10| here = "--- set a breakpoint here ---"
=>#0 <main> at target.rb:1 |
|
@ono-max yup, that seems to work just fine |
|
Have you folks tried configuring the new |
|
Thank you for your quick response! |
|
@st0012 just now. Same result. 
There is all of this in the VS Code output: Feels like it's related to the theme I metioned above. Reading this issue it might be that the terminal is invoked in an interactive way, instead of a non-interactive one? I wonder why it works on 0.1.0 and previous versions 🤔 |
|
@ono-max Attaching using rdbg in command line works fine for both the test script and Rails. @st0012 Setting the Ruby Version Manager (rbenv in my case) causes the attach to run in an infinite loop. I have to kill the VSCode window to be able to attach again. What @miharekar said rang a bell tough. I saw this commit when trying to figure out the issue in the beginning. There seems to be some issue specific to zsh regarding loading the environment configuration when using rbenv. It mentions the interactive shell... I went in the extension.js:311 file and removed the 'i' option on the shell invocation. My debugger attaches fine now with version 0.2.1 and I am able to hit breakpoints. |
|
Also having the same issue as @miharekar using a similar configuration. Mac with Apple M1 Max |
|
@ono-max I think I found the root cause of the issue. There seems to be a conflict with the decoration happening when loading iTerm2 shell integrations. You can prevent that from happening by setting TERM=dumb which should not cause side-effects for your extension. Here is the code I used to test: With this change you can still load ~/.zshrc thus keeping support for rbenv and fix the attach issue. It would be great if someone who has the same issue would be able to test this locally by replacing the @ono-max You can reproduce this by installing the iTerm2 Shell Integration and setting your login shell to zsh. |
Closes ruby#277 The problem is that we can't extract the result from stdout since Oh other zshell framework outputs many strings to stdout. To prevent it, we add TERM=dumb as a environemnt variable. Co-authored-by: Pierre-Luc Foley <[email protected]>
Closes ruby#277 The problem is that we can't extract the result from stdout since Oh other zshell framework outputs many strings to stdout. To prevent it, we add TERM=dumb as a environemnt variable. Co-authored-by: Pierre-Luc Foley <[email protected]>
Closes ruby#277 The problem is that we can't extract the result from stdout since Oh other zshell framework outputs many strings to stdout. To prevent it, we add TERM=dumb as a environemnt variable. Co-authored-by: Pierre-Luc Foley <[email protected]>
Closes ruby#277 The problem is that we can't extract the result from stdout since Oh other zshell framework outputs many strings to stdout. To prevent it, we add TERM=dumb as a environemnt variable. Acknowlegement: Thanks to great reserching by @plfoley, we could fix this problem Co-authored-by: Pierre-Luc Foley <[email protected]>
|
All yours! Happy to see this fixed. |
|
@plfoley if I try your makeShellCommand on 0.2.1 I get same error and this in the terminal output: But if I remove
Edit: This fixed it for me inside zshrc 🥳 |
|
@miharekar You would need to reload the extension after you change the code for the changes to take effect. The easiest way of doing this would be to close and re-open your VSCode window. I am sorry I should have mentioned that in my procedure. The solution you have will indeed work instantaneously as every time you attach, you spawn a new shell and ~/.zshrc get re-evaluated. Actually the fix you implemented is how I figured out that the issue was with iTerm2 Shell Integrations in the first place. The problem with that solution is that it requires a manual operation on every system. Be also mindful that if you reinstall iTerm2 Shell Extension later, the problem might reappear when changing the content of ~./zshrc. |
|
@plfoley I did reload, notice |
|
@miharekar Sorry I did not see, but you are right, the extension got reloaded fine. Can you confirm something for me please? |
|
@plfoley it does not. I saw there's quite a diff between what I have and what's on their website. Going to be updating… 😅 |
|
@miharekar @ono-max This is what I feared tough. This means we have a weak point with the proposed fix as it won't cover old versions of shell integration scripts. I think this might require a note in the ReadMe. |
|
Oh, I see. So the current approach is a partial solution. |
|
Ideally we'd not load the terminal in the interactive mode. Instead of coupling with iTerm, you could technically couple with rbenv/chruby since they're both ruby managers and this is a ruby plugin. So instead of relying on interactive terminal to load them, you'd try to load them in the way they should be loaded from their respective readmes. Silently fail if you can't load and give a way in settings to override the "smart ruby manager detection" mode. |
|
It will work for all Shell Integration scripts that were installed after they added the test for I checked and this condition has been there since at least December 2019 in their code base. The history stops there as the file was maybe moved, but this condition might have been there even before that. |
You mean, we should run the following command instead of loading shell? $ eval "$(~/.rbenv/bin/rbenv init - bash)"Or, we should load .zshrc directory as follows? $ . ~/.zshrc |
|
I meant the eval. Loading zshrc will have the same issue as we have right now, no? |
|
@miharekar is correct: If you load the content of I am not quite sure to understand why rbenv decided to put its configuration in |
|
I see. Thanks, guys. I'm not sure about the background of rbenv. Thus, I asked the question. |
|
I noticed that the version managers for Python and Nodejs use .zshrc. Using .zshrc to load initial commands may be a well-known way 🤔 https://github.com/pyenv/pyenv#set-up-your-shell-environment-for-pyenv |
|
What you say is true, but they mention this just after the ./zshrc setup in the pyenv documentation:
What I don't understand is why they don't suggest putting this in the config file that is common to all shells. They might have some reason for doing so. |
|
I'm also using zsh + chruby and having issues. Either:
I expect option 1 is what I should be doing, but I'm confused about the infinite loop. I've had issues before with our setup (chruby + VS Code + rdbg + Ruby LSP) and have the following in both my # brew
eval "$(/opt/homebrew/bin/brew shellenv)"
export PATH="$HOME/.yarn/bin:$HOME/.config/yarn/global/node_modules/.bin:$PATH"
export PATH="$HOME/.bin:$PATH"
# pyenv
export PYENV_ROOT="$HOME/.pyenv"
command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"
# chruby
source $(brew --prefix)/opt/chruby/share/chruby/chruby.sh
source $(brew --prefix)/opt/chruby/share/chruby/auto.sh
chruby_autoWhen I remove the Which makes sense. Any tips for debugging and/or working around the infinite spinner? |
|
@rnystrom I encounter the same issue with rbenv. My solution is not to specify the environment manager in the rdbg plugin at all. In the previous version, I managed to get the debugger to attach by specifying the path of rdbg through the shim in the launch.json tasks like this: As of the latest version with the local patch discussed here applied, I don't need to do this anymore however. It might have to do with how I load rbenv in the zsh configurations files. (I did moved it to the global zsh config file) Sorry I can't be more specific, I am really not familiar with chruby, but at least you have a lead to explore... |
|
Ya selecting |
|
It looks like we have 2 separate issues being discussed here
|
|
@miharekar solution worked for me (not loading iterm shell integration), although Output still have some errors: is it possible to at least control what shell profile to use? |
|
I apologize for any inconvenience, everyone. I will be discussing a solution to address these issues with the original author. Please bear with us a moment. |
|
I'm seeing this same issue but I'm using bash. 
Setting the Ruby Version Manager to rbenv also gives me an infinite loop like others have reported. |
|
Hi guys, Wrap your shell integration initialization in the following condition: This will prevent the shell integration from being loaded when the parent process is VSCode. I encountered the same problem while playing with the TypeProf extension, so my guess is that this will be a very common occurence in the Ruby world. I suggest you put something about this somewhere in the extension documentation so people can solve this easily. HTH |
|
Hello there, Apologies for the delay in response, Following a through discussion, we have determined that addressing this issue involves resolving the version manager. Consequently, if you encounter the problem, we recommend utilizing the version manager as a solution. The latest version of our extension now incorporates an updated version manager, ensuring seamless functionality without any issues. We appreciate your patience throughout this process. Should you have any further inquiries, please do not hesitate to reach out. Thank you. I would like to express special appreciation to @plfoley for his dedicated efforts in assisting with this issue. |
|
For anyone finding this thread, the issue for me was A good way to avoid this problem is to define a special environment variable in "env": {
"TERM_PROGRAM": "vscode",
}Then, in |
When using zsh as the login shell, attaching to a running instance of Rails using UNIX Socket fails with the following error:
connect ENOENT 1337;RemoteHost=<user>@<machine>.local 1337;CurrentDir=/Users/<user>/<repoDir> 1337;ShellIntegrationVersion=13;shell=zsh/var/folders/9v/<TempDir>/ruby-debug-sock-501/ruby-debug-<user>-7957macOS 13.4
VSCode 1.78.2
rdbg 1.7.1 & 1.8.0
Ruby 2.7.8
Rails 6.0.6
It work fine in version 0.1.0. It got broken in version 0.2.0
It is possible to attach to the process using TCP/IP but no breakpoint will be hit. It is however possible to break on exception when connected in this manner on version 0.2.1.
As reported in this issue, there is no issue when using bash as the login shell on with version 0.2.1
The text was updated successfully, but these errors were encountered: