[ruby-core:59717] [Backport200 - Backport #9168] [Closed] Segfault with Sync_m, Queue, and garbage collection

=E3=83=81=E3=82=B1=E3=83=83=E3=83=88 #9168 =E3=81=8C Tomoyuki Chikanaga =E3=
=81=AB=E3=82=88=E3=81=A3=E3=81=A6=E6=9B=B4=E6=96=B0=E3=81=95=E3=82=8C=E3=81=
=BE=E3=81=97=E3=81=9F=E3=80=82

=E3=82=B9=E3=83=86=E3=83=BC=E3=82=BF=E3=82=B9 =E3=82=92 Assigned =E3=81=8B=
=E3=82=89 Closed =E3=81=AB=E5=A4=89=E6=9B=B4

I've committed my patch at r44576 with some modification with ChangeLog

----------------------------------------
Backport #9168: Segfault with Sync_m, Queue, and garbage collection
https://bugs.ruby-lang.org/issues/9168#change-44232

* =E4=BD=9C=E6=88=90=E8=80=85: Patrick Hemmer
* =E3=82=B9=E3=83=86=E3=83=BC=E3=82=BF=E3=82=B9: Closed
* =E5=84=AA=E5=85=88=E5=BA=A6: High
* =E6=8B=85=E5=BD=93=E8=80=85: Tomoyuki Chikanaga
* =E3=82=AB=E3=83=86=E3=82=B4=E3=83=AA:=20
* =E5=AF=BE=E8=B1=A1=E3=83=90=E3=83=BC=E3=82=B8=E3=83=A7=E3=83=B3:=20
----------------------------------------
=3Dbegin
I am able to reliably generate a segmentation fault when using Sync_m & Que=
ue together. The issue appears garbage collection related as well, as if I =
(({GC.disable})) the issue goes away.

This is the bottom of the output generated by the script and the top of the=
 debug output (the full thing is in the attachment)

 ...
 ...
 ...
 Starting 1766
 Starting 1767
 Starting 1768
 Starting 1769
 Finalizing 1187
 Finalizing 1188
 Finalizing 1189
 Finalizing 1190
 Finalizing 1186
 Finalizing 1191
 Finalizing 1192
 Finalizing 1193
 Finalizing 1195
 Finalizing 1196
 Finalizing 1197
 Finalizing 1198
 Finalizing 1194
 Finalizing 1199
 Finalizing 1200
 Finalizing 1201
 /usr/lib64/ruby/2.0.0/thread.rb:187: [BUG] Segmentation fault
 ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-linux]
=20
 -- Control frame information ---------------------------------------------=
--
 c:0005 p:0028 s:0016 e:000015 METHOD /usr/lib64/ruby/2.0.0/thread.rb:187
 c:0004 p:0083 s:0012 e:000011 BLOCK  /tmp/test.rb:22 [FINISH]
 c:0003 p:---- s:0008 e:000007 CFUNC  :times
 c:0002 p:0055 s:0005 E:001f80 EVAL   /tmp/test.rb:16 [FINISH]
 c:0001 p:0000 s:0002 E:001dc8 TOP    [FINISH]
=20
 /tmp/test.rb:16:in `<main>'
 /tmp/test.rb:16:in `times'
 /tmp/test.rb:22:in `block in <main>'
 /usr/lib64/ruby/2.0.0/thread.rb:187:in `pop'
=20
 -- C level backtrace information -----------------------------------------=
--
 /usr/lib64/libruby20.so.2.0(+0x1c1f3f) [0x7fc0ee2d9f3f] vm_dump.c:647
 /usr/lib64/libruby20.so.2.0(+0x66a1e) [0x7fc0ee17ea1e] error.c:283
 /usr/lib64/libruby20.so.2.0(rb_bug+0xe7) [0x7fc0ee17eb3b] error.c:302
 /usr/lib64/libruby20.so.2.0(+0x13a406) [0x7fc0ee252406] signal.c:672
 /lib64/libc.so.6(+0x38270) [0x7fc0edda0270]
 /usr/lib64/libruby20.so.2.0(+0x1bdf17) [0x7fc0ee2d5f17] vm.c:1234
 /usr/lib64/libruby20.so.2.0(+0x1bc767) [0x7fc0ee2d4767] vm.c:648
 /usr/lib64/libruby20.so.2.0(+0x1bc896) [0x7fc0ee2d4896] vm.c:679
 /usr/lib64/libruby20.so.2.0(+0x1b8e67) [0x7fc0ee2d0e67] vm_eval.c:930
 /usr/lib64/libruby20.so.2.0(rb_yield+0x38) [0x7fc0ee2d0ea1] vm_eval.c:940
 /usr/lib64/libruby20.so.2.0(+0xc1d82) [0x7fc0ee1d9d82] numeric.c:3588
 /usr/lib64/libruby20.so.2.0(+0x1a91a5) [0x7fc0ee2c11a5] vm_insnhelper.c:13=
36
 /usr/lib64/libruby20.so.2.0(+0x1a9d2a) [0x7fc0ee2c1d2a] vm_insnhelper.c:14=
74
 /usr/lib64/libruby20.so.2.0(+0x1a9e37) [0x7fc0ee2c1e37] vm_insnhelper.c:15=
64
 /usr/lib64/libruby20.so.2.0(+0x1aa898) [0x7fc0ee2c2898] vm_insnhelper.c:17=
58
 /usr/lib64/libruby20.so.2.0(+0x1ab0e5) [0x7fc0ee2c30e5] vm_insnhelper.c:19=
16
 /usr/lib64/libruby20.so.2.0(+0x1ae8b9) [0x7fc0ee2c68b9] insns.def:1002
 /usr/lib64/libruby20.so.2.0(+0x1bdcd9) [0x7fc0ee2d5cd9] vm.c:1201
 /usr/lib64/libruby20.so.2.0(rb_iseq_eval_main+0x34) [0x7fc0ee2d6b22] vm.c:=
1449
 /usr/lib64/libruby20.so.2.0(+0x6c4dc) [0x7fc0ee1844dc] eval.c:250
 /usr/lib64/libruby20.so.2.0(ruby_exec_node+0x24) [0x7fc0ee1845f5] eval.c:3=
15
 /usr/lib64/libruby20.so.2.0(ruby_run_node+0x3e) [0x7fc0ee1845c8] eval.c:307
 ruby() [0x400ac9]
 /lib64/libc.so.6(__libc_start_main+0xf5) [0x7fc0edd8c6f5]
 ruby() [0x400969]
=20
=20
And this is the script which can reproduce the issue:


 #!/usr/bin/ruby
 require 'thread'
 require 'sync'
=20
 def finalizer(queues, i)
 	proc do
 		puts "Finalizing #{i}"
 		queues.synchronize(:EX) do
 			queues.delete(i)
 		end
 	end
 end
=20
 queues =3D {}
 queues.extend(Sync_m)
 10000.times do |i|
 	puts "Starting #{i}"
 	queue =3D Queue.new
 	queues[i] =3D queue
 	ObjectSpace.define_finalizer(Object.new, finalizer(queues, i))
 	queue << nil
 	queue.pop
 end

This was as simple a test case as I could create. In the finalizer, if you =
just call (({queues.delete()})) without the (({queues.synchronize()})), the=
 issue does not occur.

The issue appears new to 2.0.0. I could not duplicate it with 1.9.3p448
=3Dend


---=E3=83=95=E3=82=A1=E3=82=A4=E3=83=AB---------------------------------
ruby-segfault (9.252 KB)
backport_r44260_to_ruby_2_0_0.patch (2.22 KB)


--=20
http://bugs.ruby-lang.org/