[LuaFAR] file:rawhandle()

Здесь можно сообщить о найденных багах в Far.
Post Reply
Shmuel
Posts: 5524
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 21 times
Been thanked: 179 times

[LuaFAR] file:rawhandle()

Post by Shmuel » Mon 20 Aug, 2018 21:31

Столкнулся с падениями Фар x64 при использовании file:rawhandle() в FFI-скрипте. На x86 работает.
Собственно этот метод передаёт в скрипт FILE* в виде light userdata. Ясно, что на x64 это будет 64-битный указатель.
Поскольку реализация метода в LuaFAR совершенно прямолинейная, то непонятно, как такая проблема может возникнуть.

Дальше - больше. Оказывается в GCC-сборке LuaFAR этой проблемы нет, и всё работает.
Далее: использование far.Show() для просмотра этого указателя даёт 8 16-ричных цифр для ночной сборки и 12 цифр для сборки GCC.
В аналогичном опыте, в ночной сборке 4450 x64 показывается 12 16-ричных цифр, а в ночных сборках 4545 и далее - 8 (промежуточных билдов у меня нет).

Нужна помощь знатоков. Обсуждать можно либо здесь, либо на Мантисе.
Last edited by Shmuel on Mon 20 Aug, 2018 21:32, edited 1 time in total.

User avatar
DrKnS
Posts: 4914
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 4 times
Been thanked: 161 times

[LuaFAR] file:rawhandle()

Post by DrKnS » Mon 20 Aug, 2018 23:21

Падает в extern "C" int __cdecl _close(int const fh) (C:\Program Files (x86)\Windows Kits\10\Source\10.0.16299.0\ucrt\lowio\close.cpp) на _VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) & FOPEN), EBADF, -1);

Насколько я понимаю, rawhandle() вытаскивает FILE* из luaL_checkudata и потом static int io_fclose(lua_State *L) (FarManager\plugins\luamacro\luafar\uliolib51.c) пытается этот файл закрыть.

luaL_checkudata реализован внутри lua51.dll, io_fclose - внутри luafar3.dll.

"A modification of Standard I/O (and system) library giving it capability of working with Unicode paths." - это круто, но закрывать надо там, где открывали - у них же разные C-рантаймы и разные FILE*, поэтому произойти при таком закрытии может что угодно, включая отправку почтой порномультиков начальнику.

Shmuel
Posts: 5524
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 21 times
Been thanked: 179 times

[LuaFAR] file:rawhandle()

Post by Shmuel » Tue 21 Aug, 2018 07:51

DrKnS, твой анализ не очень соответствует действительности (я бы мог по пунктам это показать).
Но главное ты ухватил - причина в использовании разных рантаймов. И за это большое спасибо.
  • Падает оно на fread().
  • Функция _wfopen берётся из (собранной статически с рантаймом Visual C (2015 ?)) luafar3.dll, соответственно там же создаётся структура FILE.
  • Функция fread берётся из msvcrt.dll, в которой структура FILE определена не идентично рантайму, используемому в _wfopen.
Решение напрашивается такое: линковать luafar3.dll динамически с msvcrt.dll. Но мне смутно помнится, что с этим были какие-то трудности.

User avatar
DrKnS
Posts: 4914
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 4 times
Been thanked: 161 times

[LuaFAR] file:rawhandle()

Post by DrKnS » Tue 21 Aug, 2018 07:58

Shmuel wrote:
Tue 21 Aug, 2018 07:51
анализ не очень соответствует действительности
Что вижу, о том и пою:
2018-08-21_07-55-59.png

Shmuel
Posts: 5524
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 21 times
Been thanked: 179 times

[LuaFAR] file:rawhandle()

Post by Shmuel » Tue 21 Aug, 2018 08:08

DrKnS wrote:
Tue 21 Aug, 2018 07:58
Что вижу, о том и пою:
Предлагаю не отвлекаться на несущественное (если очень хочется - можно через e-mail), а сосредоточиться на решении проблемы.
Есть ли трудности/противопоказания в отношении динамической сборки luafar3.dll ?

User avatar
DrKnS
Posts: 4914
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 4 times
Been thanked: 161 times

[LuaFAR] file:rawhandle()

Post by DrKnS » Tue 21 Aug, 2018 09:32

Shmuel wrote:
Tue 21 Aug, 2018 08:08
Есть ли трудности
Майкрософтовские компиляторы/линкеры не используют msvcrt.dll.

Shmuel
Posts: 5524
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 21 times
Been thanked: 179 times

[LuaFAR] file:rawhandle()

Post by Shmuel » Tue 21 Aug, 2018 10:23

Ага, теперь вспомнил старое обсуждение (5-летней давности, наверное).
Я предлагал тогда поставить GCC на сервер, но согласия не получил. Может быть сейчас можно?

User avatar
John Doe
Бюрократ
Posts: 11848
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 26 times
Been thanked: 130 times

[LuaFAR] file:rawhandle()

Post by John Doe » Tue 21 Aug, 2018 10:28

Shmuel wrote:
Tue 21 Aug, 2018 07:51
Решение напрашивается такое: линковать luafar3.dll динамически с msvcrt.dll. Но мне смутно помнится, что с этим были какие-то трудности.
Ссылки по теме:
https://social.msdn.microsoft.com/Forum ... =vcgeneral
https://blogs.msdn.microsoft.com/oldnew ... 00/?p=1273
Last edited by John Doe on Tue 21 Aug, 2018 10:31, edited 1 time in total.

