Feature Request: Push debugger activation to first breakpoint hit instead of `require "debug"`
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 35/100
Piste de recherche
Start by reading lib/debug.rb and the Kernel#debugger implementation in lib/debug/session.rb, then trace how require "debug", require "debug/prelude", and the open variants initialize sessions. Verify the proposed behavior against activation, TracePoint, thread, UI, and forking-message concerns described in the issue. Done means requiring debug is passive while the first breakpoint activates the debugger without changing the open variants.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Proposal
require "debug"won't activate the debugger. Debugger will only be activated when the first breakpoint is triggered.require "debug"will be the same asrequire "debug/prelude"
require "debug/open"andrequire "debug/open_nonstop"'s behaviour will remain the same.
Why
Side-effects
In apps that have Bundler.require, like most Rails apps, having gem "debug" in Gemfile means the debug gem is always activated when the app is booted.
However, with the debugger's activation, many things will happen in the background:
- Additional
TracePoints would be enabled (example) - A new thread will be spawned
- Additional computation and object allocation that come with the above
To most apps, having them in the background doesn't make a huge difference. But to some, having the debugger activated causes tests to fail.
For example, I tested 5 mid-to-large Rails apps in Shopify, and 3 of them have test failures that only happen when debug is activated:
- Some tests mock
File.readlinesand could break when this line is triggered in the background. - There's also weird
NoMethodErrorexceptions that only happens with the debugger activated.
Therefore, we always have require: false after gem "debug".
Problem Solved?
However, having require: false means users need to manually type require "debug" before start debugging with console. But in the meantime, byebug can be required by default without the same side-effects. So byebug doesn't need that manual require.
This extra require step is quite inconvenient for people considering switching from byebug to debug.
Other Smaller Issues
- The activation and forking messages are noisy and disabling them project-by-project is not trivial.
require "debug"locks the UI to console, so if users want to use the remote UI by requiringdebug/openafter the app is booted,require: falseis also needed.
Possible Change
diff --git a/lib/debug.rb b/lib/debug.rb
index 15ebccb..3489268 100644
--- a/lib/debug.rb
+++ b/lib/debug.rb
@@ -1,5 +1,3 @@
# frozen_string_literal: true
require_relative 'debug/session'
-return unless defined?(DEBUGGER__)
-DEBUGGER__::start no_sigint_hook: true, nonstop: true
diff --git a/lib/debug/session.rb b/lib/debug/session.rb
index a900f89..ffb2604 100644
--- a/lib/debug/session.rb
+++ b/lib/debug/session.rb
@@ -2486,7 +2486,9 @@ end
module Kernel
def debugger pre: nil, do: nil, up_level: 0
- return if !defined?(::DEBUGGER__::SESSION) || !::DEBUGGER__::SESSION.active?
+ if !defined?(::DEBUGGER__::SESSION) || !::DEBUGGER__::SESSION.active?
+ DEBUGGER__::start no_sigint_hook: true, nonstop: true
+ end
if pre || (do_expr = binding.local_variable_get(:do))
cmds = ['binding.break', pre, do_expr]
- 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
-
SyncEm always forwards a dummy block, so wrapped methods lose their no-block/Enumerator behavior Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
endoflife-date/endoflife.date#11086 ·
-
internal
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
Kong/developer.konghq.com#7322 ·
-
bug P2
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100