From: Peter Maydell <peter.maydell@linaro.org>
To: Peter Chubb <peter.chubb@nicta.com.au>
Cc: bernard.blackham@nicta.com.au, qemu-devel@nongnu.org,
philipo@ok-labs.com
Subject: Re: [Qemu-devel] [PATCH] Remove line buffering from log file
Date: Thu, 29 Sep 2011 08:57:00 +0100 [thread overview]
Message-ID: <CAFEAcA_mLFqC0yDjM9bmSVWqRBiG8SNpYUnEU64HPH2FR_aGXg@mail.gmail.com> (raw)
In-Reply-To: <w4vcscym6e.wl%peter@chubb.wattle.id.au>
On 29 September 2011 06:03, Peter Chubb <peter.chubb@nicta.com.au> 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.
-- PMM
next prev parent reply other threads:[~2011-09-29 7:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 2:43 [Qemu-devel] [PATCH] Remove line buffering from log file Peter Chubb
2011-09-29 4:47 ` Stefan Weil
2011-09-29 5:03 ` Peter Chubb
2011-09-29 7:57 ` Peter Maydell [this message]
2011-09-29 20:11 ` Blue Swirl
2011-09-29 21:26 ` Stefan Weil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA_mLFqC0yDjM9bmSVWqRBiG8SNpYUnEU64HPH2FR_aGXg@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=bernard.blackham@nicta.com.au \
--cc=peter.chubb@nicta.com.au \
--cc=philipo@ok-labs.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).