User avatar
DrKnS
Posts: 4914
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 4 times
Been thanked: 161 times

[LuaFAR] file:rawhandle()

Post by DrKnS » Tue 21 Aug, 2018 10:33

Shmuel wrote:
Tue 21 Aug, 2018 10:23
Может быть сейчас можно?
Не жонглировать несовместимыми объектами между модулями не вариант?

Shmuel
Posts: 5524
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 21 times
Been thanked: 179 times

[LuaFAR] file:rawhandle()

Post by Shmuel » Tue 21 Aug, 2018 10:40

John Doe, спасибо, читал уже, в курсе.

DrKnS, проще всего сказать "не делай так". Но хочется, чтобы делать так было можно, то есть, сделать объекты совместимыми.
Last edited by Shmuel on Tue 21 Aug, 2018 10:41, edited 1 time in total.

User avatar
DrKnS
Posts: 4914
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 4 times
Been thanked: 161 times

[LuaFAR] file:rawhandle()

Post by DrKnS » Tue 21 Aug, 2018 11:02

Shmuel wrote:
Tue 21 Aug, 2018 10:40
сделать объекты совместимыми
Я разве против?
Но совместимыми они гарантированно будут только если низкоуровнево с ними работать только в одном модуле, т.е. остальным предоставлять свой opaque handle и все функции для работы с ним - luafar_fopen, luafar_fread, luafar_fwrite, luafar_fclose etc.
Да, возможно, это не так удобно и много работы.
Но собирать один модуль другим компилятором только потому что мы не смогли в ABI - это явный цирк.
Если по каким-либо причинам адекватно сделать нельзя - лучше уже тогда самим lua51.dll собирать.

Shmuel
Posts: 5524
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 21 times
Been thanked: 179 times

[LuaFAR] file:rawhandle()

Post by Shmuel » Tue 21 Aug, 2018 11:25

DrKnS wrote:
Tue 21 Aug, 2018 11:02
Но совместимыми они гарантированно будут только если низкоуровнево с ними работать только в одном модуле
Практика за много лет показывает, что разные модули, использующие один и тот же рантайм, вполне совмещаются друг с другом.
DrKnS wrote:
Tue 21 Aug, 2018 11:02
Но собирать один модуль другим компилятором только потому что мы не смогли в ABI - это явный цирк.
Я как бы не настаиваю, хотя ценность установки "всё делать одним компилятором" для меня не выглядит непререкаемой.
DrKnS wrote:
Tue 21 Aug, 2018 11:02
Если по каким-либо причинам адекватно сделать нельзя - лучше уже тогда самим lua51.dll собирать.
Это не решит проблему. Не уверен, что статически слинкованная lua51.dll каким-то образом будет экспортировать функции рантайма.

Ну и кроме того, использование Lua в Far большинством пользователей замыкается на возможности "из коробки". В то время как существенная часть возможностей Lua - в сторонних модулях, с которыми при статической линковке lua51.dll будет ещё больше проблем.

User avatar
John Doe
Бюрократ
Posts: 11848
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 26 times
Been thanked: 130 times

[LuaFAR] file:rawhandle()

Post by John Doe » Tue 21 Aug, 2018 11:48

Shmuel wrote:
Mon 20 Aug, 2018 21:31
Столкнулся с падениями Фар x64 при использовании file:rawhandle() в FFI-скрипте.
luajit (без luafar) тоже падает в подобной ситуации?

Shmuel
Posts: 5524
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 21 times
Been thanked: 179 times

[LuaFAR] file:rawhandle()

Post by Shmuel » Tue 21 Aug, 2018 11:59

John Doe wrote:
Tue 21 Aug, 2018 11:48
luajit (без luafar) тоже падает в подобной ситуации?
Нет.

Пробема с rawhandle вызвана тем, что функции открытия/закрытия файла находятся в luafar3.dll, а функции "сырых" чтения/записи (то-есть fread/fwrite) - в msvcrt.dll. У этих dll разное представление структуры FILE (и, наверное, каких-то других структур тоже).

User avatar
HaRT
Moderator
Posts: 8470
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 74 times
Been thanked: 135 times

[LuaFAR] file:rawhandle()

Post by HaRT » Tue 21 Aug, 2018 12:08

Shmuel wrote:
Tue 21 Aug, 2018 11:59
разное представление структуры FILE
Дело же не только в разном представлении, но и в том, что у них отдельные структуры данных. Хэндлы, действительные в одной, недействительны в другой, но их там могут пытаться применять.
Фар есть инструмент, а не нянька. © 2009 DrKnS

Shmuel
Posts: 5524
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 21 times
Been thanked: 179 times

[LuaFAR] file:rawhandle()

Post by Shmuel » Tue 21 Aug, 2018 12:19

OK, надеюсь HaRT извинит меня, что не буду комментировать его послание, но где-то надо останавливаться. Данная тема создана не для общего обсуждения, а вполне себе даже конкретного. Поэтому, если конкретных предложений нет, значит всё останется на своих местах.

В конце концов на rawhandle свет клином не сошёлся.
Те, кто хотят получить полную совместимость в FFI, могут сами собирать luafar3.dll с помощью GCC.
Я бы мог собирать и выкладывать, но времени на это нет (а на то, чтобы сделать это автоматически, знаний чуть не хватает).

Post Reply

Return to “Глюки и баги”