Backport #2739: ruby 1.8.7 built with pthreads hangs under some circumstances

• Status: Closed
• Assignee: shyouhei (Shyouhei Urabe)

[jbebel (Joel Ebel)]

=begin
Ruby 1.8.7 built with pthreads is hanging for me. I can't produce a reproducible testcase, and the problem is intermittent for me as it is, but I have traced it back to a particular patch when it began. The hang happens on an exec, where the ruby process clones itself, and the clone hangs. If I build ruby without pthreads it works fine. Specifically this is happening on a run of puppet when it is loading facts.

Going back through versions of the 1.8.7 branch, it appears the problem began happening in patchlevel 183 (svn revision 24104)
If I try the 1.8 branch, problems begin happening with svn revision 23268 and become more like the current behavior with revision 23305, both of which were merged into 1.8.7 in patchlevel 183 (r 24104)

If I try newer versions of the 1.8 branch, I find that the syntax has changed, however, it's possible that the specific problem i'm experiencing is fixed in r 24400 and/or 24402 (24400 doesn't build for me, so I can't be sure which revision is responsible for the improved behavior.

I will continue trying to create a reproducible test case for this bug, but I hoped that narrowing down where the regression begins would be a helpful place to start.
=end

[lucas (Lucas Nussbaum)]

=begin
After more investigation (see https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/520715 for the details), here are some conclusions.

Using this test case:
<------------------
#!/usr/bin/ruby1.8

%x{/usr/bin/touch /tmp/7777}
puts "executed without timeout ok"
puts "executing with timeout"
require 'timeout'
status = Timeout::timeout(5) {
%x{/usr/bin/touch /tmp/7777}
}
puts "executed with timeout ok"
--------------------------->

The above test case:

• runs fine on Debian unstable (using GLIBC 2.10)
• hangs on Debian unstable using the GLIBC packages from Debian experimental, version 2.11.0
• hangs on Ubuntu Lucid (which GLIBC 2.11.0)
  Both Debian unstable and Ubuntu lucid use Ruby 1.8.7 (2010-01-10 patchlevel 249)

By "hangs", I mean:
$ while ruby1.8 te.rb ; do true; done
executed without timeout ok
executing with timeout
executed with timeout ok
executed without timeout ok
executing with timeout
/usr/lib/ruby/1.8/timeout.rb:60: execution expired (Timeout::Error)
from te.rb:11

It is not clear whether this is a GLIBC or a Ruby issue. However, it would be fantastic if a Ruby developer with insight in the Ruby threading code could take a look.
=end

[shyouhei (Shyouhei Urabe)]

• Assignee set to kosaki (Motohiro KOSAKI)

=begin

=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned

=begin

=end

[a3li (Alex Legler)]

=begin
If it's any help: I can confirm this issue on Gentoo as well. After 10-200 iterations, the timeout occurs.
glibc 2.11, ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

On a machine with glibc 2.9 on the other hand, I can run the reproducer for minutes w/o any failure.
=end

[kosaki (Motohiro KOSAKI)]

=begin
Hi

I'm very glad to your help. if you can reproduce this issue easily, can you
please get stacktrace-info and give it us? I think we can use pstack command.

% pstack [pid-of-ruby]

Thanks.
=end

[lucas (Lucas Nussbaum)]

=begin
Ruby is compiled with pthreads enabled on Ubuntu (and Debian), so there are several PIDs of interest here.

Backtraces for the parent PID:
#0 0x00007f508e929c73 in select () from /lib/libc.so.6
#1 0x00007f508f6f2893 in rb_thread_schedule ()
from /usr/lib/libruby1.8.so.1.8
#2 0x00007f508f709a3c in ?? () from /usr/lib/libruby1.8.so.1.8
#3 0x00007f508f70e6d3 in ?? () from /usr/lib/libruby1.8.so.1.8
#4 0x00007f508f6ef6c1 in ?? () from /usr/lib/libruby1.8.so.1.8
#5 0x00007f508f6ef8b3 in ?? () from /usr/lib/libruby1.8.so.1.8
#6 0x00007f508f6f0578 in ?? () from /usr/lib/libruby1.8.so.1.8
#7 0x00007f508f6f0825 in rb_funcall () from /usr/lib/libruby1.8.so.1.8
#8 0x00007f508f6ebd7d in ?? () from /usr/lib/libruby1.8.so.1.8
#9 0x00007f508f6ed9f7 in ?? () from /usr/lib/libruby1.8.so.1.8
#10 0x00007f508f6e9dea in ?? () from /usr/lib/libruby1.8.so.1.8
#11 0x00007f508f6ecb81 in ?? () from /usr/lib/libruby1.8.so.1.8
#12 0x00007f508f6ecc5b in ?? () from /usr/lib/libruby1.8.so.1.8
#13 0x00007f508f6ef573 in ?? () from /usr/lib/libruby1.8.so.1.8
#14 0x00007f508f6ef8b3 in ?? () from /usr/lib/libruby1.8.so.1.8
#15 0x00007f508f6ec721 in ?? () from /usr/lib/libruby1.8.so.1.8
#16 0x00007f508f6ed066 in ?? () from /usr/lib/libruby1.8.so.1.8
#17 0x00007f508f6ea2f6 in ?? () from /usr/lib/libruby1.8.so.1.8
#18 0x00007f508f6fc85b in ?? () from /usr/lib/libruby1.8.so.1.8
#19 0x00007f508f6fc8a5 in ruby_exec () from /usr/lib/libruby1.8.so.1.8
#20 0x00007f508f6fc8d5 in ruby_run () from /usr/lib/libruby1.8.so.1.8
#21 0x0000000000400911 in main ()

Backtrace for the child PID:
#0 0x00007f508f4a2474 in __lll_lock_wait () from /lib/libpthread.so.0
#1 0x00007f508f4a00c1 in pthread_cond_signal@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#2 0x00007f508f6e5e8e in rb_thread_stop_timer ()
from /usr/lib/libruby1.8.so.1.8
#3 0x00007f508e8f5416 in fork () from /lib/libc.so.6
#4 0x00007f508f70cd20 in ?? () from /usr/lib/libruby1.8.so.1.8
#5 0x00007f508f70e691 in ?? () from /usr/lib/libruby1.8.so.1.8
#6 0x00007f508f6ef6c1 in ?? () from /usr/lib/libruby1.8.so.1.8
#7 0x00007f508f6ef8b3 in ?? () from /usr/lib/libruby1.8.so.1.8
#8 0x00007f508f6f0578 in ?? () from /usr/lib/libruby1.8.so.1.8
#9 0x00007f508f6f0825 in rb_funcall () from /usr/lib/libruby1.8.so.1.8
#10 0x00007f508f6ebd7d in ?? () from /usr/lib/libruby1.8.so.1.8
#11 0x00007f508f6ed9f7 in ?? () from /usr/lib/libruby1.8.so.1.8
#12 0x00007f508f6e9dea in ?? () from /usr/lib/libruby1.8.so.1.8
#13 0x00007f508f6ecb81 in ?? () from /usr/lib/libruby1.8.so.1.8
#14 0x00007f508f6ecc5b in ?? () from /usr/lib/libruby1.8.so.1.8
#15 0x00007f508f6ef573 in ?? () from /usr/lib/libruby1.8.so.1.8
#16 0x00007f508f6ef8b3 in ?? () from /usr/lib/libruby1.8.so.1.8
#17 0x00007f508f6ec721 in ?? () from /usr/lib/libruby1.8.so.1.8
#18 0x00007f508f6ed066 in ?? () from /usr/lib/libruby1.8.so.1.8
#19 0x00007f508f6ea2f6 in ?? () from /usr/lib/libruby1.8.so.1.8
#20 0x00007f508f6fc85b in ?? () from /usr/lib/libruby1.8.so.1.8
#21 0x00007f508f6fc8a5 in ruby_exec () from /usr/lib/libruby1.8.so.1.8
#22 0x00007f508f6fc8d5 in ruby_run () from /usr/lib/libruby1.8.so.1.8
#23 0x0000000000400911 in main ()

I could easily provide you with an Ubuntu lucid chroot (as a tarball) so you can reproduce the issue. I'd just need to use the CPU architecture that you use (i386, amd64?)
=end

[kosaki (Motohiro KOSAKI)]

=begin

I could easily provide you with an Ubuntu lucid chroot (as a tarball) so you can reproduce the issue. I'd just need to use the CPU architecture that you use (i386, amd64?)

Wow, thanks. amd64 please.
=end

[kosaki (Motohiro KOSAKI)]

=begin
Hm

I think child process doesn't need to call rb_thread_stop_timer().
Can you please try following patch?

diff --git a/eval.c b/eval.c
index 55dbb8c..31e6a33 100644
--- a/eval.c
+++ b/eval.c
@@ -12343,7 +12343,6 @@ rb_thread_start_timer()
safe_mutex_lock(&time_thread.lock);
if (pthread_create(&time_thread.thread, 0, thread_timer, args) == 0) {
thread_init = 1;

•   pthread_atfork(0, 0, rb_thread_stop_timer);
    pthread_cond_wait(&start, &time_thread.lock);
  

  }
  pthread_cleanup_pop(1);
  =end

[lucas (Lucas Nussbaum)]

=begin
Hi,

The patch doesn't fix the problem.

You can download an Ubuntu lucid chroot, with packages necessary to build ruby installed, at http://blop.info/pub/lucid.tar.bz2
From there, update /etc/resolv.conf with your local info, then run apt-get source ruby1.8 to download ruby 1.8 sources. cd to ruby1.8-*, and run dpkg-buildpackage to build the package the debian way. configure parameters can be found in debian/rules.

If you need more interactive help, I am available on IRC (freenode, nickname: lucas) or XMPP ([e-mail])

Thanks
=end

[kosaki (Motohiro KOSAKI)]

• File 0001-backport-ruby_1_8-26371.patch 0001-backport-ruby_1_8-26371.patch added
• File 0002-for-linux.patch 0002-for-linux.patch added

=begin
OK, fixed.
Can you please try the attached two patches?

On my test machine, the test case of comment#1 works perfectly. but I haven't tested original issue (i.e. puppet hangs problem).
=end

[lucas (Lucas Nussbaum)]

=begin
Hi,

I'm sorry, but the test case still fails for me, even with the two patches applied.

I've also spent time investigating the issue. I confirmed that r23268 in the 1_8 branch introduced the problem. I can also confirm that the 1_8 branch is not fixed yet (I could reproduce it with r26851).
=end

[jbebel (Joel Ebel)]

=begin
Using puppet, I noticed a distinct improvement in the 1_8 branch at 24402, but I haven't tried the testcase with it. You're not seeing improvement with the testcase at 24402 Lucas?
=end

[lucas (Lucas Nussbaum)]

=begin
No, I don't see any improvement with 24402.

I'm using that test case:
<-------
#!/usr/bin/ruby1.8

system("/usr/bin/touch /tmp/7777")
puts "executed without timeout ok"
require 'timeout'
status = Timeout::timeout(1) {
system("/usr/bin/touch /tmp/7777")
}
puts "executed with timeout ok\n"
--------------->
And that test runner, that I execute with ruby 1.9.1 to avoid conflicts:
<-------------
errs = 0
1.upto(100).each do |i|
system("ruby1.8 t.rb")
if $?.termsig == 2
errs += 1
end
end
puts errs
--------------->

Compiling various revisions from the 1_8 branch, I get the following results:
rev 23262: 100 successes

rev 23268: blocks, not killable with killall ruby1.9 (needs -9) (0 successes)

rev 24394: 29 successes, 71 failures
doesn't block anymore, but raises an exception:
/usr/lib/ruby/1.8/timeout.rb:60: execution expired (Timeout::Error)
from ../t.rb:6

rev 24402: 24 successes, 76 failures
(same behaviour as r24394)

rev 26851: 24 successes, 76 failures
(same behaviour as r24394)
=end

[kosaki (Motohiro KOSAKI)]

=begin
Hmm, I'm confused.

Before my patch, the test also show errs=0 on my test environment (x86_64 ubuntu 10.04 alpha3).
To reproduce hang need about 1000 times try. I think we are seeing different issue. but I haven't
understand what's difference our environment. hmm...
=end

[lucas (Lucas Nussbaum)]

=begin
How many CPU cores do you have on your system ? I'm testing with a dual-core laptop.
You are running the Ubuntu kernel as well?
=end

[kosaki (Motohiro KOSAKI)]

=begin
4core opteron. I've installed ubuntu as kvm guest recently (for tracking this issue).
=end

[lucas (Lucas Nussbaum)]

=begin
Which kernel are you using? It is possible that KVM changes the behaviour and prevents reproducing the issue...
=end

[kosaki (Motohiro KOSAKI)]

=begin
I'm using fedora12(2.6.31.9-xxx) as kvm host. unfortunately I don't have another machine. hmm..

Can you please get backtrace info again? I think my patch have solved comment#6 problem at least,
because now child process doesn't call rb_thread_stop_timer() at all.

plus, can you please tell us your configure option? I'm using
% ./configure --enable-pthread

=end

[lucas (Lucas Nussbaum)]

=begin
I'm building with:
CFLAGS="-fno-strict-aliasing -g -O2" CXXFLAGS="-fno-strict-aliasing -g" CPPFLAGS="" LDFLAGS="" ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir="${prefix}/include" --mandir="${prefix}/share/man" --infodir="${prefix}/share/info" --sysconfdir=/etc --localstatedir=/var --libexecdir="${prefix}/lib/ruby1.8" --disable-maintainer-mode --disable-dependency-tracking --disable-silent-rules --srcdir=. --program-suffix=1.8 --enable-pthread --enable-shared --enable-ipv6 --with-lookup-order-hack=INET --disable-rpath --disable-install-doc --with-sitedir='/usr/local/lib/site_ruby' --with-default-kcode=none --with-dbm-type=gdbm_compat --with-tklib=tk8.4 --with-tcllib=tcl8.4 --with-tcl-include=/usr/include/tcl8.4 --with-bundled-sha1 --with-bundled-md5 --with-bundled-rmd160 && make all && sudo make install

What I did when you proposed the patches was to rebuild the Debian package with the patches. And indeed, the problem remained, and the backtraces are:
Child:
#0 __lll_lock_wait ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1 0x00007f3d5ed2f40b in pthread_cond_signal@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_signal.S:117
#2 0x00007f3d5ef75308 in rb_thread_stop_timer () at eval.c:12539
#3 0x00007f3d5e1a7e66 in __libc_fork ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c:170
#4 0x00007f3d5efc6611 in rb_f_system (argc=,
argv=0x7fff7e47c170) at process.c:1584
#5 0x00007f3d5ef7efdc in rb_call0 (klass=,
recv=, id=,
oid=, argc=,
argv=, body=0x7f3d5f4214d8, flags=0)
at eval.c:6003
#6 0x00007f3d5ef7f1c3 in rb_call (klass=139901568018760,
recv=139901568008880, mid=9425, argc=1, argv=0x7fff7e47c170,
scope=1, self=139901568008880) at eval.c:6255
#7 0x00007f3d5ef7becb in rb_eval (self=140735312019832,
n=) at eval.c:3583
#8 0x00007f3d5ef7d327 in rb_yield_0 (val=,
self=, klass=,
flags=, avalue=)
at eval.c:5167
#9 0x00007f3d5ef79662 in rb_eval (self=140735312033144,
n=) at eval.c:3371
#10 0x00007f3d5ef7c427 in rb_eval (self=140735312033144,
n=) at eval.c:3382
#11 0x00007f3d5ef7c560 in rb_eval (self=140735312033144,
n=) at eval.c:3432
#12 0x00007f3d5ef7ee60 in rb_call0 (klass=, recv=0,
id=140735312033144, oid=, argc=0,
argv=0x7fff7e47f578, body=0x7f3d5f418068, flags=0) at eval.c:6158
#13 0x00007f3d5ef7f1c3 in rb_call (klass=139901567846520,
recv=139901567847360, mid=11025, argc=1, argv=0x7fff7e47f570,
scope=0, self=139901568008880) at eval.c:6255
#14 0x00007f3d5ef7bfd2 in rb_eval (self=1, n=)
at eval.c:3568
#15 0x00007f3d5ef7c8ba in rb_eval (self=0, n=)
at eval.c:3296
#16 0x00007f3d5ef79b66 in rb_eval (self=0, n=)
at eval.c:3762
#17 0x00007f3d5ef883cb in ruby_exec_internal () at eval.c:1689
#18 0x00007f3d5ef883f5 in ruby_exec () at eval.c:1712
#19 0x00007f3d5ef88425 in ruby_run () at eval.c:1722
#20 0x00000000004008d1 in main ()

