Re: ruby18, -pthreads, deep recursion
Marcin Wisnicki wrote: On Thu, 01 Nov 2007 22:02:38 -0500, Josh Paetzel wrote: On Thursday 01 November 2007 04:04:35 pm lemon wrote: [0] http://lists.freebsd.org/pipermail/freebsd-ports/2005- January/019352.html http://lists.freebsd.org/pipermail/freebsd-ports/2006- March/030691.html 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. As explained in abovementioned links, some of ruby extensions need pthreads but since shared modules on freebsd are never linked with threading libraries (i think it might no longer be true in releng7/ current), you have no other choice than to link ruby interpreter binary with libpthread. Thanks, that's much clearer for me now. I guess I'm lucky - I've yet to hit anything involved in our RoR app that breaks a pthread-less ruby18 on 6.2-R. Even better if the problem's gone away on 7.x. Cheers for all the responses. Regards, l. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ruby18, -pthreads, deep recursion
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.
Re: ruby18, -pthreads, deep recursion
On Thu, 01 Nov 2007 22:02:38 -0500, Josh Paetzel wrote: On Thursday 01 November 2007 04:04:35 pm lemon wrote: [0] http://lists.freebsd.org/pipermail/freebsd-ports/2005- January/019352.html http://lists.freebsd.org/pipermail/freebsd-ports/2006- March/030691.html 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. As explained in abovementioned links, some of ruby extensions need pthreads but since shared modules on freebsd are never linked with threading libraries (i think it might no longer be true in releng7/ current), you have no other choice than to link ruby interpreter binary with libpthread. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ruby18, -pthreads, deep recursion
On Fri, 02 Nov 2007 11:37:07 -0500, Marcin Wisnicki [EMAIL PROTECTED] wrote: On Thu, 01 Nov 2007 22:02:38 -0500, Josh Paetzel wrote: On Thursday 01 November 2007 04:04:35 pm lemon wrote: [0] http://lists.freebsd.org/pipermail/freebsd-ports/2005- January/019352.html http://lists.freebsd.org/pipermail/freebsd-ports/2006- March/030691.html 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. As explained in abovementioned links, some of ruby extensions need pthreads but since shared modules on freebsd are never linked with threading libraries (i think it might no longer be true in releng7/ current), you have no other choice than to link ruby interpreter binary with libpthread. I must be behind with -pthread stuff for FreeBSD 7.x/-CURRENT. If it's doesn't need -pthread any longer, then it's awsome. We can add a new check of if system is below than 7.x then force add -pthread in ruby port. It will need a lot of test first before maintainer or someone to commit this change. I don't mind to test on ruby-gtk2/ruby-gnome2 in RELENG_7 by remove -pthread from ruby port. Cheers, Mezz -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ruby18, -pthreads, deep recursion
On Fri, 02 Nov 2007 18:30:13 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: On Fri, 02 Nov 2007 11:37:07 -0500, Marcin Wisnicki [EMAIL PROTECTED] wrote: On Thu, 01 Nov 2007 22:02:38 -0500, Josh Paetzel wrote: On Thursday 01 November 2007 04:04:35 pm lemon wrote: [0] http://lists.freebsd.org/pipermail/freebsd-ports/2005- January/019352.html http://lists.freebsd.org/pipermail/freebsd-ports/2006- March/030691.html 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. As explained in abovementioned links, some of ruby extensions need pthreads but since shared modules on freebsd are never linked with threading libraries (i think it might no longer be true in releng7/ current), you have no other choice than to link ruby interpreter binary with libpthread. I must be behind with -pthread stuff for FreeBSD 7.x/-CURRENT. If it's doesn't need -pthread any longer, then it's awsome. We can add a new check of if system is below than 7.x then force add -pthread in ruby port. It will need a lot of test first before maintainer or someone to commit this change. I don't mind to test on ruby-gtk2/ruby-gnome2 in RELENG_7 by remove -pthread from ruby port. Yep, ruby-gtk2/ruby-gnome2 work great with ruby compiled without -pthread on RELENG_7. Nice! My suggest of add a new check should make everybody more happy. % ldd /usr/local/bin/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) libc.so.7 = /lib/libc.so.7 (0x28182000) % ruby /usr/local/share/examples/ruby18/gtk2/misc/filechooser.rb [...no crash...] % ruby /usr/local/share/examples/ruby18/gtk2/misc/fileselection.rb [...no crash...] Cheers, Mezz Cheers, Mezz -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ruby18, -pthreads, deep recursion
On Thu, 01 Nov 2007 16:04:35 -0500, lemon [EMAIL PROTECTED] 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. People did a lot of test for lofi and me. You can see http://freebsd.rambler.ru/bsdmail/cvs-all_2005/msg08680.html ... Have ruby compiles without -pthread breaks more stuff than with -pthread. But we can't enable thread option because it also break more stuff than disable thread support. Weird? As for your problem of ruby with -pthread. I have known about that problem and there used to have a PR of it, but I can't find that PR. It was only a problem that ruby with -pthread is causing. I am not going to work on ruby all over again, so don't ask me. :-) I am hoping that someone can bring 100% solution, but we haven't get Mr. Right for ruby yet. Maybe Ruby 1.9 or 2.x with new VM/thread will solve this problem or not. Cheers, Mezz Regards, l. snip -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
