[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Xenvif non-zero byte assertion error during teardown
- To: Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>, win-pv-devel <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
- From: "Durrant, Paul" <pdurrant@xxxxxxxxxxxx>
- Date: Mon, 6 Jul 2026 07:51:25 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amazon.co.uk; dmarc=pass action=none header.from=amazon.co.uk; dkim=pass header.d=amazon.co.uk; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:MIME-Version; bh=dZJilOkYB8R8fHp6xBhAvfKTvSrwnKdlhvbWDdjvjpA=; b=OFBLNLUwugKHl2JL+IYYBgfXX3yPkbPl/jK1sNtygM7oKBWxFP5eJw6DnJ7gKEqoU3yZtz+YeJ8CuCDygFxgXORgrUNsCW4Z3cIbJ1VFP9FwR6JW5Vlz542du1xYGo9r/8gtsb+0ii63IB8RIUgJAtjusfBzMpZriGPreR0wTHeX9XAvhRiP9k5Gzm+D41kdj6uylx8bsuZLlXkGYAl8gqkuWeKvKsEpHSuP6zs/yBtH3wanhfa25wtSQejz2zlrx99SL7Dr70a7cFtcySCkIFUx/camTEWg6atWP2gZXnPovDkecnkYKgK0g9PC5Ussd/GTK7K4qRT5YystUqUHeA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gZAtRBp7UZfwuAjUELfiZeDDgasttrQtav+73TylXLVycSRfM+gjlskJRWpmonJRDm04WqtF1RqjGl/b8ZI0PkLUXk0gQLuAy5EuYfduouSz846mYgQAzRA97lbosiHVUx7Ow9ZJ7zYvT4UpbaxwvLeutxBBKzb336a/EZJJX2Uf37Du1wLEWL6gDTQtRLmoSgeJpZt7CqHabuYj7h9GbmMS5luntDXk7QtlMd5LXDrw0pSbsrOQW1yHeQPccQ9KwENhJfCbVXlbRNBRzbKdpsNJWe+0C0fuZAatD7UrRfILBXTuNI7oUQl64HDiG4E0/QY5C6d6plCrGAdBPf65EQ==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=amazoncorp2 header.d=amazon.co.uk header.i="@amazon.co.uk" header.h="From:To:Date:Message-ID:References:In-Reply-To:Content-ID:Content-Transfer-Encoding:MIME-Version:Subject"
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amazon.co.uk;
- Delivery-date: Mon, 06 Jul 2026 07:51:41 +0000
- List-id: Developer list for the Windows PV Drivers subproject <win-pv-devel.lists.xenproject.org>
- Msip_labels: MSIP_Label_19e68092-05df-4271-8e3e-b2a4c82ba797_Enabled=true;MSIP_Label_19e68092-05df-4271-8e3e-b2a4c82ba797_SetDate=2026-07-06T07:49:28Z;MSIP_Label_19e68092-05df-4271-8e3e-b2a4c82ba797_ContentBits=0;MSIP_Label_19e68092-05df-4271-8e3e-b2a4c82ba797_Enabled=true;MSIP_Label_19e68092-05df-4271-8e3e-b2a4c82ba797_Tag=50, 3, 0, 1;MSIP_Label_19e68092-05df-4271-8e3e-b2a4c82ba797_Name=Confidential;MSIP_Label_19e68092-05df-4271-8e3e-b2a4c82ba797_ActionId=8aa42d9d-0c8d-4abe-9ff9-7b9f49d89e80;MSIP_Label_19e68092-05df-4271-8e3e-b2a4c82ba797_SiteId=5280104a-472d-4538-9ccf-1e1d0efe8b1b;MSIP_Label_19e68092-05df-4271-8e3e-b2a4c82ba797_Method=Standard;
- Thread-index: AQHdCyKfsJpOQb/qzkKKIpiudCPyjLZgMtKA
- Thread-topic: Xenvif non-zero byte assertion error during teardown
> struct _XENVIF_FRONTEND (and likely other structs) are in general full
> of similar padding. So the ASSERT(IsZeroMemory(Frontend)) check is too
> strict in most cases.
>
> I think current IsZeroMemory asserts should either be removed or
> converted to a print-only warning.
What's wrong with zeroing the struct on allocation (which is what is supposed
to happen)?
|
