Bug #8860: 64-bit x86 ruby 1.9.3-p448 on Solaris core dumps on bug4950 test case

• Status: Closed
• Assignee: ngoto (Naohisa Goto)
• Target version: -
• ruby -v: ruby 1.9.3p448 (2013-06-27 revision 41675) [i386-solaris2.12]
• Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN

[apchin (April Chin)]

64-bit ruby 1.9.3-p448 on x86 in Solaris, compiled with the Studio 12.1 compiler,
core dumps against the test case for bug 4950 in bootstraptest/test_fork.rb.
This problem sounds similar to issue 6334, which was rejected due
to lack of information.
The core dump does not occur with 64-bit ruby 1.9.3 on sparc.

configure options used:
--prefix=/usr/ruby/1.9 --mandir=/usr/ruby/1.9/share/man --bindir=/usr/ruby/1.9/bin --libdir=/usr/ruby/1.9/lib --sbindir=/usr/ruby/1.9/sbin --enable-shared --enable-rpath --enable-install-doc --disable-option-checking --with-openssl

CFLAGS="-m64 -xO2 -xchip=generic -Ui386 -U__i386 -D__amd64 -xregs=no%frameptr -mt -DFFI_NO_RAW_API"

$ cat bug4950
a = []
trap(:INT) { a.push(1) }
trap(:TERM) { a.push(2) }

pid = $$
fork do
sleep 0.5
puts "send start"
Process.kill(:INT, pid)
Process.kill(:TERM, pid)
puts "send end"
end

puts "sleep start"
sleep 3
puts "sleep end"
p a

$ ruby bug4950
sleep start
send start
send end
Memory fault(coredump)
$ pstack core
core 'core' of 24964: ruby bug4950
------------ lwp# 1 / thread# 1 ---------------
ffff80ffbf5a6797 __lwp_park () + 17
ffff80ffbf5a0062 cond_wait_queue () + 62
ffff80ffbf5a04a0 cond_wait_common () + 1dc
ffff80ffbf5a06e5 __cond_timedwait () + 5d
ffff80ffbf5a0779 cond_timedwait () + 29
ffff80ffbf5a07ad pthread_cond_timedwait () + 9
ffff80ffb8799564 native_cond_timedwait () + 24
ffff80ffb8799b5c native_sleep () + d8
ffff80ffb879b26d sleep_timeval () + 7d
ffff80ffb879b3ff rb_thread_wait_for () + 27
ffff80ffb8712162 rb_f_sleep () + 4a
ffff80ffb8789eb4 vm_call_cfunc () + c0
ffff80ffb878a562 vm_call_method () + 2ae
ffff80ffb878d57b vm_exec_core () + 1403
ffff80ffb8796e7b vm_exec () + 5c7
ffff80ffb8796f93 rb_iseq_eval_main () + 2b
ffff80ffb86b3917 ruby_exec_internal () + 87
ffff80ffb86b39f6 ruby_exec_node () + 1e
ffff80ffb86b39bc ruby_run_node () + 24
0000000000400ec8 main () + 4c
0000000000400d1c ???????? ()
------------ lwp# 3 / thread# 3 ---------------
ffff80ffbf7b189f lookup_sym () + 3b
ffff80ffbf7cb9db elf_bndr () + 11b
ffff80ffbf7ad073 elf_rtbndr () + 83
ffff80ffbf7ee030 ???????? ()
ffff80ffbf5a6876 __sighndlr () + 6
ffff80ffbf599bba call_user_handler () + 2ce
ffff80ffbf59a063 sigacthandler (f, ffff80ffbf76b6c8, ffff80ffbf76b360) + db
--- called from signal handler with signal 15 (SIGTERM) ---
ffff80ffbf5b026b _syscall6 () + 1b
ffff80ffbf599b01 call_user_handler () + 215
ffff80ffbf59a063 sigacthandler (2, ffff80ffbf76bc98, ffff80ffbf76b930) + db
--- called from signal handler with signal 2 (SIGINT) ---
ffff80ffbf5af64a __pollsys () + a
ffff80ffbf4fc6c5 pselect () + 181
ffff80ffbf4fcb44 select () + 68
ffff80ffb8799f57 thread_timer () + b3
ffff80ffbf5a64a5 _thrp_setup () + a5
ffff80ffbf5a6750 _lwp_start ()

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Feedback

Could you try latest version of Ruby 1.9.3?

[yann (Yann Rouillard)]

