On Thursday 01 November 2007 04:04:35 pm lemon wrote: > Hi, > > I've been struggling with FreeBSD's ruby18 port and threads. I realise > there's previous discussion[0] about this and I feel I'm blundering > somewhat, but here goes. > > On both 7.x and 6.x boxes I've built ruby18 with the pthreads knob > deliberately turned off (the default). The resultant ruby has problems > with deep recursion, shown by this script[1] but less pathologically in > production in a busy RoR site too. > > $ ruby -e 'def d(x); p x; d x+1; end; d 0' > > This bombs with SIGILL[2]. > > I note that, as per the conversations linked above, this build uses the > GCC option -pthread and links against libthr[3]. > > If I build the port without -pthread (and related config.h #define), > install the library alongside the from-port one, and employ the > resultant binary with some libmap.conf guidance I get a ruby which > behaves far nicer[4]. I can recurse way deeper and receive a graceful > SystemStackError exception when things hit the wall[5]. > > What's the score here? Clearly there's motive for building like it does, > but the hacked ruby works better for me in everyday life. Any ideas? > > I hope this is on-topic for freebsd-ports. I mailed the maintainer first > but got no response. > > Regards, l. > > [0] > http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019352.html > http://lists.freebsd.org/pipermail/freebsd-ports/2006-March/030691.html > > [1] Google found me this, I forget where! > > [2] $ ruby -e 'def d(x); p x; d x+1; end; d 0' | head > 0 > 1 > 2 > ... > 2138 > 2139 > Illegal instruction: 4 > > [3] $ ldd `which ruby` > /usr/local/bin/ruby: > libruby18.so.18 => /usr/local/lib/libruby18.so.18 (0x2807d000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x28154000) > libm.so.5 => /lib/libm.so.5 (0x2816d000) > libthr.so.3 => /lib/libthr.so.3 (0x28182000) > libc.so.7 => /lib/libc.so.7 (0x28195000) > > [4] $ ldd ~/tmp/ruby18 > /home/lemon/tmp/ruby18: > libruby18.so.18 => /usr/local/lib/libruby18-nothread.so.18 > (0x2807d000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x28154000) > libm.so.5 => /lib/libm.so.5 (0x2816d000) > libc.so.7 => /lib/libc.so.7 (0x28182000) > > [5] $ ~/tmp/ruby18 -e 'def d(x); p x; d x+1; end; d 0' > 0 > 1 > 2 > ... > 67705 > 67706 > -e:1:in `inspect': stack level too deep (SystemStackError) > from -e:1:in `p' > from -e:1:in `d' > from -e:1:in `d' > from -e:1
If it's any consolation, I've emailed the ruby maintainer a few times about why disabling threads in the port's menu doesn't *really* disable threads and have never gotten a reply. In my case though the damage from the 'sort of threaded' ruby that the port builds with the threads option turned off is far more insiduous. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
signature.asc
Description: This is a digitally signed message part.
