Your environment
ruby -v: 3.1.0
rdbg -v: 1.6.0
Describe the bug
When the debuggee application has multiple processes, line breakpoints added to 1 of them won't be shared to other processes.
This will cause inconsistent breakpoint stop because only that process will stop and others won't.
To Reproduce
This issue should happen to any application that:
- Has multiple processes
- Uses line breakpoints
But reproducing it with VSCode is easier:
-
Create a new rails application
-
In config/puma.rb, set
threads 1, 1 # limit the threads number to 1 will increase the reproduction chance
# other configs
workers 5 # increase this number will also help reproduction
-
Start the server with bundle exec rdbg -c -- bundle exec rails s
-
Set a breakpoint
-
Attach the debugger
-
Sending requests to the Rails app
-
The breakpoint should stop at some requests but not all of them
Expected behavior
The breakpoints should stop at every request
Additional context
@ko1 mentioned that:
- Resolving this will require rewriting a big part of the process handling mechanism
- Possible workarounds: 1) Use only 1 process or 2) For VSCode users, use launch mode instead
- There are no timeline for this issue yet (probably not before Ruby 3.2 is out)
Your environment
ruby -v:3.1.0rdbg -v:1.6.0Describe the bug
When the debuggee application has multiple processes, line breakpoints added to 1 of them won't be shared to other processes.
This will cause inconsistent breakpoint stop because only that process will stop and others won't.
To Reproduce
This issue should happen to any application that:
But reproducing it with VSCode is easier:
Create a new rails application
In
config/puma.rb, setStart the server with
bundle exec rdbg -c -- bundle exec rails sSet a breakpoint
Attach the debugger
Sending requests to the Rails app
The breakpoint should stop at some requests but not all of them
Expected behavior
The breakpoints should stop at every request
Additional context
@ko1 mentioned that: