From: nobu@... Date: 2016-11-13T02:28:47+00:00 Subject: [ruby-core:78102] [Ruby trunk Bug#12927][Closed] SIGSEGV during GC marking of sym procs Issue #12927 has been updated by Nobuyoshi Nakada. Status changed from Open to Closed Backport set to 2.1: UNKNOWN, 2.2: REQUIRED, 2.3: REQUIRED Seems already fixed in the trunk in a different way. ---------------------------------------- Bug #12927: SIGSEGV during GC marking of sym procs https://bugs.ruby-lang.org/issues/12927#change-61468 * Author: Emiliano Ritiro * Status: Closed * Priority: Normal * Assignee: * ruby -v: 2.3 * Backport: 2.1: UNKNOWN, 2.2: REQUIRED, 2.3: REQUIRED ---------------------------------------- After we migrated from Ruby 2.2.4 to Ruby 2.3.1 we started seeing a Segmentation Fault. This happens when the GC calls proc_mark() during the marking phase. The proc tries to mark the block.ep[1] which contains an invalid VALUE. I attached a script to reproduce the issue and the output of that script. (You have to run it a couple of times, it sigsevs 20% of the time) Follow are the conclusion of my analysis: The attached script duplicates a sym proc in memory (&:to_h) sym procs in Ruby 2.3 uses a cfunc_proc_t which puts its environment data at the end of the rb_proc_t struct. block->ep points to that environment. When you copy a proc (with dup_proc()), the new proc will have a block->ep pointing to the original cfunc_proc_t The sym_proc_cache prevents the corruption in most of the cases, but if we have a cache collision that replaces the original proc, and there are no other references to the original proc, the GC will collect the original proc, including its 64 bits of cfunc_proc_t, making them available for future use. The duplicated proc will still be pointing to the original env, which now is freed data that GC can assign to whatever it wants. If after that, this particular position of memory is filled with a VALUE that points outside of our memory, ruby aborts with a core dump. ---Files-------------------------------- segfault.rb (1.76 KB) output.txt (22 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: