These are WIP notes, just to have a thing to link to:
As a part of a larger problem where I see go test -count=1000 . hanging, I have noticed, on macOS
% go test -count=10000 -run TestData_callback_reading
--- FAIL: TestData_callback_reading (0.00s)
data_test.go:135: interrupted system call
--- FAIL: TestData_callback_reading (0.00s)
data_test.go:135: interrupted system call
--- FAIL: TestData_callback_reading (0.00s)
data_test.go:135: operation timed out
FAILIt doesn’t always fail but it does fail fairly frequently.
The immediate cause seems to be that the err != nil (errno != 0) check happens before checking n >= 0; the errno value has unspecified contents in that case.
That should be easy to fix…
… but:
Looking at the implementation, this is a Go call intermediating through GPGME and gogpgme_readfunc to another Go call — and that uses gpgme_err_set_errno (essentially an assignment to errno) to return an error state. I don’t see that there is any guarantee that the goroutine running gogpgme_readfunc will not be moved to another thread between the assignment and the return.
These are WIP notes, just to have a thing to link to:
As a part of a larger problem where I see
go test -count=1000 .hanging, I have noticed, on macOSIt doesn’t always fail but it does fail fairly frequently.
The immediate cause seems to be that the
err != nil(errno != 0) check happens before checkingn >= 0; theerrnovalue has unspecified contents in that case.That should be easy to fix…
… but:
Looking at the implementation, this is a Go call intermediating through GPGME and
gogpgme_readfuncto another Go call — and that usesgpgme_err_set_errno(essentially an assignment toerrno) to return an error state. I don’t see that there is any guarantee that the goroutine runninggogpgme_readfuncwill not be moved to another thread between the assignment and the return.