The following test case sometimes causes a deadlock in the parent process in lang/ruby20 and lang/ruby21. Ruby on other platforms and lang/ruby19 seem to be unaffected. This test case was inspired by sysutils/puppet, which executes similar code displays similar symptoms. at_exit { raise } if pid = fork Thread.new {} exit(0) end Tested, OK: ruby19 -v: ruby 1.9.3p484 (2013-11-22 revision 43786) [amd64-freebsd10] Tested, deadlocks: ruby20 -v: ruby 2.0.0p353 (2013-11-22 revision 43784) [amd64-freebsd10] ruby21 -v: ruby 2.1.1p76 (2014-02-24 revision 45161) [amd64-freebsd10] How-To-Repeat: In order to see a deadlock it may have to be run multiple times, for example: for i in `jot 100`; do ruby test-case.rb; done
Responsible Changed From-To: freebsd-ports-bugs->ruby Over to maintainer (via the GNATS Auto Assign Tool)
After more debugging, this is yet another case of PCID (vm.pmap.pcid_enabled=1) breaking things. While on that topic, camlistore (a Go program) is also broken by the same. Regards, Andrew
Responsible Changed From-To: ruby->swills I'll take it.
Hi, Thanks for the report and especially the followup. Lacking hardware which supports PCID, I never would have found it. :) That said, there is a similiar issue with Java, so I'm not sure where to go with this for now, except to report to kernel developers and see what they say. Perhaps we should add a pkg-message suggesting turning it off? Steve
Hi, It looks like that feature was disabled in 10-STABLE by default as of r262753. So you could upgrade to that to verify, but it since you've already disabled it, that may not be worth the effort. Up to you. Steve
Hi, On 20/03/2014, at 7:11 pm, Steve Wills <swills@FreeBSD.org> wrote: > That said, there is a similiar issue with Java, so I'm not sure where to go > with this for now, except to report to kernel developers and see what they say. > Perhaps we should add a pkg-message suggesting turning it off? As I understand it, 10.0-RELEASE has a bug that prevents Java, Ruby, Go and other programs from functioning correctly on Sandy Bridge and newer hardware. I dont feel its the responsibility of each port to warn the user that 10.0-RELEASE is broken. This ticket should be close as resolved, since the kernel committers seem to know about it (r262753, r262765). It took a few hours to find this bug via binary searching kernel revisions between 9.1 and 10.0. Posting this knowledge somewhere more visible might save someone else the same frustration. Does this meet the criteria for an errata notice? Andrew
Hi, Agreed. Hopefully there will be an EN soon. Closing PR for now. Steve
State Changed From-To: open->closed Not a ruby bug, closing.