Luajit неочевидные особенности. Опции

[DarkMaster]

Тема будет оченя вялотекущая, тем не менее иногда сталкиваюсь с неожиданным поведением среды. Подобные заметки могут быть кому-то полезны, например, мне, склероз не дремлет.

Код

local kernel32 = ffi.load("kernel32")
local threadId = ffi.new("DWORD[1]")
    local threadHandle = kernel32.CreateThread(nil, 0, ffi.cast("THREAD_START_ROUTINE", async), ffi.cast("LPVOID", HintStruct), 0, threadId)

Вызов kernel32.CreateThread и C.CreateThread на самом деле не эквивалентен. В частности в этом случае вызов через C.CreateThread шансово приводит к крашу. Причины я не знаю, но факт на лицо. В качесте домыслов через C.CreateThread подтягивается функция принадлежащая самому lua, а не конкретной либе.



Zerobane отладка.

Код

while 1 do
    local a = false
    if  a then
        print("a == true")
    end
end

Очевидно, что цикл будет крутиться вечно, а условие if a then никогда не выполнится. Ставим brake, меняем через отладчик значение a = true. Условие if a then все равно не будет выполнятся. При том, что а действительно будет равна true. Дело в том, что jit создал bypass, т.к. посчитал, что a константа и никогда не будет изменена. Фактически он никогда и не проверял ее значение, а просто делал безусловный переход пропуская блок if end. В качестве решения можно использовать конструкцию:

Код

local f = function(new_var) end
do
    local var = false
    f = function(new_var)
        if new_var then
            var = new_var
        end
        return var
    end
end

while 1 do
    local a = f(false)
    if  a then
        print("a == true")
    end
end

Данная заглушка позволит выполнить отладку с минимальными вмешательствами в код.

Сообщение отредактировал DarkMaster - 8.6.2024, 9:29

[DarkMaster]

при создании lua массива с cdata данные могут биться. garbage collector не отслеживает должным образом ссылки на них. Лучше сразу приводить к луа данным, либо заранее заботиться о том, чтобы область видимости была глобальная/код никогда выходил за область с видимостью cdata пока эти данные нужны, а так же присутствовало формальное обращение к этим данным напрямую.

Код

    local enumMonitorCallback = function(hMonitor, hdcMonitor, lprcMonitor, dwData)
        monitors[#monitors+1] = lprcMonitor
        print("Monitor position:  ", lprcMonitor.left, lprcMonitor.top, lprcMonitor.right, lprcMonitor.top) 
        return true -- продолжаем перечисление
    end

Код

    local enumMonitorCallback = function(hMonitor, hdcMonitor, lprcMonitor, dwData)
        monitors[#monitors+1] = {left=lprcMonitor.left, top=lprcMonitor.top, right=lprcMonitor.right, bottom=lprcMonitor.bottom}
        print("Monitor position:  ", lprcMonitor.left, lprcMonitor.top, lprcMonitor.right, lprcMonitor.bottom) 
        return true -- продолжаем перечисление
    end

Оба примера кода выведут корректные данные, но первый вариант не гарантирует сохранность данных после выхода из функции в upvalue monitors (читай будут битыми).

Сообщение отредактировал DarkMaster - 25.6.2024, 10:28