This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Testing status of HVM (Intel VT) on 64bit XEN unstable c

To: Ed Smith <esmith@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Testing status of HVM (Intel VT) on 64bit XEN unstable c/s 11616
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 26 Sep 2006 19:34:19 +0100
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Delivery-date: Tue, 26 Sep 2006 11:44:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <451971F0.4090702@xxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbhmmCwn1orDE2NEduCHAANk04WTA==
Thread-topic: [Xen-devel] Testing status of HVM (Intel VT) on 64bit XEN unstable c/s 11616
User-agent: Microsoft-Entourage/
On 26/9/06 7:31 pm, "Ed Smith" <esmith@xxxxxxxxxxxxxxx> wrote:

> Debug builds are fine and certainly easier to well, debug with, but they often
> run slower than release builds and hide problems.  Humm... I wonder if thats
> why you are not seeing this problem.

It is usually the other way round, since debug builds contain lots of cross
checks and assertions that are not included in production builds. Certainly
a few bugs do only crop up in production builds, and so we test both types
of builds ourselves, but it's rare and the first thing we'll do if we see a
production-build crash is to try and repro with a debug build.

> Also when we rely on debug builds to
> diagnose problems we do not design in the ability to diagnose problems when
> the bits are in customers hands.  'Good training for developers'?  No just
> trying to work towards a released product that is easier to debug because
> just enough debug-ability is built-in.

It's not entirely a diagnosis issue (production build backtraces can be
useful, but as I said they are more hassle). A debug build will often crash
earlier and with more immediately useful information about what has gone

 -- Keir

Xen-devel mailing list