View Issue Details

IDProjectCategoryView StatusLast Update
0002609WishesMacropublic2014-11-20 06:50
ReporterJohnDoe Assigned Toshmuel  
PrioritynormalSeverityminorReproducibilityN/A
Status closedResolutionfixed 
Product Version3.0 
Summary0002609: LuaFAR: защита от ошибок в far.SaveScreen/RestoreScreen
DescriptionЕсли после far.SaveScreen не вызвать far.RestoreScreen с соответствующим хэндлом, то память выделенная SaveScreen никогда не освободится.
Это нормально для C, и описывается в Энциклопедии. Но в luafar можно было бы предусмотреть метод сбора мусора.

Если ошибочно вызвать RestoreScreen с одним и тем же хэндлом повторно, то фар улетает.
В C это ожидаемо, но в luafar можно было бы учитывать такую вероятность.
TagsNo tags attached.
BuildLMb450

Activities

shmuel

2014-11-19 08:39

developer   bugnote:0013249

> Если после far.SaveScreen не вызвать far.RestoreScreen с соответствующим
> хэндлом, то память выделенная SaveScreen никогда не освободится.
> Это нормально для C, и описывается в Энциклопедии. Но в luafar можно было
> бы предусмотреть метод сбора мусора.

Поскольку RestoreScreen() перерисовывает экран, используя сохранённый образ экрана, то, учитывая, что момент сбора мусора недетерминирован, это, наверное, нежелательно?

> Если ошибочно вызвать RestoreScreen с одним и тем же хэндлом повторно,
> то фар улетает.
> В C это ожидаемо, но в luafar можно было бы учитывать такую вероятность.

Это можно поправить.

JohnDoe

2014-11-19 10:19

updater   bugnote:0013250

>Поскольку RestoreScreen() перерисовывает экран, используя сохранённый образ экрана, то, учитывая, что момент сбора мусора недетерминирован, это, наверное, нежелательно?

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

Можно обойти последующей принудительной перерисовкой.
И наверно есть смысл делать это не молча, а с ворнингом.

shmuel

2014-11-19 10:47

developer   bugnote:0013251

> Можно обойти последующей принудительной перерисовкой.
> И наверно есть смысл делать это не молча, а с ворнингом.

Поскольку вся эта деятельность будет производиться в недетерминированный момент времени (например, через несколько часов, если пользователь в эти часы не пользовался данным LuaFAR-плагином) и в недетерминированной ситуации, то неосвобождение памяти мне представляется меньшим злом.

Вот если бы Фар давал возможность освободить эту память, не перерисовывая экран, тогда это было бы вполне оправдано.

JohnDoe

2014-11-19 11:01

updater   bugnote:0013252

>Вот если бы Фар давал возможность освободить эту память, не перерисовывая экран,
Мне кажется что если бы LuaFAR мог бы выдать сообщение об ошибке (с указанием источника), то это позволило бы задушить баг в зародыше.

Т.е. мусор можно не собирать, а только сигнализировать о нём.

shmuel

2014-11-19 11:11

developer   bugnote:0013253

Last edited: 2014-11-19 11:24

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

В общем, я останавливаюсь на исполнении только второй части данного тикета (предотвращение попытки повторного освобождения памяти).

Кроме того (о чём в тикете не сказано) будет производиться проверка и защита от передачи userdata неправильного типа в качестве аргумента far.Restore.

shmuel

2014-11-19 11:21

developer   bugnote:0013254

LuaFAR build 450.

JohnDoe

2014-11-19 11:22

updater   bugnote:0013255

>Плагин может в этот момент заниматься совсем другой задачей
Ихмо.
Ситуация с неосвобождаемой памятью - это не штатная ситуация, поэтому так ли важно, чем в это время занимается плагин?
Зато ошибка будет сразу же обнаружена и исправлена автором.


>В общем, я останавливаюсь на исполнении только второй части данного тикета
Ок.

JohnDoe

2014-11-19 11:32

updater   bugnote:0013256

>LuaFAR build 450.
Проверить результат сейчас сложно, т.к. в настоящий момент никаких ошибок/вылетов тоже не происходит:

lua:local h=far.SaveScreen(); far.RestoreScreen(h); far.RestoreScreen(h)

shmuel

2014-11-19 11:39

developer   bugnote:0013257

> Ситуация с неосвобождаемой памятью - это не штатная ситуация,
> поэтому так ли важно, чем в это время занимается плагин?
> Зато ошибка будет сразу же обнаружена и исправлена автором.

LuaFAR - это библиотека. Как библиотека, она просто не имеет права "интрузивно" вмешиваться в работу аппликации во время того, как Lua собирает мусор.

Проблема в данном случае лежит в API RestoreScreen, эта функция объединяет 2 действия в одном, не предоставляя возможности их разделить. Вполне можно допустить ситуацию, когда уже после вызова SaveScreen плагин решит, что по логике текущей ситуации он не должен восстанавливать экран. Но это не предусмотрено.

> Проверить результат сейчас сложно, т.к. в настоящий момент никаких
> ошибок/вылетов тоже не происходит

Да, я знаю, об этом уже есть в форуме.

JohnDoe

2014-11-19 12:05

updater   bugnote:0013258

>Как библиотека, она просто не имеет права "интрузивно" вмешиваться в работу аппликации во время того, как Lua собирает мусор.
Да, в фаре давно напрашивается какой-нибудь лог...

Issue History

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