Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Feature Request: Push debugger activation to first breakpoint hit instead of `require "debug"`

Ouverte
#797 18 commentaires 9 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
ruby
Domaine
devtools

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 as require "debug/prelude"
  • require "debug/open" and require "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.readlines and could break when this line is triggered in the background.
  • There's also weird NoMethodError exceptions 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 requiring debug/open after the app is booted, require: false is 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

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ruby/debug

Toutes les issues de ruby/debug

Issues similaires

Plus d'issues Ruby

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.