qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] contrib/elf2dmp: a workaround for the buggy msvcrt.dll!fwrit


From: Peter Maydell
Subject: Re: [PATCH] contrib/elf2dmp: a workaround for the buggy msvcrt.dll!fwrite
Date: Wed, 10 Jul 2024 17:25:30 +0100

On Wed, 10 Jul 2024 at 09:02, hellord <halouworls@gmail.com> wrote:
>
>
>>
>>
>> On Tue, Jul 9, 2024 at 10:39 PM Peter Maydell <peter.maydell@linaro.org> 
>> wrote:
>> Is there a particular reason to use 128MB here? If the
>> runtime only fails on 4GB or more, maybe we should use
>> a larger MAX_CHUNK_SIZE, like 2GB ?
>
>
> According to current analysis, size <= 4GB all are safe, however there are 
> many
> versions of msvcrt, this bug exists on Server 2008/2019/2022 and Windows 
> 11(all
> with full latest updates), and it may also exist in other versions, but it is 
> difficult to
> check each version individually. I am not sure if all versions handle 
> boundary sizes
> like 2GB/4GB correctly. So I prefer a relatively conservative value: 128MB.
>
> Maybe we could use #ifdef _WIN32 to differentiate the handling between Linux 
> and
> Windows. For Linux, it remains unchanged, while for Windows, it processes by 
> chunks
> with max_chunk_sizeto 1GB.

I don't think it's worth making this Windows-specific. I agree that
it's OK to be a bit conservative, but 128MB seems to me extremely
conservative. I think we could say, for instance, 512MB or 1GB, without
being at much danger of running into broken implementations here.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]