luvit / luv

Bare libuv bindings for lua

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

request bind v1.45.0 new features

zhaozg opened this issue · comments

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

Opps, I made a PR, #649.

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.

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.

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

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.

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.

Ok, We do double check.

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.

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,

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

Sure, I will make an issue in a bit.

EDIT: libuv/libuv#4008