ruby-debug / ruby-debug-ide

An interface which glues ruby-debug to IDEs like Eclipse (RDT), NetBeans and RubyMine.
https://www.jetbrains.com/ruby/features/ruby_debugger.html
Other
371 stars 83 forks source link

Rails server hangs, doesn't stop at breakpoints #208

Open elliotwesoff opened 3 years ago

elliotwesoff commented 3 years ago

I have three problematic scenarios, and all are preventing me from properly debugging the server using VSCode and Docker.

Scenario 1: I start the server in the container using rdebug-ide --host 0.0.0.0 --port 6969 --dispatcher-port 6969 -- bin/rails s -p 3000 -b 0.0.0.0

When I attach the IDE, the server starts normally. When I try to make a request, it hangs and doesn't reach the breakpoint in VSCode. Eventually the console will print timeout messages:

[87] Puma starting in cluster mode...
[87] * Version 3.12.0 (ruby 2.6.5-p114), codename: Llamas in Pajamas
[87] * Min threads: 5, max threads: 5
[87] * Environment: development
[87] * Process workers: 2
[87] * Preloading application
[87] * Listening on tcp://0.0.0.0:3000
[87] Use Ctrl-C to stop
[87] ! Terminating timed out worker: 89
[87] ! Terminating timed out worker: 91
[87] ! Terminating timed out worker: 93
[87] ! Terminating timed out worker: 95
[87] ! Terminating timed out worker: 97
[87] ! Terminating timed out worker: 99
[87] ! Terminating timed out worker: 101
[87] ! Terminating timed out worker: 103

Scenario 2: I start the server without the dispatcher port using rdebug-ide --host 0.0.0.0 --port 6969 -- bin/rails s -p 3000 -b 0.0.0.0

I attach the IDE and the server then operates normally when it receives requests, but will not stop on VSCode breakpoints.

Scenario 3: I use docker-compose to start the container using the configuration:

app:
    command: bundle exec rdebug-ide --host 0.0.0.0 --port 6969 -- bin/rails s -p 3000 -b 0.0.0.0
    ports:
      - "3001:3000"
      - "6969:6969"
      - "26162:26162"
    volumes:
      - dir:/code

The server operates normally, and hangs for the requests where breakpoints are set, but breakpoints aren't reached in VSCode.

I see people using the same port as configured in the launch.json for the dispatcher port, and I also see them using 26162, which seems like a VSCode-internal debugging port. Which one should be used? Any other ideas what's wrong with my configuration?

Nowaker commented 3 years ago

Hitting the same problem with VS Code recently. Just a couple days.

Nowaker commented 3 years ago

My environment is: Puma 4.2.0, Rails 5.0, 5.1, 5.2

Nowaker commented 3 years ago

Are you using windows?

No. Arch Linux.

The debugger will flag your breakpoint when it hits the file on that line, but since the file doesn't exist for the unix system, it will never break

Are you actually staying on-topic? This is an issue about Rails server hanging when the code is about to hit the breakpoint. (Browsing to a location that would not break will not hang the server)

If this is offtopic, please create a new ticket, and preferably submit a PR since you seem to have a solution to the issue you are facing.

saviu-u commented 3 years ago

I missed the topic then, sorry, I'm removing the comment

elliotwesoff commented 3 years ago

In case this is a question of environment, this was on Pop OS, an Ubuntu based distro geared toward dev work. I haven't tested this on any other OS.

drmdrew commented 3 years ago

I wonder if this issue is due to puma running in cluster mode versus single mode?

Setting PUMA_WORKERS=0 may help in this case like it did here... worth checking at least: