Bug #21854: ruby-prof breaks on 4.0.1

• Status: Third Party's Issue
• Assignee: -
• Target version: -
• ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x64-mswin64_140]
• Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN

[cfis (Charlie Savage)]

ruby-prof breaks on 4.0.x with segmentation faults. See failing github pipelines:

https://github.com/ruby-prof/ruby-prof/actions/runs/21465420365/job/61826466398

(note the failures for ruby 3.x are some test that fail, not segmentation faults).

Tracking this down, I focused on the measure_memory_test.rb file. I have attached the traceback below. What is happening is:

• Get a tracearg event (https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_profile.c#L200)
• Get a measurement - time, memory, etc. - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measurement.c#L38
• Get the tracearg object - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure_memory.c#L21
• Call rb_obj_memsize_of - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure_memory.c#L23
• For a T_DATA object you end up in in gc.c

case T_DATA:
size += rb_objspace_data_type_memsize(obj);
break;

rb_objspace_data_type_memsize causes a segmentation fault.

Running in a debugger, with a breakpoing set in rb_objspace_data_type_memsize:

RTYPEDDATA_TYPE(obj)
0x332d747365676964 {wrap_struct_name=??? function={dmark=??? dfree=??? dsize=??? ...} parent=??? ...}
    wrap_struct_name: <Unable to read memory>
    function: {dmark=??? dfree=??? dsize=??? ...}
    parent: <Unable to read memory>
    data: <Unable to read memory>
    flags: <Unable to read memory>

The tracearg type is RUBY_INTERNAL_EVENT_NEWOBJ.

Here is the traceback. This is from a MSVC build, but you can see in the gitlab pipelines the same happens on Ubuntu.

-- C level backtrace information -------------------------------------------
C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007FF817DA1C44]
C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007FF814F2BC5F]
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_print_backtrace+0x3e) [0x00007FFEEBB01F92] C:\Source\ruby-4.0.1-mswin\vm_dump.c:1129
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_bugreport+0x223) [0x00007FFEEBB021BB] C:\Source\ruby-4.0.1-mswin\vm_dump.c:1453
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_bug_for_fatal_signal+0x75) [0x00007FFEEB9BE779] C:\Source\ruby-4.0.1-mswin\error.c:1131
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(sigsegv+0x3d) [0x00007FFEEBAFAF91] C:\Source\ruby-4.0.1-mswin\signal.c:948
C:\WINDOWS\System32\ucrtbase.dll(seh_filter_exe+0x84) [0x00007FF81591E8A4]
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(`__scrt_common_main_seh'::`1'::filt$0+0x16) [0x00007FF7B95D1B4C] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:304
C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll(_C_specific_handler+0x9d) [0x00007FFFF400F55D]
C:\WINDOWS\SYSTEM32\ntdll.dll(_chkstk+0x9f) [0x00007FF817DA62FF]
C:\WINDOWS\SYSTEM32\ntdll.dll(RtlLocateExtendedFeature+0x597) [0x00007FF817C52327]
C:\WINDOWS\SYSTEM32\ntdll.dll(KiUserExceptionDispatcher+0x2e) [0x00007FF817DA5C3E]
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_obj_memsize_of+0x1dc) [0x00007FFEEB9A2C8C] C:\Source\ruby-4.0.1-mswin\gc.c:2351
C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(measure_memory+0x51) [0x00007FFFA8427161] C:\Source\ruby-prof\ext\ruby_prof\rp_measure_memory.c:23
C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_measure+0x1a) [0x00007FFFA8425D8A] C:\Source\ruby-prof\ext\ruby_prof\rp_measurement.c:38
C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_event_hook+0x43) [0x00007FFFA842AC23] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:200
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(tp_call_trace+0x26) [0x00007FFEEBA41E12] C:\Source\ruby-4.0.1-mswin\vm_trace.c:1300
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(exec_hooks_body+0x74) [0x00007FFEEBA3FCA4] C:\Source\ruby-4.0.1-mswin\vm_trace.c:457
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_exec_event_hooks+0x4a) [0x00007FFEEBA40326] C:\Source\ruby-4.0.1-mswin\vm_trace.c:543
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_gc_event_hook+0xc1) [0x00007FFEEB99DE35] C:\Source\ruby-4.0.1-mswin\gc.c:241
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(newobj_of+0x17c) [0x00007FFEEB99C348] C:\Source\ruby-4.0.1-mswin\gc.c:1014
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(typed_data_alloc+0xb6) [0x00007FFEEB9A565A] C:\Source\ruby-4.0.1-mswin\gc.c:1102
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_data_typed_object_zalloc+0x3b) [0x00007FFEEB99D877] C:\Source\ruby-4.0.1-mswin\gc.c:1125
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_managed_id_table_create+0x21) [0x00007FFEEBA2AF2D] C:\Source\ruby-4.0.1-mswin\id_table.c:375
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(callable_method_entry_or_negative+0x299) [0x00007FFEEB9C434D] C:\Source\ruby-4.0.1-mswin\vm_method.c:1918
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(callable_method_entry+0x9) [0x00007FFEEB9C4081] C:\Source\ruby-4.0.1-mswin\vm_method.c:1937
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_populate_cc+0x2a) [0x00007FFEEB9E1CF2] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2155
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_search_method_slowpath+0x7d) [0x00007FFEEB9D0D21] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2299
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_search_method_slowpath0+0x20) [0x00007FFEEB9E261C] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2321
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x14e) [0x00007FFEEB9E2B2E] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6123
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_protect+0x14a) [0x00007FFEEB9B8DFA] C:\Source\ruby-4.0.1-mswin\eval.c:1127
C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_profile_instance+0x58) [0x00007FFFA842C128] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:820
C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_profile_class+0x2f) [0x00007FFFA842C19F] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:845
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_other+0xbc) [0x00007FFEEB9D5154] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3976
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc+0x103) [0x00007FFEEB9D4E67] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:4057
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_method_each_type+0x67b) [0x00007FFEEB9D7503] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:4888
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_method+0x14c) [0x00007FFEEB9D6E68] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:5052
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ary_each+0x7f) [0x00007FFEEBA1A083] C:\Source\ruby-4.0.1-mswin\array.c:2754
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ary_collect+0xa4) [0x00007FFEEBA18F38] C:\Source\ruby-4.0.1-mswin\array.c:3767
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_invoke_proc+0x304) [0x00007FFEEB9DF6D8] C:\Source\ruby-4.0.1-mswin\vm.c:1944
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_invoke_proc+0x95) [0x00007FFEEB9CFCE9] C:\Source\ruby-4.0.1-mswin\vm.c:1967
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_proc_call_kw+0x70) [0x00007FFEEBAADD6C] C:\Source\ruby-4.0.1-mswin\proc.c:1134
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(exec_end_procs_chain+0x3d) [0x00007FFEEB9B5B4D] C:\Source\ruby-4.0.1-mswin\eval_jump.c:106
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_exec_end_proc+0x13b) [0x00007FFEEB9B73AF] C:\Source\ruby-4.0.1-mswin\eval_jump.c:122
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_teardown+0x11e) [0x00007FFEEB9B789A] C:\Source\ruby-4.0.1-mswin\eval.c:158
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_cleanup+0x260) [0x00007FFEEB9B6C68] C:\Source\ruby-4.0.1-mswin\eval.c:211
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(ruby_run_node+0x4d) [0x00007FFEEB9B998D] C:\Source\ruby-4.0.1-mswin\eval.c:321
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(wmain+0x52) [0x00007FF7B95D1052] C:\Source\ruby-4.0.1-mswin\main.c:48
C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(__scrt_common_main_seh+0x10c) [0x00007FF7B95D126C] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
C:\WINDOWS\System32\KERNEL32.DLL(BaseThreadInitThunk+0x17) [0x00007FF816AEE8D7]

[cfis (Charlie Savage)]

• Description updated (diff)

[cfis (Charlie Savage)]

• Description updated (diff)

[jhawthorn (John Hawthorn)]

• Status changed from Open to Third Party's Issue

I would argue that this is a bug in ruby-prof. RUBY_INTERNAL_EVENT_NEWOBJ is an internal event, so the semantics of exactly when it fires and the state the object is in are not documented and may change. In Ruby 4.0 (specifically https://github.com/ruby/ruby/commit/74075617b17ab80db74a5e7c1c8515601a8ce6f4) we moved initialization of the three VALUEs following flags and klass to after this runs, so RUBY_INTERNAL_EVENT_NEWOBJ sees these objects in a not fully initialized state (which was always the case, they're just more uninitialized now).

I think ruby-prof should not do this. It doesn't make sense to call memsize_of on object immediately after it's allocated anyways. For almost all types that memsize_of returns something other than the slot size those values aren't filled in until after the NEWOBJ event fires (even on 3.4 and below), so whatever results this is reporting are bogus.

IMO Long term nothing should be supported on the object passed to RUBY_INTERNAL_EVENT_NEWOBJ other than making note of the object's address. We had some similar discussions in #21710

[cfis (Charlie Savage)]

Thanks for the update @jhawthorn (John Hawthorn) and link.

Do you have a recommendation for what ruby-prof should do instead? ~~ Maybe it is simple as listen only for NEWOBJ?~~ This feature was added to ruby-prof 7 years ago, so I would prefer not to all of a sudden yank it out.

The idea is to profile the amount and size of objects created by each method (other modes are measure time, number of allocations, etc).

[cfis (Charlie Savage)]

Ok, looking at the exposed events, there does not seem to be one that lets you know when an object is created. Can an "official" one be added?

If ruby-prof tracked the object ids for each RUBY_INTERNAL_EVENT_NEWOBJ call and then asked for their size on RUBY_INTERNAL_EVENT_FREEOBJ would that work? Or is the object already invalid at that point?

[jhawthorn (John Hawthorn)]

Do you have a recommendation for what ruby-prof should do instead? ~~ Maybe it is simple as listen only for NEWOBJ?~~ This feature was added to ruby-prof 7 years ago, so I would prefer not to all of a sudden yank it out.

Did it ever work correctly though? Testing ruby-prof 1.7.2 on Ruby 3.4.7...

def a; "a" * 280; end
def b; "b" * 10_000; end
profile = RubyProf.profile(measure_mode: RubyProf::MEMORY) { a;b;a;b }
RubyProf::GraphPrinter.new(profile).print

Measure Mode: memory
Thread ID: 38472
Fiber ID: 38464
Total Time: 882.0
Sort by: total_time

  %total   %self      total       self       wait      child            calls     name                          location
------------------------------------------------------------------------------------------------------------------------------------------------------
 100.00%   0.00%    882.000      0.000      0.000    882.000                1     [global]#                      (irb):19
                    720.000     80.000      0.000    640.000              2/2     Object#a
                    162.000     80.000      0.000     82.000              2/2     Object#b
------------------------------------------------------------------------------------------------------------------------------------------------------
                     82.000     82.000      0.000      0.000              2/4     Object#b
                    640.000    640.000      0.000      0.000              2/4     Object#a
  81.86%  81.86%    722.000    722.000      0.000      0.000                4     String#*
------------------------------------------------------------------------------------------------------------------------------------------------------
                    720.000     80.000      0.000    640.000              2/2     [global]#
  81.63%   9.07%    720.000     80.000      0.000    640.000                2     Object#a                       (irb):17
                    640.000    640.000      0.000      0.000              2/4     String#*
------------------------------------------------------------------------------------------------------------------------------------------------------
                    162.000     80.000      0.000     82.000              2/2     [global]#
  18.37%   9.07%    162.000     80.000      0.000     82.000                2     Object#b                       (irb):18
                     82.000     82.000      0.000      0.000              2/4     String#*

This profile suggests that method a allocated 640 bytes, which is correct (it allocates two 320 byte objects, as those can hold the 280 byte strings plus metadata). But it incorrectly suggests that method b allocated 82 bytes (it does allocate two 40 byte objects, but the bulk of that 10000 byte string comes from malloc memory... I have no idea where the extra two bytes come from).

We could also consider this example of why even if NEWOBJ received full initialized objects (which it never has), it can't report all memory allocated:

a = [] # NEWOBJ for one allocation, 40 bytes
10_000_000.times { a << nil } # NEWOBJ is never fired here, but we allocate 80+MB via malloc
a.clear # empty it for good measure so that we can't even see it on FREEOBJ

What are you hoping to measure? To me memsize makes sense when trying to estimate the size of all retained objects at a certain point (to reduce memory usage), but I'm not sure of the utility of measuring allocated bytes as a rate or total. Most Ruby profilers measure the number of allocated objects (incrementing by one when the NEWOBJ hook is fired, or using GC.stat), as that's a reasonable (though also flawed) proxy of how often GC will run. I think that usage is likely to remain safe.

[Eregon (Benoit Daloze)]

• Related to Bug #21710: Segfault when reading object_id after it is set inside RUBY_INTERNAL_EVENT_NEWOBJ added

[cfis (Charlie Savage)]

Ok - I will remove this functionality from ruby-prof then.