Date: Mon, 11 Dec 2006 17:01:00 -0800 From: Julian Elischer <julian@elischer.org> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD Current <current@freebsd.org>, Kris Kennaway <kris@obsecurity.org> Subject: Re: kdb_backtrace 'feature'? Message-ID: <457DFF4C.2010806@elischer.org> In-Reply-To: <457DFB48.7020704@elischer.org> References: <457DE51C.905@elischer.org> <20061212001154.GA87602@xor.obsecurity.org> <457DFB48.7020704@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > Kris Kennaway wrote: >> On Mon, Dec 11, 2006 at 03:09:16PM -0800, Julian Elischer wrote: >>> I often have the following: >>> >>> >>> code x() does some bad thing 'A'.. it's a known thing and you can tell >>> where it was done from (x()) but x() tell at the time that it is bad. >>> >>> at some later time, you discover 'A' is bad but now you don't know who >>> was teh bad caller of x() >>> >>> >>> The solution I'm looking for: >>> >>> when x() is called it calls kdb_backtrace, but has teh backtrace >>> written to a static 16K buffer instead of being put out the normal way. >>> >>> when A is found to be wrong, we can see who the last caller of x() was >>> and how it was called. >>> >>> >>> I am looking at it now.. but if anyone has any thoughts let me know... >> >> See <sys/stack.h> > > interesting... is there any documentation on how to use this and what > its limitations are? > > man -k stack doesn't provide anything.. grrrrr. cute.. after reading code.. interesting but it doesn't save any arguments.. but definitly interesting.. thanks for pointing it out. I missed that being added.. > > >> >> Kris > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?457DFF4C.2010806>