Wild pointer detected with ASAN during source build

Hi,

We have a regression test system based on Python in Windows OS. Recently we updated to VS 2022 and investigated using the Address Sanitizer feature - https://docs.microsoft.com/en-us/cpp/sanitizers/asan?view=msvc-170

In order for us to utilise the feature we need to python from source with the compile option /fsanitize=address enabled.
we have tried with 3.8.1 and 3.9.13 (we tried with latest 3.10.7 but encounter an issue with nuget.exe fetching python
x86 - https://stackoverflow.com/questions/73411602/unable-to-find-package-pythonx86-via-nuget)

On both 3.81 and 3.9.13 we are able to build from source python with no issue however with address sanitizer enabled we encounter the following wild pointer error :

==5104==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x02302010 at pc 0x68d65232 bp 0x00cfefbc sp 0x00cfefb0
READ of size 4 at 0x02302010 thread T0
**** CALL STACK ****
Address 0x02302010 is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow C:\Users\livuser\Downloads\Python-3.9.13\Python-3.9.13_pre\Objects\obmalloc.c:1420 in address_in_range
Shadow bytes around the buggy address:
**** VISUAL OF BUGGY MEMORY ****

Full output of build.bat is attached as output.log

To set up it is a little tedious as each project file (.vcproj) used in the pcbuild solution requires the following lines adding since we don't have easy access to the compile commands through the bat file

VCPROJ addition (had to remove < these braces > due to text editor hiding entries):
PropertyGroup
EnableASAN true /EnableASAN
/PropertyGroup

Has Python been built with the address sanitizer tool enabled? In Linux it is easy as we can just apply LD_PRELOAD to provide the address sanitizer as a shared library but this is less trivial in Windows OS which is our primary use case.

Thanks in advance for any input on this issue!
Richard

output.log

Beginnen Sie mit der angehängten output.log und Objects/obmalloc.c bei address_in_range (Zeile 1420), und überprüfen Sie anschließend build.bat sowie die pcbuild-Projektdateien, in denen /fsanitize=address hinzugefügt wurde. Reproduzieren Sie den Windows-Quellbuild mit ASAN und stellen Sie fest, ob der gemeldete Zugriff des Allokators ein Problem eines unterstützten Builds oder ein Fehler ist; abgeschlossen bedeutet eine bestätigte Ursache und eine Regressionstestabdeckung oder eine dokumentierte Einschränkung.