Parent:
#0 0x00007f3d5e1cff82 in select () from /lib/libc.so.6
#1 0x00007f3d5ef8459b in rb_thread_schedule () at eval.c:11280
#2 0x00007f3d5efc6185 in rb_waitpid (pid=,
st=, flags=1) at process.c:597
#3 0x00007f3d5efc6484 in rb_syswait (pid=16044) at process.c:1442
#4 0x00007f3d5efc6625 in rb_f_system (argc=,
argv=0x7fff7e47c170) at process.c:1601
#5 0x00007f3d5ef7efdc in rb_call0 (klass=,
recv=, id=,
oid=, argc=,
argv=, body=0x7f3d5f4214d8, flags=0)
at eval.c:6003
#6 0x00007f3d5ef7f1c3 in rb_call (klass=139901568018760,
recv=139901568008880, mid=9425, argc=1, argv=0x7fff7e47c170,
scope=1, self=139901568008880) at eval.c:6255
#7 0x00007f3d5ef7becb in rb_eval (self=140735312019832,
n=) at eval.c:3583
#8 0x00007f3d5ef7d327 in rb_yield_0 (val=,
self=, klass=,
flags=, avalue=)
at eval.c:5167
#9 0x00007f3d5ef79662 in rb_eval (self=140735312033144,
n=) at eval.c:3371
#10 0x00007f3d5ef7c427 in rb_eval (self=140735312033144,
n=) at eval.c:3382
#11 0x00007f3d5ef7c560 in rb_eval (self=140735312033144,
n=) at eval.c:3432
#12 0x00007f3d5ef7ee60 in rb_call0 (klass=, recv=0,
id=140735312033144, oid=, argc=0,
argv=0x7fff7e47f578, body=0x7f3d5f418068, flags=0) at eval.c:6158
#13 0x00007f3d5ef7f1c3 in rb_call (klass=139901567846520,
recv=139901567847360, mid=11025, argc=1, argv=0x7fff7e47f570,
scope=0, self=139901568008880) at eval.c:6255
#14 0x00007f3d5ef7bfd2 in rb_eval (self=1, n=)
at eval.c:3568
#15 0x00007f3d5ef7c8ba in rb_eval (self=0, n=)
at eval.c:3296
#16 0x00007f3d5ef79b66 in rb_eval (self=0, n=)
at eval.c:3762
#17 0x00007f3d5ef883cb in ruby_exec_internal () at eval.c:1689
#18 0x00007f3d5ef883f5 in ruby_exec () at eval.c:1712
#19 0x00007f3d5ef88425 in ruby_run () at eval.c:1722
#20 0x00000000004008d1 in main ()

