[#85349] [Ruby trunk Bug#14334] Segmentation fault after running rspec (ruby/2.5.0/erb.rb:885 / simplecov/source_file.rb:85) — pragtob@...
Issue #14334 has been updated by PragTob (Tobias Pfeiffer).
3 messages
2018/02/02
[#85358] Re: [ruby-cvs:69220] nobu:r62039 (trunk): compile.c: unnecessary freezing — Eric Wong <normalperson@...>
[email protected] wrote:
5 messages
2018/02/03
[#85612] Why require autoconf 2.67+ — leam hall <leamhall@...>
Please pardon the intrusion; I am new to Ruby and like to pull the
6 messages
2018/02/17
[#85616] Re: Why require autoconf 2.67+
— Vít Ondruch <v.ondruch@...>
2018/02/18
VGhpcyBjb3VsZCBoZWxwIHlvdSB0byBidWlsZCBSdWJ5IHdpdGggb2xkZXIgYXV0b2NvbmYgKDIu
[#85634] [Ruby trunk Bug#14494] [PATCH] tool/m4/ruby_replace_type.m4 use AC_CHECK_TYPES for HAVE_* macros — normalperson@...
Issue #14494 has been reported by normalperson (Eric Wong).
3 messages
2018/02/19
[#85674] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — matz@...
Issue #13618 has been updated by matz (Yukihiro Matsumoto).
5 messages
2018/02/20
[#85686] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/02/20
[email protected] wrote:
[#85704] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Koichi Sasada <ko1@...>
2018/02/21
On 2018/02/20 18:06, Eric Wong wrote:
[ruby-core:85442] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
From:
Eric Wong <normalperson@...>
Date:
2018-02-06 10:00:00 UTC
List:
ruby-core #85442
Eric Wong <[email protected]> wrote: > [email protected] wrote: > > https://bugs.ruby-lang.org/issues/14357 > > > > The thread_safe gem is not maintained anymore, but I don't see > > any reason why its test suite should segfault with Ruby 2.5. > > Right, no 3rd-party C exts loaded and I hit this in trunk, too. > Using -fsanitize=address reveals use-after-free in st.c > Investigating, but maybe Vladimir can find it sooner. Maybe my initial investigation was correct, after all. valgrind takes forever, but indicates the free is caused by rebuild_table; so it doesn't look like we missed GC marking during rebuild. Disabling the free(tab->entries) at line st.c:792 (patch below) seems to indicate success with the thread_safe test suite (letting it loop overnight). Looks like the new_tab != tab case of rebuild is leaving a hanging reference somewhere. ==9885== Thread 32 cache_loops_sp*: ==9885== Invalid read of size 8 ==9885== at 0x235622: find_table_entry_ind (st.c:873) ==9885== by 0x236C95: st_lookup (st.c:1049) ==9885== by 0x1520CE: rb_hash_aref (hash.c:853) ==9885== by 0x2A95E0: vm_opt_aref (vm_insnhelper.c:3650) ==9885== by 0x2A95E0: vm_exec_core (insns.def:1175) ==9885== by 0x2ACA83: vm_exec (vm.c:1790) ==9885== by 0x2AD875: invoke_block (vm.c:993) ==9885== by 0x2AD875: invoke_iseq_block_from_c (vm.c:1045) ==9885== by 0x2B64A8: invoke_block_from_c_bh (vm.c:1063) ==9885== by 0x2B64A8: vm_yield (vm.c:1108) ==9885== by 0x2B64A8: rb_yield_0 (vm_eval.c:970) ==9885== by 0x2B64A8: rb_yield_1 (vm_eval.c:976) ==9885== by 0x19238D: int_dotimes (numeric.c:4984) ==9885== by 0x29F816: vm_call_cfunc_with_frame (vm_insnhelper.c:1921) ==9885== by 0x29F816: vm_call_cfunc (vm_insnhelper.c:1937) ==9885== by 0x2A83D9: vm_exec_core (insns.def:719) ==9885== by 0x2ACA83: vm_exec (vm.c:1790) ==9885== by 0x2AD875: invoke_block (vm.c:993) ==9885== by 0x2AD875: invoke_iseq_block_from_c (vm.c:1045) ==9885== Address 0xbeafe88 is 43,080 bytes inside a block of size 49,152 free'd ==9885== at 0x4C29E90: free (vg_replace_malloc.c:473) ==9885== by 0x14C3EC: objspace_xfree (gc.c:7987) ==9885== by 0x14C3EC: ruby_sized_xfree (gc.c:8082) ==9885== by 0x14C3EC: ruby_xfree (gc.c:8089) ==9885== by 0x236472: rebuild_table (st.c:792) ==9885== by 0x237E85: rebuild_table_if_necessary (st.c:1090) ==9885== by 0x237E85: st_add_direct_with_hash (st.c:1153) ==9885== by 0x237E85: st_update (st.c:1431) ==9885== by 0x150A4E: tbl_update (hash.c:561) ==9885== by 0x150A4E: rb_hash_aset (hash.c:1654) ==9885== by 0x2A9687: vm_opt_aset (vm_insnhelper.c:3671) ==9885== by 0x2A9687: vm_exec_core (insns.def:1189) ==9885== by 0x2ACA83: vm_exec (vm.c:1790) ==9885== by 0x2AD875: invoke_block (vm.c:993) ==9885== by 0x2AD875: invoke_iseq_block_from_c (vm.c:1045) ==9885== by 0x2B674F: invoke_block_from_c_bh (vm.c:1063) ==9885== by 0x2B674F: vm_yield (vm.c:1108) ==9885== by 0x2B674F: rb_yield_0 (vm_eval.c:970) ==9885== by 0x2B674F: rb_yield (vm_eval.c:983) ==9885== by 0x131C86: rb_ensure (eval.c:1035) ==9885== by 0x29F816: vm_call_cfunc_with_frame (vm_insnhelper.c:1921) ==9885== by 0x29F816: vm_call_cfunc (vm_insnhelper.c:1937) ==9885== by 0x2A83D9: vm_exec_core (insns.def:719) Line numbers based on r62184 (git commit 05c18139a1545a61caaaf33d888c8427d346b571). Following patch hides the problem by introducing a leak: ``` --- a/st.c +++ b/st.c @@ -789,7 +789,7 @@ rebuild_table(st_table *tab) if (tab->bins != NULL) free(tab->bins); tab->bins = new_tab->bins; - free(tab->entries); + /* free(tab->entries); */ /* NOT FOR PRODUCTION USE */ tab->entries = new_tab->entries; free(new_tab); } ``` (gdb) up #17 0x00005604a6dd173d in find_table_entry_ind (tab=tab@entry=0x7f13e4444ac0, hash_value=hash_value@entry=0, key=key@entry=94578030726560) at ../st.c:874 874 && PTR_EQUAL(tab, &entries[bin - ENTRY_BASE], hash_value, key)) (gdb) up #18 0x00005604a6dd2d26 in st_lookup (tab=0x7f13e4444ac0, key=key@entry=94578030726560, value=value@entry=0x7f132fdfc2f8) at ../st.c:1050 1050 bin = find_table_entry_ind(tab, hash, key); (gdb) p *tab $1 = {entry_power = 7 '\a', bin_power = 8 '\b', size_ind = 0 '\000', rebuilds_num = 213, type = 0x5604a71ce210 <objhash>, num_entries = 121, bins = 0x7f13e445a340, entries_start = 0, entries_bound = 121, entries = 0x7f13e445c6b0} Looks like it's freshly rebuilt table. Pretty easy to reproduce the problem on 2.5, I remember it took more tries on 2.4 (didn't valgrind). An extra pair of eyes more experienced with this code than I am would be appreciated. Thanks. Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
