Интересный сбой возникающий видимо из-за повреждений БД конфигов Far
- по крайней мере после удаления БД кэша на какой-то период времени испаряется. Обычно происходит ошибка в LuaMacro::OpenW() после которой удаётся прочитать стек (скриншоты в reports.7z), но в x86 (PID=8464) похожая ошибка с AV возникла на выходе по F10. Сообщение отладчика -
Необработанное исключение по адресу 0x673C4679 (sortstr-x32.dll) в Far.exe: 0xC0000005: нарушение прав доступа при чтении по адресу 0x00000000.. И что интересно так это то что ошибка явно плавающая:
1) возникает хаотично, обычно после обновления билда;
2) событие может совпадать с рефакторингом (чаще) или изменениями в LuaMacro (редко);
3) после удаления БД кэша обычно пропадает;
4) одно из условий воспроизведения выполнение последовательности операций:
а) запуск тестовой копии в ассоциациях которой указано
<filetype mask="*.lua" description="Lua script">
<command type="0" enabled="1" command="lua:@"!=\!.!""/>
</filetype>
<filetype mask="*.moon" description="Moonscrip">
<command type="0" enabled="1" command="lua:@"!=\!.!""/> для учёта возможного наличия пробелов в пути к файлу;
б) переход в каталог ./Far30/scripts/ где лежат тестовые скрипты LuaMacro;
в) последовательный запуск скриптов:
hello.lua
test.lua
test.7z
test.rar
test1.lua
test2.lua
test3.lua
test4.lua hello.lua всегда отрабатывает без ошибок, test.lua может отрабатывать чуть по разному - если на моей машине типичное время его срабатывания ~ 96 - 98 mS, то перед боем он отработает за ~ 81 - 83 mS - т.е. признаком того, что ожидается ошибка в LuaMacro::OpenW() является примерно 10% снижение необходимого для его отработки времени, а после достаточно открыть в ArcLite test.7z и запустить оттуда test.lua получаем AV (Access Violation) в LuaMacro с одинаковым стеком и отладочной выдачей:
->
->
при этом если после AV перезапустить ту же копию и повторить операции обычно повторных AV не возникает, что позволяет предположить плавающий характер явления.
Если бы явление было одноразовым то можно было предположить его возможную как причину ВЧ-помеху по цепям питания прошедшую через каскад сетевых фильтров или случайную наводку на плату, но оно воспроизводится эпизодически, а значит причина его возникновения вызывает интерес...
Добавлено: О!, а дампы и прочее случайно забыл -
reports.7z...