Date: Sun, 12 Nov 2006 17:03:21 -0500 From: Josh Paetzel <josh@tcbug.org> To: freebsd-hackers@freebsd.org Cc: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> Subject: Re: Epic5-0.3.1 ruby support and FreeBSD AMD64 problem Message-ID: <200611121603.22085.josh@tcbug.org> In-Reply-To: <17751.36500.33990.809115@bhuda.mired.org> References: <200611121143.22391.josh@tcbug.org> <17751.36500.33990.809115@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 12 November 2006 15:13, Mike Meyer wrote: > In <200611121143.22391.josh@tcbug.org>, Josh Paetzel=20 <josh@tcbug.org> typed: > > I'm the port maintainer for irc/epic4 and irc/epic5 and try to > > liason with the developers as much as possible. I've received a > > request from the Epic developers that I can't really help with > > and I'm wondering if someone would be willing to be able to lend > > them a hand. > > > > Epic5-0.3.1 includes optional ruby support. When ruby support is > > compiled in on an AMD64 box attempting to use gdb on it > > spontainiously reboots the box, no panic, no hang, just a hard > > reset. The problem has been verified to occur on 5-STABLE and > > 6-STABLE on multiple machines. It does not occur if the gdb from > > devel/gdb6 is used. > > > > At the moment I'm dealing with the situation by keeping the port > > at 5.0.2.0 but I'm getting more and more requests to get 0.3.1 > > into the tree. Given the nature of the problem doing so at this > > point means either not having the ruby support in the port or > > marking it broken for AMD64, neither of which are particularly > > attractive. > > Why not test for both conditions? I.e. - if ruby support is > included (you did say it was optional) AND if you're on amd64, then > mark the port as broken? Better yet, since using devel/gdb6 seems > to fix the problem, use devel/gdb6 under those conditions. Or - to > keep it simple - always use devel/gdb6. > > Note that getting this problem fixed won't meean you can ignore it. > If you want to avoid building with the workaround (whatever that > may be) on amd64 after the fix has been committed, you'll have to > check the OS version, and optionally build with the workaround if > someone is installing the fix on an earlier version of FreeBSD. > > <mike You're right. The workaround could be more sophisticated. Thanks for=20 pointing that out. I guess my perspective is that this issue is=20 being caused by a problem in the code for epic, not a bug in FBSD. =20 =46rom the wording of your email I sort of get the impression you are=20 thinking along the lines of it being a FreeBSD bug? =20 My main plea is for someone familiar with FBSD to volunteer to give=20 these guys a hand in tracking this down. :) =2D-=20 Thanks, Josh Paetzel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611121603.22085.josh>