Date: Tue, 11 Dec 2007 12:10:03 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Ed Maste <emaste@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: gcore thread problem? Message-ID: <20071211201003.GA61429@elvis.mu.org> In-Reply-To: <20071211195541.GA51608@sandvine.com> References: <90242b1f0611220412l4ef4c92jd6f3e308f7c882fd@mail.gmail.com> <20071211195541.GA51608@sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Ed Maste <emaste@freebsd.org> [071211 12:08] wrote: > On Wed, Nov 22, 2006 at 05:42:33PM +0530, Vaidehi Shukla wrote: > > > 'gcore' doesn't display correct backtrace (info threads) for multi-threaded > > application. Is there any way to get correct backtrace (i.e. info threads) > > with gcore in freebsd?. Let me know if you can suggest some method to get > > correct backtrace. > > I've patched gcore to use the ptrace(2) interface instead of procfs to get > the per-thread state and plan to commit this in the not-too-distant future. > > One issue with the change though is that gcore can currently create a core > asynchronously (i.e., without stopping the process). The core may have > inconsistent data in it in this case, but it may be that the process is > critical and cannot be stopped during the core creation. The ptrace > change I made requires the process to be stopped for at least a short > interval. Can you leave in the procfs utility as well? This seems to be somewhat of a step backwards as you are quite correct that there may be a critical process that can not be stopped. -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071211201003.GA61429>