Issue #15912 has been reported by deivid (David Rodr=EDguez).

----------------------------------------
Bug #15912: Allow some reentrancy during TracePoint events
https://bugs.ruby-lang.org/issues/15912

* Author: deivid (David Rodr=EDguez)
* Status: Open
* Priority: Normal
* Assignee: =

* Target version: =

* ruby -v: ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
I got a report in byebug about byebug being incompatible with zeitwerk. Thi=
s one: https://github.com/deivid-rodriguez/byebug/issues/564. This is a pro=
blem because zeitwerk is the default Rails code loader, and byebug is the d=
efault Rails debugger.

Both of these tools rely on the TracePoint API:

* Byebug uses a bunch of TracePoint events to stop execution at certain poi=
nts in your program.
* Zeitwek uses `:class` events to be able to resolve some circular edge cas=
es.

I investigated the problem and I think the issue is that while stopped at t=
he byebug prompt, we're actually in the middle of processing a TracePoint e=
vent. That means that further TracePoint events triggered at the byebug's p=
rompt will be ignored, because otherwise we could get into an infinite loop=
 where the handling of events would trigger more events that trigger themse=
lves the execution of handlers again.

I understand why the TracePoint API does this, but if we could allow some l=
evel of reentrancy here, we could probably make these tools play nice toget=
her. I figure if we kept a stack of TracePoint event handlers being run, an=
d check that the current event type is not already in the stack, we would a=
llow :class events to be triggered from :line events, and I think that woul=
d allow Zeitwerk to work within byebug.

What do you think about this, @ko1?



-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>