Pending MethodBreakpoint

[ko1]

When we set a method breakpoint with break C.foo and If the C or C.foo is not defined, it will be a pending breakpoint and when C.foo is activated, it will be activated.

We can set breakpoint with any expression like:

[1, 7] in target.rb
      1|
      2| def (o = '').s
      3|   :s
      4| end
      5|
=>    6| p o.s
      7| __END__
=>#0    <main> at target.rb:6
(rdbg:commands) b o.s
#0  BP - Method  o.s at target.rb:2

(rdbg) c
[1, 7] in target.rb
      1|
      2| def (o = '').s
=>    3|   :s
      4| end
      5|
      6| p o.s
      7| __END__
=>#0    .s at target.rb:3
  #1    <main> at target.rb:6

Stop by #0  BP - Method  o.s at target.rb:2

In this case, user can set a breakpoint with current context (lvar o).

The problem is, if we write an expression which does not valid, the breakpoint will be registered as a pending breakpoint.

(rdbg) b not_lvar.foo
undefined local variable or method `not_lvar' for "":String
#1  BP - Method (pending)  not_lvar.foo

Maybe it will not be activated in future.

This is useful for singleton method:

[master]$ exe/rdbg target.rb  -e 'b C.foo'
DEBUGGER: Session start (pid: 19219)
[1, 7] in target.rb
      1|
=>    2| class C
      3|   def self.foo
      4|   end
      5| end
      6|
      7| __END__
=>#0    <main> at target.rb:2
(rdbg:commands) b C.foo
uninitialized constant C
#0  BP - Method (pending)  C.foo

(rdbg) c
DEBUGGER:  BP - Method  C.foo at target.rb:3 is activated.

At first, C is not defined so it will be a pending breakpoint. After that C.foo is defined and the breakpoint will be activated.

b expr.method has two usecases:

• (1) want to set breakpoint to the current context
• (2) want to set singleton class

For (1), it should not make a pending breakpoint. For (2),, it should.

We can not recognize the purpose for (1) and (2) now.

Ideas:

• If the expression is like Constant, allow to make pending.
  • It saves (2).
  • Not complete for (1)
• Add option to recognize 1 and 2.
  • break --allow-pending C.foo for (2).
  • Too long...

[ko1]

Line breakpoint also makes pending with non-existing files. It seems same problem so current behavior is possible to keep. And idea 1 is more kind.

[st0012]

Just to understand the context: what's the main concern of having pending breakpoints that may not be activated? If they're not activated (TracePoint not enabled), the performance impact should be minimum I think?

[ko1]

For pending MethodBreakpoint, it introduces performance penalty to observe new method definitions.