Project

General

Profile

Actions
Copy link

Bug #21854

closed

ruby-prof breaks on 4.0.1

Bug #21854: ruby-prof breaks on 4.0.1

Added by cfis (Charlie Savage) 25 days ago. Updated 23 days ago.

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
[ruby-core:124638]

Description

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:

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]

Related issues 1 (0 open — 1 closed)

Related to Ruby - Bug #21710: Segfault when reading object_id after it is set inside RUBY_INTERNAL_EVENT_NEWOBJClosedActions

Updated by cfis (Charlie Savage) 25 days ago Actions
Copy link
 #1

  • Description updated (diff)

Updated by cfis (Charlie Savage) 25 days ago Actions
Copy link
 #2

  • Description updated (diff)

Updated by jhawthorn (John Hawthorn) 25 days ago · Edited Actions
Copy link
 #3 [ruby-core:124641]

  • 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

Updated by cfis (Charlie Savage) 25 days ago · Edited Actions
Copy link
 #4 [ruby-core:124643]

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).

Updated by cfis (Charlie Savage) 25 days ago · Edited Actions
Copy link
 #5 [ruby-core:124644]

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?

Updated by jhawthorn (John Hawthorn) 24 days ago Actions
Copy link
 #6 [ruby-core:124645]

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.

Updated by Eregon (Benoit Daloze) 24 days ago Actions
Copy link
 #7

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

Updated by cfis (Charlie Savage) 23 days ago Actions
Copy link
 #8 [ruby-core:124654]

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

Actions
Copy link

Also available in: PDF Atom