From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9O84-0001MW-Ee for qemu-devel@nongnu.org; Thu, 29 Sep 2011 17:26:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R9O83-0001Q0-8z for qemu-devel@nongnu.org; Thu, 29 Sep 2011 17:26:52 -0400 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:58830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9O83-0001Pv-2I for qemu-devel@nongnu.org; Thu, 29 Sep 2011 17:26:51 -0400 Message-ID: <4E84E296.3070807@mail.berlios.de> Date: Thu, 29 Sep 2011 23:26:46 +0200 From: Stefan Weil MIME-Version: 1.0 References: <4E83F86B.2020208@mail.berlios.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Remove line buffering from log file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: bernard.blackham@nicta.com.au, Peter Maydell , Peter Chubb , qemu-devel@nongnu.org, philipo@ok-labs.com Am 29.09.2011 22:11, schrieb Blue Swirl: > On Thu, Sep 29, 2011 at 7:57 AM, Peter Maydell > wrote: >> On 29 September 2011 06:03, Peter Chubb wrote: >>> Stefan> That's the reason why line buffering is needed today. I >>> Stefan> enable log file output to see what happened last before the >>> Stefan> crash. >>> >>> Thanks for this, I didn't think of this use-case. I don't think I've >>> ever seen a qemu crash that wasn't caused by something really obvious. >> >> You don't need the logging for the obvious ones :-) >> >>> abort() already flushes all open streams. So only signals that cause >>> immediate death are a problem: SIGSEGV is the obvious one. If its >>> handler called abort() then that would flush too. abort() is >>> guaranteed by the POSIX spec to be callable from a signal handler. >> >> Catching SIGSEGV is likely to interact badly with the signal >> handling in linux-user mode, I expect. >> >>> Stefan> Speed is not the primary target when somebody runs qemu -d ... >>> >>> It is if it takes hours to reach the problem that causes >>> the abort(). Speeding up by an order of magnitude is worth it. >> >> One tactic I've found useful in these cases is to run without >> logging up to nearly the point where things fail, and then >> do a savevm. Then you can loadvm on a qemu with logging enabled >> and only look at the section of execution that causes the problem. > > This sounds like it should be possible to enable and disable logging > during run time. The QEMU monitor already supports setting the log level via command 'log'. I used this command to examine problems with some user commands running in an emulated Linux. > The performance could be improved by taking a trace point like > approach, where all possible processing is postponed to outside > process. Guest and host code disassembly and op printout could be left > to postprocessing, the logs should contain only binary data.