Golang runtime: TestMemmoveOverlapLarge0x120000 failures

#!watchflakes
post <- pkg == "runtime" && test == "TestMemmoveOverlapLarge0x120000"

Issue created automatically to collect these failures.

Example (log):

--- FAIL: TestMemmoveOverlapLarge0x120000 (5.25s)
    memmove_test.go:166: Copy failed, copying from src[8:4615] to dst[1:4608].
        Offset 360448 is different, 180 != 180

— watchflakes

Comment From: gopherbot

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "runtime" && test == "TestMemmoveOverlapLarge0x120000"

2023-04-04 21:20 darwin-amd64-12_0 go@2f2b874b runtime.TestMemmoveOverlapLarge0x120000 (log)

--- FAIL: TestMemmoveOverlapLarge0x120000 (5.25s) memmove_test.go:166: Copy failed, copying from src[8:4615] to dst[1:4608]. Offset 360448 is different, 180 != 180

— watchflakes

Comment From: cherrymui

The test code doesn't look racy. This is copying test[8:4615] to test[1:4608], and the memory at offset 360448 isn't even being touched. So it doesn't look like a bug in memmove implementation. Also doesn't look like a compiler bug, otherwise I'd expect it fails more deterministically.

Maybe a memory error? 360448 is 0x58000. Maybe there is some glitch at page boundary?

Comment From: bcmills

The 180 != 180 part of that log message is also suspicious, since it seems to indicate that the value went back to being equal after the comparison.

Could be register corruption during the call to matchLen? (Maybe the call got interrupted by a signal?)

Comment From: bcmills

(Might be related to #49233, perhaps?)

Comment From: gopherbot

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "runtime" && test == "TestMemmoveOverlapLarge0x120000"

2025-07-09 15:28 gotip-linux-arm64-asan-clang15 go@67c17044 runtime.TestMemmoveOverlapLarge0x120000 [SKIP] (log)