FW: adding a red zone at the start of the allocation cause GC issue
Fannie Zhang
Hi all,
Recently, some Asan enabling patches have been merged into master. But the CL https://go-review.googlesource.com/c/go/+/298614 only adds a red zone at the end of the allocation, it may cause -asan option to fail to detect underflows, Ian commented on this CL that a red zone may be added at the start of the allocation.
Unfortunately, the modification will cause a GC issue. Because the process of Go memory allocation and GC are closely linked, like mallocgc() calls heapBitsSetType() to set heap bitmap for the new allocation.
If adding a red zone at the start of the allocation, the allocated pointer that returned is not equal to “(span().base + s.elemsize*freeidx), it is equal to “(span().base +s.elemsize*freeidx + redZoneSize)”. I do not know whether this behavior will break some of underlying assumptions in GC.
The modification patch is https://go-review.googlesource.com/c/go/+/361966.
The test case is https://play.golang.org/p/B_nXGywju4w.
The command: go run -asan test.go
I am not very familiar with the whole GC process, the related change may be wrong, or it may miss important things. If you have time, can you please take a look and give me some comments?
Thank you very much!
Best regards,
Fannie Zhang
Keith Randall
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/PAXPR08MB6640BF62E7648E3D3B32D85894939%40PAXPR08MB6640.eurprd08.prod.outlook.com.