From owner-freebsd-ports@FreeBSD.ORG Thu Nov 1 22:40:30 2007 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 844D516A417 for ; Thu, 1 Nov 2007 22:40:30 +0000 (UTC) (envelope-from lemon+freebsd@zomo.co.uk) Received: from tang.lemonia.org (tang.lemonia.org [88.208.192.38]) by mx1.freebsd.org (Postfix) with ESMTP id 48B5513C48E for ; Thu, 1 Nov 2007 22:40:30 +0000 (UTC) (envelope-from lemon+freebsd@zomo.co.uk) Received: from [86.154.152.116] (helo=always.avalon) by tang.lemonia.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.62 (FreeBSD)) (envelope-from ) id 1InhAy-0004gt-Os; Thu, 01 Nov 2007 21:02:13 +0000 Message-ID: <472A3F63.9010500@zomo.co.uk> Date: Thu, 01 Nov 2007 21:04:35 +0000 From: lemon User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 86.154.152.116 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on tang.lemonia.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on tang.lemonia.org) Subject: ruby18, -pthreads, deep recursion X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 22:40:30 -0000 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