New Go's 1.2(1)2 heap allocator crashes the app about cloud-game HOT 4 CLOSED

hmm, where in the stack trace shows it is from "type checker"? And this can be filed as bug to GO right?

from cloud-game.

@giongto35, it's in the (*mspan).typePointersOfUnchecked line.
I don't think it is a bug in Go, but rather a race condition during frame encoding and multiple reinitializations of the x264 encoder.
It crashes randomly (right away or on a second attempt) with x264 (but not with vpx), on Windows (but not on cloudretro.io with Linux), on PSX Castlevania where it changes output resolution like crazy, each time recreating the encoder (but if you disable that recreation in the config pcsx.coreAspectRatio: false, it works).
So I assume something has changed in the pointer checker of Go after v1.20, maybe it's way more strict now, and that naïve way of encoder's recreation won't fly anymore. ;/

Well, at least they fixed c-go stack collision introduced in version 1.21, which would burry Go for the project otherwise.

from cloud-game.

After a long debugging session, decided to revert everything back to 1.20 for now.
It crashes under Linux/Windows on Go 1.22 with h264 encoder only (any versions, any settings), when Go's GC is looping over uintptrs and crashing due to the mem corruption. https://tip.golang.org/src/runtime/mbitmap_allocheaders.go
It seems, there are some similar bugs out there in Go, but I couldn't reproduce this issue with an isolated unit test in order to post this bug formally onto the tracker.

Anyways. :/

Steps to reproduce:

1. Compile with 1.22. (branch go1.22)
2. Run some PSX games which change output resolution. (Castelvania, or bundled psxtest)
3. Crash.

from cloud-game.

@giongto35, I think, I fixed it somehow ;/
Removed a wrapper to Go structure over the C x264_param_t structure and now it works, so it seems. Not sure why, but my guess that new allocator from 1.22 goes beyond mem bounds of this struct. That's possible because the Go wrapper is written a long time ago for older versions of x264 and if they change the order or the list of fields, you can easily go out of bounds (due to Go's structs padding or sizeof mismatch) when mapping an old struct to a new one from C.

Will test it, then. Maybe, this will fix it. :/

from cloud-game.