michaelherold / benchmark-memory

Memory profiling benchmark style, for Ruby 2.1+
MIT License
217 stars 6 forks source link

Ractors benchmark memory seg fault #27

Closed PedroAugustoRamalhoDuarte closed 11 months ago

PedroAugustoRamalhoDuarte commented 1 year ago

Hello, thanks for this gem. I am trying to setup a memory benchmark with new ruby ractors and i its returns a segfault, maybe is a problem with ruby its self or memory-profiler

Ruby versions tested: 3.1 and 3.2.2

# frozen_string_literal: true
require 'benchmark'
require 'benchmark/memory' # gem install benchmark-memory

def factorial(n)
  n == 0 ? 1 : n * factorial(n - 1)
end

Benchmark.memory do |x|
  x.report('ractors:') do
    ractors = []
    4.times do
      ractors << Ractor.new do
        1000.times { factorial(1000) }
      end
    end
    # take response from ractor, so it will actually execute
    ractors.each(&:take)
  end
end
Calculating -------------------------------------
main.rb:104: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
[BUG] Segmentation fault at 0x0000000000000000
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]

-- Control frame information -----------------------------------------------
michaelherold commented 12 months ago

This is due to memory_profiler not supporting Ractors. I'm not sure what the source of the segfault is, but when I change your example to the following, I experience the same segfault:

# frozen_string_literal: true

require "memory_profiler"

def factorial(n)
  n == 0 ? 1 : n * factorial(n - 1)
end

MemoryProfiler.start

ractor = Ractor.new do
  1000.times { factorial(1000) }
end

# take response from ractor, so it will actually execute
ractor.take

MemoryProfiler.stop.pretty_print

I will file an issue upstream.

michaelherold commented 11 months ago

This is due to an issue in the VM of MRI that was reported and fixed for the upcoming 3.3 release. I verified this on the latest commit of Ruby's trunk.

The fix was back ported for 3.2 as well, but would be out in a 3.2.3 release, which has not yet been released.

There is a backport for 3.1 as well, which I assume is in the same state.

All that to say that this should not be a problem in Rubies newer than the ones out today.

I don't think the effort of catching a case where someone uses a Ractor in a benchmark is worth the effort so I will go ahead and close this for posterity.

Thanks for reporting!