• File core.part1 core.part1 added
• File core.part2 core.part2 added
• File test_fork_modified.rb test_fork_modified.rb added

Hi,

I confirm that this bug is still present with ruby 1.9.3 patch level 484:
Output of ruby -v: ruby 1.9.3p484 (2013-11-22 revision 43786) [i386-solaris2.10]

I attached the core dump (which is 6 MB, so it is split in two files) and you will find the stacktrace below.

I noticed that the core dump happens only if the two signals INT and TERM are sent, when I remove one line or the other, the core dump doesn't happen.

It also doesn't happen if I insert a 0.5s pause between the two signal (see the attached file test_forks_modified.rb).

I will try the last ruby 1.9.3 version that went out recently.

Stacktrace:

core 'core' of 12295: ./work/solaris10-i386/build-isa-pentium_pro/ruby-1.9.3-p484/ruby191 te
----------------- lwp# 1 / thread# 1 --------------------
feef8e29 __lwp_park (8061084, 80610b0, 8046020) + 19
feef361b cond_wait_queue (8061084, 80610b0, 8046020) + 5e
feef3998 cond_wait_common (8061084, 80610b0, 8046020) + 1db
feef3bca _cond_timedwait (8061084, 80610b0, 80460d8) + 51
feef3c35 cond_timedwait (8061084, 80610b0, 80460d8) + 24
feef3c71 pthread_cond_timedwait (8061084, 80610b0, 80460d8, fed9a3de) + 1e
fed9a3fe native_cond_timedwait (8061084, 80610b0, 80460d8, 0) + 2e
fed9aa87 native_sleep (8061030, 8046154, feffa320, fed9c211) + d7
fed9c26f sleep_timeval (8061030, 1, 0, fed9c41c) + 6c
fed9c43a rb_thread_wait_for (1, 0, 0, fecc530d) + 2a
fecc534f rb_f_sleep (1, 806525c, 8114da8, fed576b2) + 4f
fed74d8d vm_exec_core (8061030, 0, fee2c4e0, fed97041) + 1d6ec
fed9772e vm_exec (8061030, 80fe1c0, fef60018, fed9782d) + 6fe
fed97852 rb_iseq_eval_main (80fe1c0, 8047a88, feef6b6a, fec5a101) + 32
fec5a184 ruby_exec_internal (80fe1c0, 0, 0, fec5a27c, 8047b38) + 8f
fec5a29a ruby_exec_node (80fe1c0) + 2a
fec5a24b ruby_run_node (80fe1c0, 8047b98, 8047b68, 8050b78, 29, fef77790) + 34
08050b8f main (2, 8047b98, 8047ba4, 8047b8c) + 5f
08050a9d _start (2, 8047c5c, 8047ca0, 0, 8047cad, 8047d6d) + 7d
----------------- lwp# 3 / thread# 3 --------------------
feefde86 __systemcall (3, fee30618, 0) + 6
feeeeb44 call_user_handler (2, fee30bdc, fee3068c) + 1e0
feeeecd0 sigacthandler (2, fee30bdc, fee3068c) + 7c
--- called from signal handler with signal 2 (SIGINT) ---
feefbe95 __pollsys (fee32ca0, 1, 0, 0) + 15
feea5871 pselect_large_fdset (4, fee32f40, fee30ca0, fee30ca0, 0, 0) + 1fd
feea5b97 select_large_fdset (4, fee32f40, 0, 0, 0, 0) + 82
fed9af1d thread_timer (8060dbc) + c5
feef8aab _thr_setup (feba0200) + 4e
feef8db0 _lwp_start (feba0200, 0, 0, fee32ff8, feef8db0, feba0200)

[hsbt (Hiroshi SHIBATA)]

• Assignee set to ngoto (Naohisa Goto)

[ngoto (Naohisa Goto)]

The latest version is Ruby 1.9.3-p545. Please try the latest version.
https://www.ruby-lang.org/en/news/2014/02/24/ruby-1-9-3-p545-is-released/

Could you try latest version of SolarisStudio 12.3 compiler?

I only use Solaris 10 on Sparc, and I don't have x86 Solaris. So, it is very hard to solve the problem.

[ngoto (Naohisa Goto)]

• Status changed from Feedback to Closed

Closed because of no feedback, and because 1.9.3 is EOL.

Recently, some problems about fork and exec on Solaris have been fixed.
See [Bug #11265], [Bug #11336], and [Bug #11353], though these may not be related with this issue.