|
Notes |
|
|
(0013270)
|
|
zed
|
|
15-11-2013 16:49
|
|
|
|
|
|
Всего-то надо поменять базовый адрес и перекомпилировать. Хуже не будет.
|
|
|
|
(0013273)
|
|
zed
|
|
15-11-2013 18:28
|
|
|
Нужно же чтобы ещё и адресное пространство всех dll не пересекалось. Т.е. если просто задать адрес одной либе $20000000, а другой $20000004 толку всё равно не будет. |
|
|
|
|
|
Проще всего взять адреса на которые их сейчас преобразует система. |
|
|
|
(0013275)
|
|
zed
|
|
15-11-2013 18:47
|
|
|
Мне кажется, это будет зависеть от системы. Покажи скриншот со своими адресами? |
|
|
|
|
|
Будет, на других системах могут быть программы внедряем длл с совпадающими адресами и произойдет релокация, но сейчас то релокация точно происходит. |
|
|
|
|
|
Первый скриншот сделан на 64-битной винде, а второй на 32-битном нетбуке. |
|
|
|
|
|
Кстати, я не предлагаю менять сразу все dll, потому и разбил на кучу дочерних хотелок. Можно поштучно, постепенно подкладывая в ночнушки. |
|
|
|
(0013770)
|
|
zed
|
|
13-02-2014 11:57
|
|
Мне нужен список: dll - base adress, в котором будут перечислены все dll, которые может использовать SAS на текущий момент и базовые адреса, которые они должны использовать. Этот список (в виде текстового файла), я ожидаю в этом репозитории: https://bitbucket.org/sas_team/sas.lib.external
Как только будет такой список, я пересоберу нужные dll и закрою все связанные тикеты. Сам я составлять этот список не возьмусь. |
|
|
|
|
|
Тебе именно файлик нужен? Если я в конкретные тикеты повписываю? А то создание временного файлика в репозитории смотрится странно. |
|
|
|
(0013772)
|
|
zed
|
|
13-02-2014 12:33
|
|
|
Почему же временного? При последующих обновлениях либ мне же нужно будет не забыть прописывать правильные адреса. Так что файлик будет более чем постоянный. И на него нужно будет ориентироваться при добавлении новых dll. |
|
|
|
|
|
Давай я все-таки где-то здесь выложу файлик, а в репу закинешь его сам. А то когда я это смогу сделать, я не знаю. |
|
|
|
(0013776)
|
|
zed
|
|
13-02-2014 12:58
|
|
|
|
|
(0013778)
|
|
zed
|
|
13-02-2014 13:52
|
|
|
Кстати, обрати внимание. На твоём же скриншоте у leveldb и libpng прописаны как бы правильные ImageBase. Но на самом деле у них всё те же 0x10000000h. И вообще этот адрес у всех сишных либ, что я собирал, но монитор почему-то его не показывает и всё выглядит как-будто бы ОК. |
|
|
|
|
|
Ты меня озадачил. Единственная мысль которая приходит в голову, что дело в использовании ASLR в Windows 7, а оба скриншота делались на Windows 7 хоть и с разной битностью. Для leveldb и libpng включена поддержка ASLR. При этом система выполняет реаллокацию, вроде как, один раз для всех процессов. Так что учитывая, что XP уже пропадает, можно попробовать ограничиться включением ASLR для собранных нами библиотек. |
|
|
|
(0013780)
|
|
zed
|
|
13-02-2014 15:05
|
|
Похоже на правду. И насколько я вижу, в MSVC эта поддержка включена по-умолчанию, а в delphi нам нужно использовать специальную директиву, причём как в dll, так и в exe:
> The easiest way of enabling both ASLR and NX is to do this:
> Add '{$SETPEOPTFLAGS $140}' to the project source file (.dpr or .dpk)
ну и приглядывать за этим моментом, при добавлении новых либ. |
|
|
|
|
|
Точно. Дело именно в ASLR, если я запускаю вторую копию Планеты до закрытия первой то адреса leveldb и libpng в ней будут точно такие же как и в первой, а если после закрытия, то у leveldb и libpng уже получаются новые адреса. |
|
|
|
|
> ну и приглядывать за этим моментом, при добавлении новых либ.
А какие из проблемных либ у нас студией собираются? FreeImage.dll и все? |
|
|
|
(0013783)
|
|
zed
|
|
13-02-2014 15:12
|
|
|
Да. Там почему-то оказалось, что этот флаг снят. Надо будет посмотреть в настройки проекта. |
|
|
|
(0013784)
|
|
zed
|
13-02-2014 15:24
(edited on: 13-02-2014 15:25) |
|
ASLR решает проблему двойной загрузки dll в память, но при первой загрузке либы, у нас таки будет происходить реалокация адресов, о чём говорилось в статье, по мотивам которой и открыт тикет:
> Процесс загрузки по другому адресу долгий. Система пробегает по всему коду, и исправляет адреса на правильные, а таких адресов может быть десятки и сотни тысяч(!!!).
И возникает дилемма: с одной стороны современные технологии и ASLR, а с другой - быстродействие. Так что может имеет смысл наоборот, отключить эту фишку, если ты отдаёшь приоритет именно быстродействию?
Тот же zlib, который я сегодня обновил, не использует ASLR и у него уникальный image adress. Т.е. их выбор налицо.
|
|
|
|
|
http://blogs.msdn.com/b/mattev/archive/2007/08/21/enabling-aslr-for-memory-savings.aspx
Судя по этой заметке я таки правильно понял работу ASLR и она таки решение проблемы с минимумом работы. |
|
|
|
|
|
Почитай статейку, при использовании ASLR реаллокация происходит в ядре, а не в процессе и она общая для всех экземпляров использующих dll. Так что никакой диллемы. |
|
|
|
|
|
http://stackoverflow.com/questions/3617600/does-aslr-cause-a-slow-loading-of-dlls |
|
|
|
(0013788)
|
|
zed
|
|
13-02-2014 15:34
|
|
|
Ок, stackoverflow меня убедил. Значит переходим на ASLR где это возможно? |
|
|
|
|
|
Ну как по мне это логичный шаг. И вроде как проблем принести не должен. Кстати, а какие вообще могут быть проблемы? А то моя банальная эрудиция теряется и отказывается отвечать на этот вопрос. :) |
|
|
|
(0013935)
|
|
zed
|
|
09-03-2014 11:53
|
|
|
|
|
|
|
Речь про 64-битную компиляцию, у нас она пока даже не планируется. Плюс как я понимаю сами эти библиотеки компилируются без подключения Эврики, а для самой САС.Планеты мы ASLR включать тоже не планировали. |
|
|
|
(0013937)
|
|
zed
|
|
09-03-2014 12:21
|
|
> Плюс как я понимаю сами эти библиотеки компилируются без подключения Эврики
Некоторые (libge) с эврикой.
Я согласен, что для нас это пока не актуально, однако ж, могут быть и грабли. |
|
dll_base.png (202,762) 15-11-2013 19:26