luvit/luv

request bind v1.45.0 new features

zhaozg opened this issue · 13 comments

squeek502 commented

I'm working on this. Here's the full list of new stuff: https://docs.libuv.org/en/v1.x/search.html?q=1.45.0

zhaozg commented

Opps, I made a PR, #649.

  • 👍1
squeek502 commented

No worries, I am working on the bindings for uv_thread_cpuinfo, uv_thread_getaffinity, uv_thread_setaffinity, uv_get_available_memory, and uv_cpumask_size.

  • 👍1
squeek502 commented

I can't test it right now since I'm on Windows currently, but my first guess is that it's finding a regression in libuv.

zhaozg commented

Ok, I got ideas, some Mem error should be suppression. That's maybe come from lua 5.4.6.

squeek502 commented

Those errors don't look like something we should suppress. Conditional jump or move depends on uninitialised value(s) and Use of uninitialised value pretty much always means there is a bug somewhere.

  • 👍1
squeek502 commented

I'm getting the same valgrind errors in my branch that only updates Libuv, so this looks like either a bug on our end or a regression on Libuv's end.

zhaozg commented

Ok, We do double check.

squeek502 commented

My guess is that it's a regression in libuv. It wouldn't be the first time that our tests have found things that the libuv tests missed. I will investigate it soon.

zhaozg commented

My guess is that it's a regression in libuv. It wouldn't be the first time that our tests have found things that the libuv tests missed. I will investigate it soon.

I add --track-origins=yes for valgrind in https://github.com/luvit/luv/actions/runs/5031004869/jobs/9023801782, that report Uninitialised value value was created by a heap allocation in libuv side,
uv__iou_fs_statx call by uv_fs_stat, I can say https://github.com/libuv/libuv/blob/v1.x/src/unix/linux.c#L816
come from libuv/libuv#3952,

  • 👍1
zhaozg commented

Can you report this to libuv, I have unclear English communication ability. ☹

squeek502 commented

Sure, I will make an issue in a bit.

EDIT: libuv/libuv#4008