I have a Windows console app with a consistent repro of my 5950x writing to the first byte of a 4k page with a constant that's the same as a typical fill pattern for the app. I added code to my app to create write breakpoints for such allocations for all threads in the app, and that breakpoint is never hit. So I'm guessing it's a processor bug that mistakenly writes to the wrong memory location occasionally.
I created my own operator new that adds 16 bytes of padding before and after each allocation to better track the problem. It's in that allocator that I hook the 2 >1k allocations per JPG file processed for the first two threads that come in and set memory write breakpoints on the first byte of the "after" padding. The "after" padding is filled with the character 'a'. The app regularly validates that the padding hasn't been trashed. When memory is freed, I fill it all with '$'. I detect the problem when the "after" padding is 4k-page aligned and the first byte is '$' instead of 'a'. Surrounding bytes aren't trashed. I am certain my app doesn't have a stray write -- I only write fill patterns 8 bytes at a time and as I said the write breakpoints are never hit.
The C++ app uses PPL's parallel_for to use many cores to enumerate about 91,000 JPG files then iterates through the files to extract Exif data. I simplified the code substantially to just retrieve a handful of exif values and still get a repro of the bug.
The bug happens more frequently using all 32 cores, but still reproes easily when the app is constrained to 7 cores.
Is this a known processor bug? I have a minidump file and all the source code if you want.
Thanks
