[#83096] File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?}) — Nobuyoshi Nakada <nobu@...>
On 2017/10/04 8:47, normal@ruby-lang.org wrote:
5 messages
2017/10/04
[#83100] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Eric Wong <normalperson@...>
2017/10/04
Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#83105] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Nobuyoshi Nakada <nobu@...>
2017/10/04
On 2017/10/04 15:55, Eric Wong wrote:
[#83107] Alias Enumerable#include? to Enumerable#includes? — Alberto Almagro <albertoalmagro@...>
Hello,
9 messages
2017/10/04
[#83113] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/05
This has been requested countless times, then rejected each and every time.
[#83129] Re: Alias Enumerable#include? to Enumerable#includes?
— Alberto Almagro <albertoalmagro@...>
2017/10/05
Sorry I didn't found it on the core mail list's archive.
[#83138] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/06
Ruby has not been made of popular votes so far. You have to show us
[#83149] Re: Alias Enumerable#include? to Enumerable#includes?
— Eric Wong <normalperson@...>
2017/10/06
Alberto Almagro <albertoalmagro@gmail.com> wrote:
[#83200] [Ruby trunk Feature#13996] [PATCH] file.c: apply2files releases GVL — normalperson@...
Issue #13996 has been reported by normalperson (Eric Wong).
4 messages
2017/10/10
[ruby-core:83466] [Ruby trunk Bug#13887] test/ruby/test_io.rb may get stuck with FIBER_USE_NATIVE=0 on Linux
From:
ko1@...
Date:
2017-10-21 14:51:22 UTC
List:
ruby-core #83466
Issue #13887 has been updated by ko1 (Koichi Sasada).
Sorry for missing this ticket.
I can't understand it is correct, but I believe you guys. Thank you so much.
I'm not sure why previous versions doesn't have same problem.
----------------------------------------
Bug #13887: test/ruby/test_io.rb may get stuck with FIBER_USE_NATIVE=0 on Linux
https://bugs.ruby-lang.org/issues/13887#change-67461
* Author: wanabe (_ wanabe)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Target version:
* ruby -v:
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
Eric Wong wrote in https://bugs.ruby-lang.org/issues/13875#note-5 [ruby-core:82708]
> However, test/ruby/test_io.rb seems stuck when FIBER_USE_NATIVE is 0
> on my system...
I can reproduce with `make optflags="-DFIBER_USE_NATIVE=0 -O0" test-all TESTOPTS="$(git rev-parse --show-cdup)/test/ruby/test_io.rb"` on my Ubuntu 17.10, glibc 2.24-12.
Here is a reduced code.
This code don't stop with SIGINT (CTRL+C) so I had to use SIGKILL.
```
1000.times do |i|
p i
r, w = IO.pipe
w.puts "foo"
w.close
rt = Thread.new do
r.each_char.next
r.close
end
Thread.new {}.join # <= stuck
rt.join
end
```
GDB showed ALLOCATE_STACK() had entered in infinity loop at get_cached_stack(), static function of glibc.
I guess `stack_cache` local variable of allocatestack.c of glibc got corrupted.
```
$ gdb --args ./miniruby -v a.rb
(snip)
(gdb) r
Starting program: /home/takira/work/prog/ruby/ruby/tmp/.out.tmp/miniruby -v a.rb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7f2865b5e700 (LWP 5568)]
ruby 2.5.0dev (2017-09-10 trunk 59457) [x86_64-linux]
0
(snip)
[Thread 0x7f8fe2ba4700 (LWP 27769) exited]
51
[Thread 0x7f8fe2da6700 (LWP 27768) exited]
^C
Thread 1 "miniruby" received signal SIGINT, Interrupt.
0x00007f8fe4014bc3 in get_cached_stack (memp=<synthetic pointer>, sizep=<synthetic pointer>) at allocatestack.c:194
warning: Source file is more recent than executable.
194 if (FREE_P (curr) && curr->stackblock_size >= size)
(gdb) bt 5
#0 0x00007f8fe4014bc3 in get_cached_stack (memp=<synthetic pointer>, sizep=<synthetic pointer>)
at allocatestack.c:194
#1 allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0x7fffffffb350) at allocatestack.c:496
#2 __pthread_create_2_1 (newthread=0x555555d3f488, attr=0x7fffffffb350,
start_routine=0x555555713e6d <thread_start_func_1>, arg=0x555555d3f3c0) at pthread_create.c:663
#3 0x0000555555714013 in native_thread_create (th=0x555555d3f3c0) at ../../thread_pthread.c:1031
#4 0x000055555571827a in thread_create_core (thval=93824997656680, args=93824997656600, fn=0x0)
at ../../thread.c:740
(More stack frames follow...)
(gdb) f 0
#0 0x00007f8fe4014bc3 in get_cached_stack (memp=<synthetic pointer>, sizep=<synthetic pointer>)
at allocatestack.c:194
194 if (FREE_P (curr) && curr->stackblock_size >= size)
(gdb) p (&stack_cache)->next
$1 = (struct list_head *) 0x7f8fe2da69c0
(gdb) p (&stack_cache)->next->next->next->next->next
$2 = (struct list_head *) 0x7f8fe2da69c0
```
I've reproduced it with ruby_2_4, ruby_2_3 and ruby_2_2.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>