ReaderThreadError: wrong number of arguments (given 0, expected 1)
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 35/100
Piste de recherche
Start with the stack trace at debug/server_dap.rb:504 and follow the greeting and connection flow through debug/server.rb:156 and debug/server.rb:54-56. Reproduce with Ruby 3.3.6, debug 1.9.2, and the nested-breakpoint scenario if possible, then verify that continuing or disconnecting no longer leaves the debugger or Rails request hung and does not emit the ReaderThreadError.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Your environment
ruby -v: 3.3.6rdbg -v: 1.9.2- Inside docker (docker image
ruby:3.3.6-slim-bookworm@sha256:7a89be75c6768a888f70c90f4626366de90909c4e4d62729775ea3b64672547cto be exact) - Process started like:
bundle exec rdbg -O -n --session-name='web' -c -- bin/rails server -b 0.0.0.0 -p 3000RUBY_DEBUG_SOCK_DIR=/app/tmp(Rails root being/appinside container,/app/tmpis a volume mounted into container so socket can be attached to from outside container)
Describe the bug
Quite often during the course of debugging the debugger process seems to becomes in a paused state but unable to display the current thread or breakpoint. Rails requests hang even if disconnecting from the remote debugger (VSCode connecting via a socket).
After that point the main process becomes unresponsive and the only way to continue is to restart the parent process (which in our case means restarting the docker container).
To Reproduce
We have seen this arise sporadically. The following is one way we've been able to reproduce it but we have seen it occur even when avoiding the below:
-
When paused at a breakpoint, calling another method manually (or in a watch) which has its own breakpoints set will cause execution to run to and pause at the nested breakpoint, but continuing from there will break the debugger.
class Foo def a puts "hello" # BP 1 <= active 1 + 1 end def b 42 # BP 2 end end Foo.new.aGiven the following file with breakpoints set above, when stopped at
BP 1, callingbwill re-break atBP 2, but continuing from there seems to break the debugger and leave some thread in a hung state.
Again, this is just one cause but we have been able to reproduce it at times without any manual execution of methods with BPs. However, we do not have a reproduction case for this.
Expected behavior
The debugger doesn't hang
Additional context
When this is encountered, I disconnected VSCode's debugger and manually attached to the same debugger instance via rdbg -A socket. When doing so the debugger output shows:
root@b032c5a1c83b:/app> rdbg -A tmp/rdbg-7-web
(unknown) "Content-Length: 154\r\n"
(unknown) "\r\n"
(unknown) "{\"type\":\"event\",\"event\":\"output\",\"body\":{\"category\":\"console\",\"output\":\"DEBUGGER (client): Connected. PID:7, $0:bin/rails, session_name:web\\n\"},\"seq\":434}"
root@b032c5a1c83b:/app> # ^ exits
The application logs show:
DEBUGGER: Connected.
DEBUGGER: ReaderThreadError: wrong number of arguments (given 0, expected 1)
["/usr/local/lib/ruby/gems/3.3.0/gems/debug-1.9.2/lib/debug/server_dap.rb:504:in `puts'",
"/usr/local/lib/ruby/gems/3.3.0/gems/debug-1.9.2/lib/debug/server.rb:156:in `greeting'",
"/usr/local/lib/ruby/gems/3.3.0/gems/debug-1.9.2/lib/debug/server.rb:56:in `block (3 levels) in activate'",
"/usr/local/lib/ruby/gems/3.3.0/gems/debug-1.9.2/lib/debug/server.rb:54:in `synchronize'",
"/usr/local/lib/ruby/gems/3.3.0/gems/debug-1.9.2/lib/debug/server.rb:54:in `block (2 levels) in activate'",
"/usr/local/lib/ruby/gems/3.3.0/gems/debug-1.9.2/lib/debug/server.rb:506:in `block in accept'",
"/usr/local/lib/ruby/3.3.0/socket.rb:815:in `block (2 levels) in accept_loop'",
"/usr/local/lib/ruby/3.3.0/socket.rb:812:in `each'",
"/usr/local/lib/ruby/3.3.0/socket.rb:812:in `block in accept_loop'",
"<internal:kernel>:187:in `loop'",
"/usr/local/lib/ruby/3.3.0/socket.rb:810:in `accept_loop'",
"/usr/local/lib/ruby/3.3.0/socket.rb:1170:in `block in unix_server_loop'",
"/usr/local/lib/ruby/3.3.0/socket.rb:1124:in `unix_server_socket'",
"/usr/local/lib/ruby/3.3.0/socket.rb:1169:in `unix_server_loop'",
"/usr/local/lib/ruby/gems/3.3.0/gems/debug-1.9.2/lib/debug/server.rb:502:in `accept'",
"/usr/local/lib/ruby/gems/3.3.0/gems/debug-1.9.2/lib/debug/server.rb:49:in `block in activate'"]
DEBUGGER: Disconnected.
- Langage dominant
- Ruby
- Étoiles
- 1.3k
- Forks
- 146
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de ruby/debug
-
Difficulté 3/5 1-2 jours Accessibilité débutants 68/100
-
Support exceptionOptions in setExceptionBreakpoints to catch arbitrary exception classes via DAP Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 55/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 52/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
Toutes les issues de ruby/debug
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
simp/pupmod-simp-simp#395 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 80/100
simp/pupmod-simp-rsyslog#219 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
simp/pupmod-simp-pupmod#256 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
simp/pupmod-simp-sudo#150 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100