Occasional errors for NumPage() under high concurrency about go-fitz HOT 4 CLOSED

package main

import (
	_ "embed"
	"sync"

	"github.com/gen2brain/go-fitz"
)

//go:embed test.pdf
var pdf []byte

var routines = 10_000

func main() {
	wg := new(sync.WaitGroup)
	wg.Add(routines)
	for i := 0; i < routines; i++ {
		go func(r int, g *sync.WaitGroup) {
			defer g.Done()
			numPage(r)
		}(i, wg)
	}
	wg.Wait()
	println("Done")
}

func numPage(routine int) {
	// Simulate concurrent requests by deep copying the bytes.
	// The original slice is a package level variable, hence
	// it won't be GC'ed. But a function level copy of this
	// slice might be collected very early.
	c := make([]byte, len(pdf))
	copy(c, pdf)

	doc, _ := fitz.NewFromMemory(c)
	// From now on doc saves a raw memory range of bytes.
	// There is no other Go reference of c. Apparently, this
	// causes the GC to trigger its eviction.

	defer doc.Close()
	num := doc.NumPage()

	if num != 3 {
		println("Routine:", routine, "| Num pages:", num)
		// If we assume that the error is caused by the GC
		// evicting our byte slice copy too eagerly, then we
		// need to somehow force the byte slice to remain in
		// memory.

		// Uncomment the following line for the PoC fix:
		// println(c)

		// If it's indeed rectifying the issue, then the
		// above println must never print anything, since
		// doc.NumPage() will now always provide correct
		// results, i.e. 3.
	}
}