[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 09:32:19 +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=12ISgU8ZHyY4qPAdqYxEKUiz+5B1UyB1nEKLGCxNt3Y=; b=K2wXz67ayX2wv1QBocdGM8dNIYyZNZtF5unJ5Np7KXNFlcVkE8jMvlr7J9FxcLBzwUZa4U06IDMJ8kEH4dbiS8cHh2rTmLVsrEmlZ0W3/Rij+zRjvMSxKvnBzEN2QOB/4s7Ekve+dJ6NAjcvLVWejiApr+ioonKuBaqVmdepKgvYO7dlBcAcp9p1m8ZgvPRDD3afm6E2FUOaFTvzg7BWt4hBYYlV4p53qHTOShZcyHeZnyUvoa8XW0K3PppBMY6ZVngOVMxmfoknVCz8cPPycTIhrSFa3sCGii56bsgM6FEpKhY2HM5sqcW3iFvhpA91PRREkEDMmrU5oxBY+Ri3aw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=U7hNwA2l2yA9eIraEayKmnySJMYhLKnyOMXWHLh41NpLCzleAiiLdIbiqXicpyOL6GTCrzmruJvb9am8RIw6GsbfCijFZj7HOxaCoskz2NKJXxwuSpnax/qW6ClKw3BvjSI2LjH1ubl2Lbhk+16bk3KsUcafyhmnQAHj39jWrpvefNEQQ3cfqMXQM15YThwSGaYLfJh/VU+3geoyteLTOSjafY0mYmIB0/yQ5trKrS1BqjPJk0jVSCZq2ziiRAVFldd+7aVvPCGBMBjVDq6i7FiJIaCzYrKwYgkdn3rbAcxGejiYmtaubr+mYDvZgm2l0zRrBAjFswoY8F54BZDJdg==
- 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 09:32:46 +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-06T09:30:59Z;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=90b22752-0fde-4701-a7a2-69140729140f;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/qzkKKIpiudCPyjLZgMtKAgAAJkgCAABLIgA==
- Thread-topic: Xenvif non-zero byte assertion error during teardown
>>
>> What's wrong with zeroing the struct on allocation (which is what is
>> supposed to happen)?
>>
>
>
> Struct padding bytes have unspecified values and compilers are free to
> emit code that overwrite them even if we don't access them directly. So
> even if a structure was zeroed on initialization, its padding can't be
> guaranteed to remain zero on teardown.
Make the padding explicit then... that should avoid the issue without removing
the check (which *has* caught leaks in the past).
|
