View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002609 | Wishes | Macro | public | 2014-02-27 13:27 | 2014-11-20 06:50 |
Reporter | JohnDoe | Assigned To | shmuel | ||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | closed | Resolution | fixed | ||
Product Version | 3.0 | ||||
Summary | 0002609: LuaFAR: защита от ошибок в far.SaveScreen/RestoreScreen | ||||
Description | Если после far.SaveScreen не вызвать far.RestoreScreen с соответствующим хэндлом, то память выделенная SaveScreen никогда не освободится. Это нормально для C, и описывается в Энциклопедии. Но в luafar можно было бы предусмотреть метод сбора мусора. Если ошибочно вызвать RestoreScreen с одним и тем же хэндлом повторно, то фар улетает. В C это ожидаемо, но в luafar можно было бы учитывать такую вероятность. | ||||
Tags | No tags attached. | ||||
Build | LMb450 | ||||
|
> Если после far.SaveScreen не вызвать far.RestoreScreen с соответствующим > хэндлом, то память выделенная SaveScreen никогда не освободится. > Это нормально для C, и описывается в Энциклопедии. Но в luafar можно было > бы предусмотреть метод сбора мусора. Поскольку RestoreScreen() перерисовывает экран, используя сохранённый образ экрана, то, учитывая, что момент сбора мусора недетерминирован, это, наверное, нежелательно? > Если ошибочно вызвать RestoreScreen с одним и тем же хэндлом повторно, > то фар улетает. > В C это ожидаемо, но в luafar можно было бы учитывать такую вероятность. Это можно поправить. |
|
>Поскольку RestoreScreen() перерисовывает экран, используя сохранённый образ экрана, то, учитывая, что момент сбора мусора недетерминирован, это, наверное, нежелательно? Т.е. для сбора мусора будет вызываться RestoreScreen, что приведёт к неожиданному восстановлению неактуального образа экрана. Можно обойти последующей принудительной перерисовкой. И наверно есть смысл делать это не молча, а с ворнингом. |
|
> Можно обойти последующей принудительной перерисовкой. > И наверно есть смысл делать это не молча, а с ворнингом. Поскольку вся эта деятельность будет производиться в недетерминированный момент времени (например, через несколько часов, если пользователь в эти часы не пользовался данным LuaFAR-плагином) и в недетерминированной ситуации, то неосвобождение памяти мне представляется меньшим злом. Вот если бы Фар давал возможность освободить эту память, не перерисовывая экран, тогда это было бы вполне оправдано. |
|
>Вот если бы Фар давал возможность освободить эту память, не перерисовывая экран, Мне кажется что если бы LuaFAR мог бы выдать сообщение об ошибке (с указанием источника), то это позволило бы задушить баг в зародыше. Т.е. мусор можно не собирать, а только сигнализировать о нём. |
|
Даже "только сигнализация" при недетерминированных обстоятельствах мне представляется плохой идеей. Плагин может в этот момент заниматься совсем другой задачей, причём, возможно, совсем не предполагающей вывод модального диалога. В общем, я останавливаюсь на исполнении только второй части данного тикета (предотвращение попытки повторного освобождения памяти). Кроме того (о чём в тикете не сказано) будет производиться проверка и защита от передачи userdata неправильного типа в качестве аргумента far.Restore. |
|
LuaFAR build 450. |
|
>Плагин может в этот момент заниматься совсем другой задачей Ихмо. Ситуация с неосвобождаемой памятью - это не штатная ситуация, поэтому так ли важно, чем в это время занимается плагин? Зато ошибка будет сразу же обнаружена и исправлена автором. >В общем, я останавливаюсь на исполнении только второй части данного тикета Ок. |
|
>LuaFAR build 450. Проверить результат сейчас сложно, т.к. в настоящий момент никаких ошибок/вылетов тоже не происходит: lua:local h=far.SaveScreen(); far.RestoreScreen(h); far.RestoreScreen(h) |
|
> Ситуация с неосвобождаемой памятью - это не штатная ситуация, > поэтому так ли важно, чем в это время занимается плагин? > Зато ошибка будет сразу же обнаружена и исправлена автором. LuaFAR - это библиотека. Как библиотека, она просто не имеет права "интрузивно" вмешиваться в работу аппликации во время того, как Lua собирает мусор. Проблема в данном случае лежит в API RestoreScreen, эта функция объединяет 2 действия в одном, не предоставляя возможности их разделить. Вполне можно допустить ситуацию, когда уже после вызова SaveScreen плагин решит, что по логике текущей ситуации он не должен восстанавливать экран. Но это не предусмотрено. > Проверить результат сейчас сложно, т.к. в настоящий момент никаких > ошибок/вылетов тоже не происходит Да, я знаю, об этом уже есть в форуме. |
|
>Как библиотека, она просто не имеет права "интрузивно" вмешиваться в работу аппликации во время того, как Lua собирает мусор. Да, в фаре давно напрашивается какой-нибудь лог... |
Date Modified | Username | Field | Change |
---|---|---|---|
2014-02-27 13:27 | JohnDoe | New Issue | |
2014-11-19 08:39 | shmuel | Note Added: 0013249 | |
2014-11-19 10:19 | JohnDoe | Note Added: 0013250 | |
2014-11-19 10:47 | shmuel | Note Added: 0013251 | |
2014-11-19 11:01 | JohnDoe | Note Added: 0013252 | |
2014-11-19 11:11 | shmuel | Note Added: 0013253 | |
2014-11-19 11:21 | shmuel | Note Added: 0013254 | |
2014-11-19 11:21 | shmuel | Assigned To | => shmuel |
2014-11-19 11:21 | shmuel | Status | new => feedback |
2014-11-19 11:22 | JohnDoe | Note Added: 0013255 | |
2014-11-19 11:22 | JohnDoe | Status | feedback => assigned |
2014-11-19 11:24 | shmuel | Note Edited: 0013253 | |
2014-11-19 11:32 | JohnDoe | Note Added: 0013256 | |
2014-11-19 11:39 | shmuel | Note Added: 0013257 | |
2014-11-19 12:05 | JohnDoe | Note Added: 0013258 | |
2014-11-20 06:50 | shmuel | Build | => LMb450 |
2014-11-20 06:50 | shmuel | Status | assigned => closed |
2014-11-20 06:50 | shmuel | Resolution | open => fixed |