Klaus Post

@greenx Are you sure this isn't just because it isn't printed? Did you confirm this on the sever side?

Could look like some Go magic. I will look a bit deeper into it.

https://github.com/rawstudio/rawstudio/blob/master/plugins/meta-tiff/tiff-meta.c#L1396 The memory is directly mapped to [IFD](https://github.com/rawstudio/rawstudio/blob/master/plugins/meta-tiff/tiff-meta.c#L43) You would need to byte swap gushort/guint/gint values on BE.

@barracuda156 I am just the messenger. I have no intention of fixing this.

This does not use unsafe and the only assembler would be in the stdlib. Imports here: https://godoc.org/github.com/klauspost/compress/flate?imports "sync" is only used for a sync.Once and there are no goroutines, so...

I don't have access to the servers, so I cannot tell you. It is running on https://fuzzit.dev/ - https://twitter.com/fuzzitdev

As Keith Randall noted on the original issue #20846 > This looks like the stack has been trashed somehow. > Not only the return address for gopark. gopark's arguments also...

@futurist I am not sure if this is related. My best bet would be there is a problem with the `sync.Pool` reuse mechanics causing a race. Unfortunately the project seems...

@futurist It is not a problem in the compression package. The stack looks messed up. It looks like either a problem in the package you are using or a runtime...

`Threads Per Core` is not going to be accurate. But it does seem like there is something fishy with the latest Intels: ``` === RUN TestMocks/GenuineIntel00B06A2_RaptorLakeP_04_CPUID.txt mockcpu_test.go:180: Opening GenuineIntel00B06A2_RaptorLakeP_04_CPUID.txt mockcpu_test.go:183:...