Date: Thu, 1 Nov 2007 22:02:38 -0500 From: Josh Paetzel <josh@tcbug.org> To: freebsd-ports@freebsd.org Cc: lemon <lemon+freebsd@zomo.co.uk> Subject: Re: ruby18, -pthreads, deep recursion Message-ID: <200711012202.42025.josh@tcbug.org> In-Reply-To: <472A3F63.9010500@zomo.co.uk> References: <472A3F63.9010500@zomo.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1719375.3K7gjlXTGk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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.ht= ml > > [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 =3D> /usr/local/lib/libruby18.so.18 (0x2807d000) > libcrypt.so.4 =3D> /lib/libcrypt.so.4 (0x28154000) > libm.so.5 =3D> /lib/libm.so.5 (0x2816d000) > libthr.so.3 =3D> /lib/libthr.so.3 (0x28182000) > libc.so.7 =3D> /lib/libc.so.7 (0x28195000) > > [4] $ ldd ~/tmp/ruby18 > /home/lemon/tmp/ruby18: > libruby18.so.18 =3D> /usr/local/lib/libruby18-nothread.so.18 > (0x2807d000) > libcrypt.so.4 =3D> /lib/libcrypt.so.4 (0x28154000) > libm.so.5 =3D> /lib/libm.so.5 (0x2816d000) > libc.so.7 =3D> /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= =20 why disabling threads in the port's menu doesn't *really* disable threads a= nd=20 have never gotten a reply. In my case though the damage from the 'sort of threaded' ruby that the port= =20 builds with the threads option turned off is far more insiduous. =2D-=20 Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB --nextPart1719375.3K7gjlXTGk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHKpNSJvkB8SevrssRAv9kAJ9NZ49C2Sfb1CGmuHzIrJtcyJw18gCgjgf9 diCN2rAbavAjC0SgwKslgeA= =bPf+ -----END PGP SIGNATURE----- --nextPart1719375.3K7gjlXTGk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711012202.42025.josh>