But applying the patch to the svn tree (branch v1_8_7) works, strangely. This is very surprising, because the Debian package and the SVN tree should be almost identical (we do have a few Debian-specific things, but nothing that should be relevant). I tried to download the ruby-1.8.7-p249.tar.gz tarball, and rebuild it with the patch applied, and it works like the SVN branch (=> the patch works).

Conclusion: your patch fixes the bug, and we have something broken in the Debian package that causes the effects of your patch to be hidden. Would you happen to know if something in the Ruby build process could explain that?

Anyway, thanks a lot for working on that issue! What is the next step? Are you going to release a 1.8.7.250?
=end

[kosaki (Motohiro KOSAKI)]

=begin
Sorry, I don't know release plan.

Urabe-san, Can you please tell us next 1.8.7.x release plan?
=end

[naruse (Yui NARUSE)]

=begin
(2010/03/11 15:34), Lucas Nussbaum wrote:

But applying the patch to the svn tree (branch v1_8_7) works,
strangely. This is very surprising, because the Debian package and
the SVN tree should be almost identical (we do have a few
Debian-specific things, but nothing that should be relevant). I tried
to download the ruby-1.8.7-p249.tar.gz tarball, and rebuild it with
the patch applied, and it works like the SVN branch (=> the patch
works).

Please let us know such fixes, even if it is ugly like following patch:
http://redmine.ruby-lang.org/issues/show/2724

