From: sam.saffron@... Date: 2017-07-26T21:30:34+00:00 Subject: [ruby-core:82185] [Ruby trunk Bug#13772] Memory leak recycling stacks for threads in 2.4.1 Issue #13772 has been updated by sam.saffron (Sam Saffron). valgrind reports tons of these: ==18152== 463,665 (86,200 direct, 377,465 indirect) bytes in 431 blocks are definitely lost in loss record 16,407 of 16,429 ==18152== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18152== by 0x14BECE: objspace_xcalloc (gc.c:7944) ==18152== by 0x170E12: iseq_alloc (iseq.c:215) ==18152== by 0x170E12: rb_iseq_new_with_opt (iseq.c:478) ==18152== by 0x2E3B2F: new_child_iseq (compile.c:1119) ==18152== by 0x2E3B2F: iseq_compile_each (compile.c:5835) ==18152== by 0x2E4499: iseq_compile_each (compile.c:3996) ==18152== by 0x2EE93B: rb_iseq_compile_node (compile.c:608) ==18152== by 0x170E53: rb_iseq_new_with_opt (iseq.c:483) ==18152== by 0x2E232C: new_child_iseq (compile.c:1119) ==18152== by 0x2E232C: iseq_compile_each (compile.c:5905) ==18152== by 0x2E4499: iseq_compile_each (compile.c:3996) ==18152== by 0x2E2CCE: iseq_compile_each (compile.c:6280) ==18152== by 0x2EDAA7: rb_iseq_compile_node (compile.c:651) ==18152== by 0x170E53: rb_iseq_new_with_opt (iseq.c:483) ---------------------------------------- Bug #13772: Memory leak recycling stacks for threads in 2.4.1 https://bugs.ruby-lang.org/issues/13772#change-65948 * Author: sam.saffron (Sam Saffron) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: 2.4.1 * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- Per: https://github.com/rest-client/rest-client/issues/611 gem install rest-client ``` 100000.times.each_slice(32) do |slice| slice.map { Thread.new { RestClient.get('echo.jsontest.com/key/value/one/two') } }.each(&:join) GC.start(full_mark: true, immediate_sweep: true) slots = GC.stat[:heap_live_slots] puts "slots #{slots} #{i+=1} threads #{Thread.list.count}" end ``` Causes unbound memory growth on 2.4.1, this was not the case in earlier versions of Ruby or Ruby master. When running through heaptrack and massif-visualizer it looks like all unreclaimed allocations come from thread_recycle_stack Ruby heaps do not grow during tests, all the growth is around unmanaged memory. I feel getting this sorted is urgent, we have seen similar leaks at Discourse. -- https://bugs.ruby-lang.org/ Unsubscribe: