[#61171] Re: [ruby-changes:33145] normal:r45224 (trunk): gc.c: fix build for testing w/o RGenGC — SASADA Koichi <ko1@...>
(2014/03/01 16:15), normal wrote:
[#61243] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — normalperson@...
Issue #9425 has been updated by Eric Wong.
[#61359] [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs — normalperson@...
Issue #9609 has been reported by Eric Wong.
(2014/03/07 19:09), normalperson@yhbt.net wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>
I'm unsure about this. I _hate_ the extra branches this adds;
Hi Eric,
SASADA Koichi <ko1@atdot.net> wrote:
(2014/03/14 2:12), Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#61452] [ruby-trunk - Feature #9632] [Open] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been reported by Eric Wong.
[#61496] [ruby-trunk - Feature #9638] [Open] [PATCH] limit IDs to 32-bits on 64-bit systems — normalperson@...
Issue #9638 has been reported by Eric Wong.
[#61568] hash function for global method cache — Eric Wong <normalperson@...>
I came upon this because I noticed existing st numtable worked poorly
(2014/03/18 8:03), Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
what's the profit from using binary tree in place of hash?
Юрий Соколов <funny.falcon@gmail.com> wrote:
[#61687] [ruby-trunk - Bug #9606] Ocassional SIGSEGV inTestException#test_machine_stackoverflow on OpenBSD — normalperson@...
Issue #9606 has been updated by Eric Wong.
[#61760] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been updated by Eric Wong.
[ruby-core:61391] [ruby-trunk - Bug #8860] 64-bit x86 ruby 1.9.3-p448 on Solaris core dumps on bug4950 test case
Issue #8860 has been updated by Yann Rouillard.
File core.part1 added
File core.part2 added
File 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)
----------------------------------------
Bug #8860: 64-bit x86 ruby 1.9.3-p448 on Solaris core dumps on bug4950 test case
https://bugs.ruby-lang.org/issues/8860#change-45703
* Author: April Chin
* Status: Feedback
* Priority: Normal
* Assignee:
* Category:
* 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
----------------------------------------
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 ()
---Files--------------------------------
core.part1 (3 MB)
core.part2 (2.96 MB)
test_fork_modified.rb (267 Bytes)
--
http://bugs.ruby-lang.org/