Issue #7134 has been updated by kosaki (Motohiro KOSAKI).

Assignee changed from kosaki (Motohiro KOSAKI) to nobu (Nobuyoshi Nakada)
Target version changed from 1.9.3 to next minor

Hi,

We are sorry, recursive lock is clearly unacceptable because recursive lock was not designed for trap handler. It lead to memory corruption.
When this issue was occur, C stack trace is below.

4   ruby--                        	0x0000000100260061 rb_mutex_lock + 1217 (thread_pthread.c:197)
5   ruby--                        	0x00000001002605c8 rb_mutex_synchronize + 24 (thread.c:4286)
6   ruby--                        	0x000000010015e4f0 io_binwrite + 512 (io.c:1163)
7   ruby--                        	0x000000010016156b io_write + 955 (io.c:1261)
8   ruby--                        	0x0000000100254947 vm_call0_body + 743 (vm_eval.c:110)
9   ruby--                        	0x000000010024a6c8 rb_funcall + 536 (vm_eval.c:49)
10  ruby--                        	0x0000000100160eff rb_io_puts + 159 (io.c:6717)
11  ruby--                        	0x0000000100254947 vm_call0_body + 743 (vm_eval.c:110)
12  ruby--                        	0x0000000100249f20 rb_funcall2 + 256 (vm_eval.c:750)
13  ruby--                        	0x0000000100256c55 vm_call_cfunc + 421 (vm_insnhelper.c:1442)
14  ruby--                        	0x000000010025668f vm_call_method + 287 (vm_insnhelper.c:1689)
15  ruby--                        	0x0000000100242f8c vm_exec_core + 10060 (insns.def:968)
16  ruby--                        	0x000000010024f024 vm_exec + 100 (vm.c:1159)
17  ruby--                        	0x000000010024e781 vm_invoke_proc + 161 (vm.c:680)
18  ruby--                        	0x000000010024e6d0 rb_vm_invoke_proc + 32 (vm.c:696)
19  ruby--                        	0x0000000100145695 proc_call + 117 (proc.c:567)
20  ruby--                        	0x0000000100254947 vm_call0_body + 743 (vm_eval.c:110)
21  ruby--                        	0x0000000100249f20 rb_funcall2 + 256 (vm_eval.c:750)
22  ruby--                        	0x000000010024d486 rb_eval_cmd + 262 (vm_eval.c:1379)
23  ruby--                        	0x000000010025c35a rb_threadptr_execute_interrupts_common + 330 (thread.c:1716)
24  ruby--                        	0x000000010025cd44 rb_thread_io_blocking_region + 164 (thread_pthread.c:196)
25  ruby--                        	0x000000010016fa3c io_binwrite_string + 60 (io.c:1116)
26  ruby--                        	0x000000010013fd0d rb_ensure + 109 (eval.c:802)
27  ruby--                        	0x000000010015e4f0 io_binwrite + 512 (io.c:1163)
28  ruby--                        	0x000000010016156b io_write + 955 (io.c:1261)
29  ruby--                        	0x0000000100254947 vm_call0_body + 743 (vm_eval.c:110)
30  ruby--                        	0x000000010024a6c8 rb_funcall + 536 (vm_eval.c:49)
31  ruby--                        	0x0000000100160eff rb_io_puts + 159 (io.c:6717)
32  ruby--                        	0x0000000100254947 vm_call0_body + 743 (vm_eval.c:110)
33  ruby--                        	0x0000000100249f20 rb_funcall2 + 256 (vm_eval.c:750)
34  ruby--                        	0x0000000100256c55 vm_call_cfunc + 421 (vm_insnhelper.c:1442)
35  ruby--                        	0x000000010025668f vm_call_method + 287 (vm_insnhelper.c:1689)
36  ruby--                        	0x0000000100242f8c vm_exec_core + 10060 (insns.def:968)
37  ruby--                        	0x000000010024f024 vm_exec + 100 (vm.c:1159)
38  ruby--                        	0x000000010024f965 rb_iseq_eval_main + 405 (vm.c:1402)
39  ruby--                        	0x000000010013efdf ruby_exec_internal + 111 (eval.c:251)
40  ruby--                        	0x000000010013ef27 ruby_run_node + 71 (eval.c:303)
41  ruby--                        	0x000000010010b17f main + 79 (main.c:36)
42  libdyld.dylib                 	0x00007fff8997e7e1 start + 1

Now, almost all IO hold a mutex durling io for serialization since r20144 (aka 1.9.2p0). Then, you can't
use any IOs in trap handler.

Ho hum. I think this spec is too user unfriendly and NEWS-1.9.2 seems not explain this incompatibility.
Nobu, Can you please explain current spec, your intention and your recommended trap handler writing style.


----------------------------------------
Bug #7134: Signal handling bug in Mac OS X
https://bugs.ruby-lang.org/issues/7134#change-32450

Author: auastro (Andy Kitchen)
Status: Assigned
Priority: Normal
Assignee: nobu (Nobuyoshi Nakada)
Category: 
Target version: next minor
ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin12]


On Mac OS X, running the attached program causes the exception below about 1/10 times it is run.

$ ruby hup.rb 
hup.rb:2:in `write': deadlock; recursive locking (ThreadError)
	from hup.rb:2:in `puts'
	from hup.rb:2:in `puts'
	from hup.rb:2:in `block in <main>'
	from hup.rb:6:in `call'
	from hup.rb:6:in `write'
	from hup.rb:6:in `puts'
	from hup.rb:6:in `puts'
	from hup.rb:6:in `<main>'

The expected output is:
> In Hup Handler
>Finished...

or

> Finished...
> In Hup Handler

My ruby is compiled with clang:

$ clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix



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