Date: Mon, 20 Mar 2006 22:05:15 -0800 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Ganbold <ganbold@micom.mng.net> Cc: freebsd-current@freebsd.org Subject: Re: rcorder problem when booting CURRENT Message-ID: <20060321060515.GB31874@flame.pc> In-Reply-To: <441F8014.4040003@micom.mng.net> References: <441F7635.4090300@micom.mng.net> <441F7991.8000505@micom.mng.net> <441F7635.4090300@micom.mng.net> <20060321041219.GA31213@flame.pc> <441F8014.4040003@micom.mng.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2006-03-21 12:24, Ganbold <ganbold@micom.mng.net> wrote:
> Giorgos Keramidas wrote:
> >Still a core dump is a core dump. Can you build a debugging version of
> >rcorder and try again? This time the stack trace may be more useful.
>
> How to enable debugging? I manually added in rcorder.c:
>
> #define DEBUG 1
> #ifdef DEBUG
> int debug = 1; /* changed to from 0 to 1 */
>
> Maybe above is wrong.
Indeed, it is not really right. The right way of building a debugging
executable that is part of the FreeBSD base system is to use DEBUG_FLAGS:
# cd /usr/src/sbin/rcorder
# make cleandir
# make cleandir
# env DEBUG_FLAGS='-g' make obj all install
Then you should have a `/sbin/rcorder' executable that is not stripped
and includes debugging information. After it dumps core, please let us
know of the new backtrace.
Thank you for taking the time to do all these tests to track down why
rcorder dumps core in this case :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060321060515.GB31874>