Some tests of 1.50.0 are failing on i586 and s390x

[cryptomilk]

I've packaged 1.50.0.0 for Fedora and one test fails on i586 on rawhide:

ok 112 thread - test thread sleep msecs in main thread
Uncaught Error in thread: thread:1: syntax error near '<\21>'
  { delay = 100, elapsed = 1 }
  ./tests/test-thread.lua:87: elapsed should be at least delay 
  stack traceback:
  	[C]: in function 'assert'
  	./tests/test-thread.lua:87: 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 113 thread - test thread create with options table

on s390x I see:

  ./tests/test-misc.lua:233: assertion failed!
  stack traceback:
  	[C]: in function 'assert'
  	./tests/test-misc.lua:233: in function 'fn'
  	./lib/tap.lua:59: in function <./lib/tap.lua:48>
  	[C]: in function 'xpcall'
  	./lib/tap.lua:48: in function 'run'
  	./lib/tap.lua:146: in function 'tap'
  	tests/run.lua:23: in main chunk
  	[C]: ?
not ok 79 misc - uv.wtf8 and utf16 conversion
  ./tests/test-misc.lua:246: assertion failed!
  stack traceback:
  	[C]: in function 'assert'
  	./tests/test-misc.lua:246: in function 'fn'
  	./lib/tap.lua:59: in function <./lib/tap.lua:48>
  	[C]: in function 'xpcall'
  	./lib/tap.lua:48: in function 'run'
  	./lib/tap.lua:146: in function 'tap'
  	tests/run.lua:23: in main chunk
  	[C]: ?
not ok 80 misc - uv.wtf8<->utf16 unpaired surrogate

https://koji.fedoraproject.org/koji/taskinfo?taskID=128366040

[Bilal2453]

The failure in luv.sleep is likely a regression in libuv 1.50, since that code haven't been touched on our side.

[squeek502]

Uncaught Error in thread: thread:1: syntax error near '<\21>'

This is a strange error. I'm unable to reproduce that particular error even when intentionally inserting a NAK control character into the thread function:

$ ./build/lua tests/test-thread.lua
./build/lua: tests/test-thread.lua:68: unexpected symbol near '<\21>'

EDIT: I think that error has to be coming from here:

luv/src/thread.c

Line 298 in 7aeed6f

fprintf(stderr, "Uncaught Error in thread: %s\n", lua_tostring(L, -1));

on s390x

Assuming this is an endianness issue, unsure if it's on our side or Libuv's; will check it out.

[squeek502]

The s390x failure should be addressed by #753

Would appreciate if you could double-check that it will fix it; I don't currently have a good way of running the tests while targeting a big-endian architecture.

[cryptomilk]

#753 fixes running the tests on s390x: https://koji.fedoraproject.org/koji/taskinfo?taskID=128411469

Thanks.

[cryptomilk]

About the issue on 32bit:

Uncaught Error in thread: thread:1: unexpected symbol near '<\4>'
  { elapsed = 0, delay = 100 }
  ./tests/test-thread.lua:87: elapsed should be at least delay 
not ok 113 thread - test thread create with options table

Any idea what that Uncaught error is?

[squeek502]

Any idea what that Uncaught error is?

No, but it's definitely the root cause, and the fact that it's a different control character this time (\4 now vs \21 in the OP) is not good news.

It's coming from here:

luv/src/thread.c

Line 298 in 7aeed6f

fprintf(stderr, "Uncaught Error in thread: %s\n", lua_tostring(L, -1));

Will likely need to reproduce it locally to understand what might be happening.

[cryptomilk]

My guess would be some memory overwrite. Building libuv with AddressSanitizer might catch it.

[clason]

Would appreciate if you could double-check that it will fix it; I don't currently have a good way of running the tests while targeting a big-endian architecture.

This might help:
https://github.com/neovim/neovim/blob/2470db02c5136525b8abce1ee0889d94f8d81d98/.github/workflows/optional.yml#L19-L48

(Running this with luv HEAD right now; seems to pass.)

My guess would be some memory overwrite. Building libuv with AddressSanitizer might catch it.

ASAN is indeed throwing a fit over the update, both on Linux and Windows. Haven't got any useful logs out of it, though:

• https://github.com/neovim/neovim/actions/runs/12945549440/job/36109345313?pr=32174
• https://github.com/neovim/neovim/actions/runs/12946739839/job/36111871325?pr=32174

(This is specific to the Luv bump; ASAN passed for the earlier libuv update itself.)

[clason]

ASAN failures seem to be fixed now (at least in Neovim tests).