Intermittent CI failure: assertion tripped when run under Valgrind

[squeek502]

Split from #721

---

This assertion was tripped in a CI run of our tests here: https://github.com/luvit/luv/actions/runs/11649845591/job/32437850489

ok 126 thread - getaffinity, setaffinity
default priority	0
hello world from thread
priority in thread	0
lua: /home/runner/work/luv/luv/src/loop.c:98: luv_walk_cb: Assertion `data && data->ref < 0x1000000' failed.

It occurred during the "getpriority, setpriority" test, and a re-run fixed it so it is an intermittent failure.

Our own tests tripping this assertion seems like bad news.

---

Same failure here and (presumably, logs have been cleared) here

Not sure why it's only getting tripped when run under Valgrind.

[squeek502]

Different but presuambly related failure here: https://github.com/luvit/luv/actions/runs/12801148295/job/35690138656?pr=746

default priority	0
hello world from thread
priority in thread	0
  ./tests/test-thread.lua:180: Unknown system error -115: Unknown system error -115
  stack traceback:
  	[C]: in function 'assert'
  	./tests/test-thread.lua:180: in field 'fn'
  	./lib/tap.lua:59: in function <./lib/tap.lua:48>
  	[C]: in function 'xpcall'
  	./lib/tap.lua:48: in upvalue 'run'
  	./lib/tap.lua:146: in function 'lib/tap'
  	tests/run.lua:23: in main chunk
  	[C]: in ?
not ok 129 thread - getpriority, setpriority

This seems suspiciously like stack corruption/use-after-free/race condition or something like that. Impossible error codes, impossible data->ref values, etc.

[squeek502]

Something else that's strange about this is the hello world from thread output. That's the output from a completely different test (test avoid thread be released before it done), so I have no idea why it's showing up here.

The expected output for the getpriority, setpriority test is

default priority        0
priority after change   0
priority in thread      0
ok 9 getpriority, setpriority

[truemedian]

To add to the above wrt impossible error codes: It's because libuv returns the wrong thing for errors. It's returning UV__ERR(errno) despite the fact that pthread functions do not return error information in errno. It should be returning UV__ERR(retval).

A result of errno -115 tells us nothing more than one of the pthread functions failed, we will not know why or which until libuv starts providing the correct error information.