Ruby port includes some patch that makes it broken. I don't know what exactly patch makes it broken, and don't care. It dumps core on large call stacks. Some code on which it dumps core actually work on Mac OS X and linux (aka anywhere else I tested). Fix: curl ftp://ftp.ruby-lang.org:21//pub/ruby/1.8/ruby-1.8.6-p287.tar.bz2 -o ruby-1.8.6-p287.tar.bz2 && \ tar -jxvf ruby-1.8.6-p287.tar.bz2 && \ cd ruby-1.8.6-p287 && \ ./configure --prefix=/usr/local/ruby186 --with-iconv-dir=/usr/local && \ make all install (aka install from source code) How-To-Repeat: 1) Install freebsd from ports 2) type: irb 3) type in irb: def a; a; end; a 4) ???? 5) Profit! It outputs "Illegal instruction: 4" and dumps core. Expected: SystemStackError: stack level too deep from (irb):1:in `a' from (irb):1:in `a' from (irb):1
Responsible Changed From-To: freebsd-ports-bugs->ruby
Responsible Changed From-To: ruby->stas Assign
Hi! Thank you for a bug report. I expect it will be fixed soon. Fixing it appears to be a lot harder that it seems the firts time. The problem is more deeper than it seems. The FreeBSD port of ruby links ruby binary against pthreads to solve compatibility problems with threaded libraries (so you can use the same unthreaded ruby binary with both threaded and non-threaded libraries). The root of the issue is in the fact that ruby uses getrlimit call to get the current stack limit. This obviously is a complete noncense in the threaded case. The nonportable POSIX threads extension to get the current thread's stack limit should be used in that case. The other side of the problem is the ruby stack overflow detector is completely opportunistic. That is it only checks for stack overflow only every 256th call of rb_call0, so it is often unable to prevent stack overflow when stack sizes are small enough, which is the case with FreeBSD threads. The reason it may not fail on Linux is that Linux seem to use gratuitously large thread stack sizes by default, so it doesn't overflow fast. Ruby reserves up to 1/5 of the available stack size, so if the stack size is too small this reservation is just not enough for another 256 calls of rb_call0. I'm currently working on the solution to this problem, as decreasing check interval doesn't look right as it will increase overhead as well. I'm not yet sure what is the best way to solve this. -- Stanislav Sedov ST4096-RIPE
stas 2009-06-19 12:42:45 UTC FreeBSD ports repository Modified files: Mk bsd.ruby.mk lang/ruby18 Makefile lang/ruby18/files patch-gc.c Added files: lang/ruby18/files patch-configure.in Log: - Fix stack overflow detection algorithm. It has not worked before as we were linking the ruby binary against pthreads, and the default stack size detection method with getrlimit didn't returned right values in this case. Now, if threads enabled, it also tries to determine the stack size via pthreads calls and use this value if it is smaller than what getrlimit returned. Furthermore, the stack overflow detection routine now works proactively, generating exception if there're probability the stack will be exhausted by the time of the next check (ruby performs checks only in each 256th call of rb_call0). [1] - Build pthreads-enabled ruby by default. I have not received any bug reports for this for years, and this verison will work correctly with threaded libraries. Also, do not link agains pthreads in non-pthread case (this breaks stack size detection algorithm), and eliminate the option to disable pthreads (so only power users who know what they're doing can disable them). - Build RDoc by default so it is available in the package. - Bump portrevision. PR: ports/132158 Reported by: Eugene Pimenov <libc@libc.st> Revision Changes Path 1.185 +2 -2 ports/Mk/bsd.ruby.mk 1.143 +10 -16 ports/lang/ruby18/Makefile 1.1 +35 -0 ports/lang/ruby18/files/patch-configure.in (new) 1.4 +138 -3 ports/lang/ruby18/files/patch-gc.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed Fixed in last revision.