Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

ReaderThreadError: wrong number of arguments (given 0, expected 1)

Aberta
  • Algo errado?
#1,123 2 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
35/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
ruby
Domínio
devtools

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Your environment

  • ruby -v: 3.3.6
  • rdbg -v: 1.9.2
  • Inside docker (docker image ruby:3.3.6-slim-bookworm@sha256:7a89be75c6768a888f70c90f4626366de90909c4e4d62729775ea3b64672547c to be exact)
  • Process started like: bundle exec rdbg -O -n --session-name='web' -c -- bin/rails server -b 0.0.0.0 -p 3000
    • RUBY_DEBUG_SOCK_DIR=/app/tmp (Rails root being /app inside container, /app/tmp is 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.a

    Given the following file with breakpoints set above, when stopped at BP 1, calling b will re-break at BP 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.
Linguagem predominante
Ruby
Estrelas
1.3k
Forks
146
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de ruby/debug

Todas as issues de ruby/debug

Issues semelhantes

Mais issues de Ruby

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.