luac.cross goes into an apparently infinite loop

[pjsg]

Expected behavior

luac.cross completes is a reasonable amount of time.

Actual behavior

It runs for a long time on one particular file.

Test code

-- tz

local M = {}

local tstart = 0
local tend = 0
local toffset = 0
local config = require "config"

function M.exists(zone)
  return file.exists(zone + ".zone")
end

function M.getzones()
  local result = {}
  for fn, _ in pairs(file.list()) do
    local _, _, prefix = string.find(fn, "(.*).zone")
    if prefix then
      table.insert(result, prefix)
    end
  end
  return result
end

function M.load(t)
  local z = file.open(config.tz .. ".zone", "r")

  local hdr = z:read(20)
  local magic = struct.unpack("c4 B", hdr)

  if magic == "TZif" then
      local lens = z:read(24)
      local ttisgmt_count, ttisdstcnt, leapcnt, timecnt, typecnt, charcnt = struct.unpack("> LLLLLL", lens)

      local times = z:read(4 * timecnt)
      local typeindex = z:read(timecnt)
      local ttinfos = z:read(6 * typecnt)

      z:close()

      local offset = 1
      local tt
      for i = 1, timecnt do
        tt = struct.unpack(">l", times, (i - 1) * 4 + 1)
        if t < tt then
          offset = (i - 2)
          tend = tt
          break
        end
        tstart = tt
      end

      local tindex = struct.unpack("B", typeindex, offset + 1)
      toffset = struct.unpack(">l", ttinfos, tindex * 6 + 1)
  else
      tend = 0x7fffffff
      tstart = 0
  end
end


function M.getoffset(t)
  if t < tstart or t >= tend then
    -- Ignore errors
    local ok, msg = pcall(function ()
        M.load(t)
    end)
    if not ok then
      print (msg)
    end
  end

  return toffset, tstart, tend
end

return M

NodeMCU version

dev branch

[TerryE]

Thanks. I'll call take a look.

[HHHartmann]

Just tried with currentish dev build and it compiles in reasonable time (like instantly)
Tried int and float.

[pjsg]

Hmm -- it still fails for me (I tried copying the sample that I had pasted above into a new file, just in case it was due to some invisible character). This is for a plain integer build from dev.

I just installed gdb and it appears to be looping in Align4.

(gdb) where
#0  0x000000000041367e in DumpChar (y=0, D=0x7fffffffe860) at ../ldump.c:43
#1  0x00000000004136e9 in Align4 (D=0x7fffffffe860) at ../ldump.c:51
#2  0x0000000000413e20 in DumpDebug (f=0x67f440, D=0x7fffffffe860) at ../ldump.c:235
#3  0x0000000000414076 in DumpFunction (f=0x67f440, p=0x67cda0, D=0x7fffffffe860) at ../ldump.c:275
#4  0x0000000000413daf in DumpConstants (f=0x67e040, D=0x7fffffffe860) at ../ldump.c:225
#5  0x0000000000414063 in DumpFunction (f=0x67e040, p=0x0, D=0x7fffffffe860) at ../ldump.c:274
#6  0x000000000041420a in luaU_dump_crosscompile (L=0x67c010, f=0x67e040, w=0x402837 <writer>, data=0x67cdd0, strip=0, target=...) at ../ldump.c:312
#7  0x0000000000402b87 in pmain (L=0x67c010) at luac.c:318
#8  0x0000000000412bc7 in luaD_precall (L=0x67c010, func=0x67c400, nresults=0) at ../ldo.c:336
#9  0x0000000000412ea2 in luaD_call (L=0x67c010, func=0x67c400, nResults=0) at ../ldo.c:395
#10 0x0000000000408813 in f_Ccall (L=0x67c010, ud=0x7fffffffebd0) at ../lapi.c:888
#11 0x0000000000411d0b in luaD_rawrunprotected (L=0x67c010, f=0x408728 <f_Ccall>, ud=0x7fffffffebd0) at ../ldo.c:119
#12 0x00000000004132e1 in luaD_pcall (L=0x67c010, func=0x408728 <f_Ccall>, u=0x7fffffffebd0, old_top=16, ef=0) at ../ldo.c:482
#13 0x000000000040887d in lua_cpcall (L=0x67c010, func=0x402886 <pmain>, ud=0x7fffffffec20) at ../lapi.c:898
#14 0x0000000000402cd0 in main (argc=1, argv=0x7fffffffed30) at luac.c:349
(gdb) print *D
$1 = {L = 0x67c010, writer = 0x402837 <writer>, data = 0x67cdd0, strip = 0, status = 101, target = {little_endian = 1, sizeof_int = 4, sizeof_strsize_t = 4, 
    sizeof_lua_Number = 4, lua_Number_integral = 1, is_arm_fpa = 0}, wrote = 1091}

It appears that the D->status is non zero, so DumpBlock can't dump anything, so Align4 never makes progress. Of course, I have no idea of why D->status is 101.

Other lua files compile instantly.

[TerryE]

Hi Philip, if you are in luaU_dump_crosscompile() then this is normal compile path and not the LFS code. I haven't changed this for years. if you go to app/lua/luac_cross and do a make FLAVOR=debug clean followed by make FLAVOR=debug, then the make will compile the debug version.

Like Gregor, this works fine for me both with and without -f. Can you replicate this with a standard master or dev build? Just let me know the commit that you are building to, and any changes to user_config.h. Thanks

[TerryE]

@pjsg can you please email me the exact lua file and commit ID so I can try and replicate your test case. Failing this, I will treat this issue as closed 😄

[TerryE]

OK, it's an eLua bug. The problem is the loop at ldump.c:50:51 and that DumpBlock() does not bump D->wrote once D->status is non-zero. so line 50 should read: while(D->wrote&3 && D->status==0) which will cause the compile to error with an integer overflow.

I haven't done the patch because I first want to check what we want to do here:

• 0x7FFFFFF is treated as an integer overflow even though the nodeMCU Lua VM handles it OK.
• Even though the compile now errors with "value too big or small for target integer type", it still outputs an invalid LC file.