We want to know platform dependent problems.

Conclusion: your patch fixes the bug, and we have something broken in
the Debian package that causes the effects of your patch to be
hidden. Would you happen to know if something in the Ruby build
process could explain that?

Ruby has many portability hacks.
So we have many possibilities...
(so, we want to know such problems)

--
NARUSE, Yui [e-mail]

=end

[shyouhei (Shyouhei Urabe)]

=begin
Motohiro KOSAKI wrote:

Sorry, I don't know release plan.

Urabe-san, Can you please tell us next 1.8.7.x release plan?

Well... No plan yet. There are several issues to be fixed and backported so at
least something is to be released, hopefully at some point of next quarter, but
I do not have any particular dates now.

This fix should be included to the next one of course.

Attachment: signature.asc
=end

[lucas (Lucas Nussbaum)]

=begin

Please let us know such fixes, even if it is ugly like following patch:
http://redmine.ruby-lang.org/issues/show/2724

We want to know platform dependent problems.

After investigating that, I discovered that what I was seeing (patch not working inside the Debian package) was caused by a stupid mistake on my side: while research that problem, I had built ruby from trunk, and got a libruby1.8.so.1.8.8. Since installing the Debian package causes ldconfig to be run, I ended up using that library instead of the (fixed) libruby1.8.so.1.8.7.
=end

[naruse (Yui NARUSE)]

• Status changed from Assigned to Closed

=begin

=end

[naruse (Yui NARUSE)]

• Status changed from Closed to Open
• Assignee deleted (kosaki (Motohiro KOSAKI))

=begin

=end

[naruse (Yui NARUSE)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

=begin
This issue was solved with changeset r26972.
Joel, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end

[naruse (Yui NARUSE)]

• Category set to core
• Status changed from Closed to Assigned
• Assignee set to shyouhei (Shyouhei Urabe)

=begin
Backport r26371, r26327, r26972.
=end

[shyouhei (Shyouhei Urabe)]

=begin
Hi Yui,

Yui NARUSE wrote:

Backport r26371, r26327, r26972.

Can you tell me what's the matter of r26327?

=end

[lucas (Lucas Nussbaum)]

=begin
It was reported in Debian bug #580464 that the same problem affects Debian GNU/kFreeBSD. Is there a reason why the #ifdefs around rb_thread_stop_timer()/rb_thread_start_timer() aren't simply removed? With Linux and NetBSD affected, it's likely that everybody is affected.

(Btw, I can't find how to reopen this bug report)
=end

[kosaki (Motohiro KOSAKI)]

=begin
Hi Lucas,

It was reported in Debian bug #580464 that the same
problem affects Debian GNU/kFreeBSD. Is there a reason
why the #ifdefs around rb_thread_stop_timer()/rb_thread_start_timer()
aren't simply removed? With Linux and NetBSD affected,
it's likely that everybody is affected.

Basically, The stable branch shouldn't be change by guess.
Then, We only changed the branch by an actual bug report.

but, personally, I incline your opinion...
Naruse-san, Urabe-san, What do you think?

(Btw, I can't find how to reopen this bug report)

me too.
Could you please open another ticket? I'll make the ticket
relationship againt #2739.

Thanks.

=end

[kosaki (Motohiro KOSAKI)]

=begin

(Btw, I can't find how to reopen this bug report)

me too.
Could you please open another ticket? I'll make the ticket
relationship againt #2739.

plus, Could you please confirm the attached patch solve your kFreeBSD issue?

Attachment: bug2739-kfreebsd.patch
=end

[shyouhei (Shyouhei Urabe)]

=begin

Naruse-san, Urabe-san, What do you think?

I'm waiting for a reply from Yui on this. See the discussion log.
=end

[lucas (Lucas Nussbaum)]

=begin
On 08/05/10 at 15:58 +0900, KOSAKI Motohiro wrote:

Hi Lucas,

It was reported in Debian bug #580464 that the same
problem affects Debian GNU/kFreeBSD. Is there a reason
why the #ifdefs around rb_thread_stop_timer()/rb_thread_start_timer()
aren't simply removed? With Linux and NetBSD affected,
it's likely that everybody is affected.

Basically, The stable branch shouldn't be change by guess.
Then, We only changed the branch by an actual bug report.

but, personally, I incline your opinion...
Naruse-san, Urabe-san, What do you think?

(Btw, I can't find how to reopen this bug report)

me too.
Could you please open another ticket? I'll make the ticket
relationship againt #2739.

Yes, see #3278.

| Lucas Nussbaum
| [e-mail] http://www.lucas-nussbaum.net/ |
| jabber: [e-mail] GPG: 1024D/023B3F4F |

=end

[naruse (Yui NARUSE)]

=begin
Shyouhei Urabe wrote:

Yui NARUSE wrote:

Backport r26371, r26327, r26972.

Can you tell me what's the matter of r26327?

Sorry, I meant r26371,r26373,r26374,r26972.
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Assigned to Closed

=begin
This issue was solved with changeset r28203.
Joel, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end