[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xenvif non-zero byte assertion error during teardown


  • To: "Durrant, Paul" <pdurrant@xxxxxxxxxxxx>, win-pv-devel <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>
  • Date: Mon, 6 Jul 2026 11:25:06 +0200
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
  • Delivery-date: Mon, 06 Jul 2026 09:25:11 +0000
  • Feedback-id: default:8631fc262581453bbf619ec5b2062170:Sweego
  • List-id: Developer list for the Windows PV Drivers subproject <win-pv-devel.lists.xenproject.org>

Hello,

On 06/07/2026 09:51, Durrant, Paul wrote:
>> 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)?
> 

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.


--
Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.