-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux test-dns resolveTxt failure #1148
Comments
Something weird is going on here:
I'm not sure I have the knowledge necessary for debugging this one properly. A quick fix would be to change the domain that it looks up the TXT records for. |
For me, I am getting the following when building Luvit on Linux: Uncaught Error: /mnt/bilal/home/Desktop/luvit/deps/dns.lua:690: attempt to perform arithmetic on local 'len_lo' (a nil value)
stack traceback:
/mnt/bilal/home/Desktop/luvit/deps/dns.lua:690: in function 'handler'
/mnt/bilal/home/Desktop/luvit/deps/core.lua:248: in function 'emit'
...bilal/home/Desktop/luvit/deps/stream/stream_readable.lua:172: in function 'push'
/mnt/bilal/home/Desktop/luvit/deps/net.lua:123: in function </mnt/bilal/home/Desktop/luvit/deps/net.lua:117>
[builtin#37]: at 0x004e1840
/mnt/bilal/home/Desktop/luvit/init.lua:49: in function </mnt/bilal/home/Desktop/luvit/init.lua:47>
[C]: in function 'xpcall'
/mnt/bilal/home/Desktop/luvit/init.lua:47: in function 'fn'
[string "bundle:deps/require.lua"]:310: in function <[string "bundle:deps/require.lua"]:266>
make: *** [Makefile:12: test] Error 255 I have traced a tiny bit of this, and found that (line 114 from net): function Socket:_read(n)
local onRead
function onRead(err, data)
timer.active(self)
if err then
return self:destroy(err)
elseif data then
p(3, n, data) -- data = '\000'
self:push(data)
else
self:push(nil)
self:emit('_socketEnd')
end
end We notice here that the data getting passed is function onData(msg)
local len_hi, len_lo, len, answers
len_hi = byte(msg, 1)
len_lo = byte(msg, 2)
len = lshift(len_hi, 8) + len_lo -- len_lo == nil Since uv.read_start(self._handle, onRead) so I am not entirely sure why this single test is the one getting this kind of data. |
I've also confirmed:
makes it somehow work just fine without getting this kind of weird chunk. |
I have just noticed that it doesn't have to be a different domain, just changing it to Good to mention, requesting Update: I've changed all tests to use /mnt/bilal/home/Desktop/luvit/tests/libs/tap.lua:81: /mnt/bilal/home/Desktop/luvit/tests/test-dns.lua:98: assertion failed!
stack traceback:
[C]: in function 'error'
/mnt/bilal/home/Desktop/luvit/tests/libs/tap.lua:81: in function </mnt/bilal/home/Desktop/luvit/tests/libs/tap.lua:64>
[C]: in function 'xpcall'
/mnt/bilal/home/Desktop/luvit/tests/libs/tap.lua:64: in function 'run'
/mnt/bilal/home/Desktop/luvit/tests/libs/tap.lua:165: in function 'tap'
/mnt/bilal/home/Desktop/luvit/tests/run.lua:42: in function 'fn'
[string "bundle:deps/require.lua"]:310: in function 'require'
/mnt/bilal/home/Desktop/luvit/main.lua:128: in function </mnt/bilal/home/Desktop/luvit/main.lua:20> ... oh lol. Rest of the tests seems fine with it now, including Update 2: Changing the tests that uses Update 3: With some help from Nameless, we found that the failing request (
when a successful one (
|
@squeek502 you think we can use that as a workaround for now? or we should totally figure out the weirdness happening here first? or maybe just changing that |
Ok, so the servers being used are essentially global, so each test affects the next. In its current place:
When moved to the bottom:
The servers get set to So, one quick fix would be to just call EDIT: In the meantime, #1149 |
Still not totally sure why this test was failing, but this should fix it until we understand more about it. See luvit#1148
Sounds good, will test if this works on my machine now |
oh sorry, that looks like my bad. I just refetched the test file and it successfully passed all tests. |
Some more weirdness:
|
This might be due to Google not handling DNS of type TXT well enough:
I suggest we could change Google to something else everywhere in the tests maybe? |
I think it's fine to work around whatever weirdness they are doing on the main domain. It could be easily a custom dns server that responds differently depending on any number of factors (time of day, geo location, version of client, etc) at their scale. |
Still not totally sure why this test was failing, but this should fix it until we understand more about it. See luvit#1148
I was getting this locally and now it's happening on the CI too:
EDIT: Locally the error I'm getting is
Maximum attempts reached
The text was updated successfully, but these errors were encountered: