Горячая замена кода

[vlad]

Какие еще уязвимости? O_o

http://en.wikipedia.org/wiki/Dangling_pointer#Security_holes_involving_dangling_pointers

[ilovb]

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

Если мы вдруг желаем заменять реализацию в процессе разработки (перекомпилируем и выгружаем модули), то достаточно в секции CLOSE добавить вызов метода SetDir(StdDir).

[vlad]

Какие еще уязвимости? O_o

Грубо говоря - в 99.9% случаев ты получишь трап. Потому что адрес находится вне адресного пространства процесса или мусор лежащий по этому адресу будет квалифицирован как invalid processor instruction. А в оставшемся 0.1% ты получишь "странное" поведение. А если хакеры постараются - то и security hole.

Для сравнения - в случае NIL указателя ты в 100% получишь трап.

[valexey_u]

Какие еще уязвимости? O_o

Грубо говоря - в 99.9% случаев ты получишь трап. Потому что адрес находится вне адресного пространства процесса или мусор лежащий по этому адресу будет квалифицирован как invalid processor instruction. А в оставшемся 0.1% ты получишь "странное" поведение. А если хакеры постараются - то и security hole.

Для сравнения - в случае NIL указателя ты в 100% получишь трап.

Эмм.. Совсем не факт что эта дыра в ББ есть. Нужно смотреть в детали реализации.

[ilovb]

vlad: Ты думаешь что в ББ это именно так работает?

[vlad]

Если мы вдруг желаем заменять реализацию в процессе разработки (перекомпилируем и выгружаем модули), то достаточно в секции CLOSE добавить вызов метода SetDir(StdDir).

Еще раз. Я не желаю ничего там заменять. Я желаю разрабатывать свою программу, которой нафиг не сдалась динамическая я загрузка, потому что она грузится один раз и летит на Марс. Но ББ заставляет меня выгружать/загружать модули как часть процесса разработки. Пример показывает, что при этом могут возникать проблемы.

[ilovb]

Я не желаю ничего там заменять

Так с этого и надо было начинать.

"Но ББ заставляет "
Заставляет? Вот ведь скотина! Лучше б "разрешил" завершить прогу, пересобрать и снова запустить.

А что собсна мешает работать в православном стиле с++? O_o

[vlad]

vlad: Ты думаешь что в ББ это именно так работает?

Если бы это работало по другому, то трап был бы более информативным.

[valexey_u]

Вообще, теоретически, в ББ МОЖНО сделать на уровне фреймворка горячую замену кода. Действительно можно. Нужно добавить "команду" Update (unload & load), которая будет выполняться атомарно (благо многозадачности в ББ нет, так что и с этим проблем нет). В процессе такого update выполняем:
1) выгрузку старой версии модуля.
2) поиск всех оставшихся объектов в памяти за которые ответственен данный модуль
3) загрузка новой версии модуля
4) передача всех найденных объектов специальной функции конвертации новой версии модуля (в том числе указателей на функции!) в качестве VAR-параметров. Пусть конвертирует да меняет.

Все четыре пункта должны идти непрерывно и атомарно (то есть message loop не крутится).

[ilovb]

Пример показывает, что при этом могут возникать проблемы.

Пример не показывает абсолютно ничего кроме радиуса...

[ilovb]

Если бы это работало по другому, то трап был бы более информативным.

Этот трап не более и не менее информативный чем любой другой трап в ББ.
Номер ошибки есть. Дамп есть. Где сработал трап показано. Что еще надо?

[vlad]

Я не желаю ничего там заменять

Так с этого и надо было начинать.

Сознаюсь, я отклонился от темы, но я обозначил интересующий меня аспект еще вот здесь: http://oberspace.dyndns.org/index.php/topic,598.msg20104.html#msg20104:

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

"Но ББ заставляет "
Заставляет? Вот ведь скотина! Лучше б "разрешил" завершить прогу, пересобрать и снова запустить.

Претензий к "заставляет" не было. Он так работает - пожалуйста. Причем такой подход рекламируется и имеет определенные преимущества. А мы тут как раз степень фатальности недостатков такого подхода обсуждаем

[ilovb]

2) поиск всех оставшихся объектов в памяти за которые ответственен данный модуль

Если реализация устанавливается только в экспортные переменные, то сделать контроль раз плюнуть. Kernel позволяет перебрать экспортные переменные модуля.
А вот если объекты не в глобальных переменных... то это нужно что-то вроде сборщика мусора только для модулей.

[vlad]

Этот трап не более и не менее информативный чем любой другой трап в ББ.
Номер ошибки есть. Дамп есть. Где сработал трап показано. Что еще надо?

"Метод объекта принадлежит такому-то модулю выгруженному в такое-то время"?

P.S. Номер ошибки - это вообще прошлый век. Ценен только как дополнение к нормальной диагностике, для статистики и т.п. локализаций.

[vlad]

Дамп есть. Где сработал трап показано. Что еще надо?

Кстати, место где сработало полезно только в сравнении с вообще ничем. Потому что само место будет вполне валидным - вызов метода не-NIL объекта.