I want to vent my frustration. The experience of contributing has been
unpleasant for me. I have noticed that similar fixes are prioritized and
merged faster, while I spent time resolving the issue and reporting it, but
it did not receive an effective merge. Although it was during the freeze
pe
Thanks for the reproducer. I think I've puzzled out what's going wrong and
it's pretty subtle.
TL;DR: You can work around this by either calling `calloc` or just
allocating `inRows` as Go memory and pinning that as well. The latter will
be safer and faster overall. It's not totally clear to me at
Michael,
The OP appears to have lost interest in debugging. Here's my minimal,
reproducible example that produces the same fatal errror:
https://go.dev/play/p/flEmSh1euqR (run locally)
If the runtime.GC() statement is uncommented then the fatal error does not
occur.
The use of this profli
go version go1.21.5 windows/amd64
There have been 9 garbage collections according to NumGC and also the
PauseEnd array; However, the PauseNs array only shows two pause times, and
they are incorrectly positioned in the array (the first time is logged at
PauseNs[4] rather than PauseNs[0])
Can an
In the twelfth garbage collection of a short program I ran, GC trace
reports the goal heap size as 735 MB (see below for gc11, gc12 and gc13
from GC trace) I also checked runtime Memstats (see attached image), and
it says the nextGC target after 12 GCs have run is 838103616.
Should goal Heap
The proposal says:
To ensure backwards compatibility with existing code, the new semantics
will only apply in packages contained in modules that declare go 1.22 or
later in their go.mod files. This per-module decision provides developer
control of a gradual update to the new semantics througho
