Does not play well with RubyMine (possibly VSCode rdbg) Debugger

[jbaxendale-ut]

What did you do?

I enabled Freezolite in a Rails app using Bootsnap and attempted to debug the Rails server with RubyMine.

I tried normal IDE gutter breakpoints in application code while serving a request that definitely executed that
code. I also tried moving require "freezolite/auto" from early boot to after Bundler.require(...), but the
debugger behavior did not change.

To narrow it down, I verified that:

• RubyMine/debase had attached to the server process.
• Pause worked.
• Exception breakpoints worked.
• The configured line breakpoint was registered and considered valid.
• The file path matched the method source_location.
• A broad manual TracePoint.new(:line) for the same file/line did fire.
• Removing Freezolite resolved the issue.

What did you expect to happen?

RubyMine/debase line breakpoints should stop execution when the Rails server executes the matching application code.

What actually happened?

RubyMine attached to the Rails server process, but normal IDE gutter breakpoints in application code did not stop execution.

The server continued to run and serve requests. The debugger was not completely broken: pause worked, exception breakpoints worked, and debugging specs still worked. The failure seemed isolated to normal line breakpoints in the Rails server process.

The interesting part is that a broad manual Ruby TracePoint(:line) did fire for the same file/line, but the IDE/
debase targeted breakpoint did not.

Additional context

From looking at Freezolite’s implementation, this does not seem like a simple line-number offset from inserting # frozen_string_literal: true. In the normal mode I was using, Freezolite appears to install RequireHooks wrappers and temporarily change RubyVM::InstructionSequence.compile_option around file loads.

Since debase line breakpoints target specific RubyVM::InstructionSequence objects, my suspicion is that there is an interaction between Freezolite/RequireHooks/Bootsnap and the instruction sequences debase attaches breakpoints to.

I was not using Freezolite’s experimental constant-freezing/source-transform mode.

Environment

Ruby Version: 3.4.9

Framework Version (Rails, whatever): Rails app using Bootsnap

Freeze The Lits Version: Freezolite 0.7.0

Sample Project

https://github.com/jbaxendale-ut/freezolite-debug

[jbaxendale-ut]

FYI: I said "possibly VSCode" as I haven't re-tested that flow yet since removing the gem, just noticed that it similarly struggled to attach -- but I will give it a run through as well.

[jbaxendale-ut]

Also I don't expect you to necessarily fix this, but maybe want to call out this out as one of the snags of using it like the other notes and figured I would help with the demonstration :)

[palkan]

Hey,

Thanks for reporting!

Yeah, I'm afraid it has something with iseqs.

First thing I would suggest is to upgrade to Ruby 3.4.10 (there were some fixes regarding iseqs also discovered by freezolite; maybe, related).

Then, if you can upgrade to 3.4.10, I'd give Bootsnap's new built-in support for freezing literals a try (instead of Freezolite): https://github.com/rails/bootsnap#custom-compilers

[jbaxendale-ut]

Ah, we are already on Ruby 4.0 (since I reported this) and I didn't realize that Bootsnap added this handling built in. I will give it a peek, thanks!

[skatkov]

I ran into, as it seem, similar issue, when Freezolite seemed to break the coverage report tool. I tried using the latest SimpleCov, but it could be reproduced without it.

Here is a repro:
https://github.com/skatkov/rails-freezolite-coverage-issue

[palkan]

@skatkov Thanks for the reproduction! The coverage issue has been fixed in Ruby 4.0.4:

$ ruby -v
ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [aarch64-linux]

$ bunld exec simplecov run bin/rails test test/models/greeting_test.rb
Running 1 tests in a single process (parallelization threshold is 50)
Run options: --seed 58871

# Running:

.

Finished in 0.003604s, 277.4492 runs/s, 277.4492 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
Coverage report generated for Unit Tests to coverage/index.html
Line coverage: 3 / 8 (37.50%)

$ bundle exec simplecov coverage app/models/greeting.rb --no-color
app/models/greeting.rb
  Line:   100.00% (3 / 3)

So, the best solution is to upgrade to Ruby 4.0.4+ (or Ruby 3.4.10+ for those using 3.4.x series).

For older Ruby releases, you can enable eval coverage to fix it:

  # .simplecov
  SimpleCov.load_profile "rails"
  SimpleCov.cover "app/**/*.rb"
+ SimpleCov.enable_coverage :eval