Deadlock after issuing `Net::HTTP.get` request and using a Ruby Debug breakpoint after the request

[Chaseshak]

We noticed a thread deadlock issue with Ruby debug after our net/http version changed from 0.2.0 to 0.3.0.

When you are in the breakpoint after making any http request and you attempt to fetch your debug history (e.g. you arrow key up a few times), it crashes.

This error occurs in Ruby 3.1.3 which is using net-http (0.3.0). It does not occur in Ruby 3.1.2 (or earlier) which is using net-http (0.2.0).

Reproduction script (using net-http 0.3.0 or higher):

require "debug"
require "net/http"

Net::HTTP.get(URI.parse("https://google.com"))

binding.b

Stack trace:

["DEBUGGER Exception: .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:1233",
 #<fatal: No live threads left. Deadlock?
3 threads, 3 sleeps current:0x000000014a83b950 main thread:0x000000015a6048e0
* #<Thread:0x0000000100ec4d10 sleep_forever>
   rb_thread_t:0x000000015a6048e0 native:0x00000001faaf9b40 int:0

* #<Thread:0x000000010107e4a8@DEBUGGER__::SESSION@server .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/session.rb:177 sleep_forever>
   rb_thread_t:0x000000014a83b950 native:0x000000016f393000 int:0

* #<Thread:0x0000000104d64548@Timeout stdlib thread .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/timeout-0.3.1/lib/timeout.rb:101 sleep_forever>
   rb_thread_t:0x000000014a9f1ce0 native:0x000000016f59f000 int:0

>,
 [".rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:874:in `pop'",
  ".rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:874:in `wait_next_action_'",
  ".rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:856:in `wait_next_action'",
  ".rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:320:in `suspend'",
  ".rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:251:in `on_breakpoint'",
  ".rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:69:in `suspend'",
  ".rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:178:in `block in setup'",
  ".rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/session.rb:2586:in `debugger'",
  "test.rb:6:in `<main>'"]]
.rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:874:in `pop': No live threads left. Deadlock? (fatal)
3 threads, 3 sleeps current:0x000000014a83b950 main thread:0x000000015a6048e0
* #<Thread:0x0000000100ec4d10 sleep_forever>
   rb_thread_t:0x000000015a6048e0 native:0x00000001faaf9b40 int:0

* #<Thread:0x000000010107e4a8@DEBUGGER__::SESSION@server .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/session.rb:177 sleep_forever>
   rb_thread_t:0x000000014a83b950 native:0x000000016f393000 int:0

* #<Thread:0x0000000104d64548@Timeout stdlib thread .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/timeout-0.3.1/lib/timeout.rb:101 sleep_forever>
   rb_thread_t:0x000000014a9f1ce0 native:0x000000016f59f000 int:0

	from .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:874:in `wait_next_action_'
	from .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:856:in `wait_next_action'
	from .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:320:in `suspend'
	from .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/thread_client.rb:251:in `on_breakpoint'
	from .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:69:in `suspend'
	from .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:178:in `block in setup'
	from .rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/debug-1.7.1/lib/debug/session.rb:2586:in `debugger'
	from test.rb:6:in `<main>'

[ko1]

Could you try latest debug.gem 1.8.0?

[Chaseshak]

Hi @ko1, thanks for the response!

I just tried this with debug 1.8.0 and I still get the deadlock error above.