0002245: Исправить базовые адреса для dll входящих в дистрибутив

(0013270)
zed (manager)
15-11-2013 16:49

Работает - не трогай.

(0013272)
vdemidov (manager)
15-11-2013 18:22
edited on: 15-11-2013 18:22

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

(0013273)
zed (manager)
15-11-2013 18:28

Нужно же чтобы ещё и адресное пространство всех dll не пересекалось. Т.е. если просто задать адрес одной либе $20000000, а другой $20000004 толку всё равно не будет.

(0013274)
vdemidov (manager)
15-11-2013 18:44

Проще всего взять адреса на которые их сейчас преобразует система.

(0013275)
zed (manager)
15-11-2013 18:47

Мне кажется, это будет зависеть от системы. Покажи скриншот со своими адресами?

(0013276)
vdemidov (manager)
15-11-2013 19:01

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

(0013277)
vdemidov (manager)
15-11-2013 19:54

Первый скриншот сделан на 64-битной винде, а второй на 32-битном нетбуке.

(0013278)
vdemidov (manager)
15-11-2013 20:08

Кстати, я не предлагаю менять сразу все dll, потому и разбил на кучу дочерних хотелок. Можно поштучно, постепенно подкладывая в ночнушки.

(0013770)
zed (manager)
13-02-2014 11:57

Мне нужен список: dll - base adress, в котором будут перечислены все dll, которые может использовать SAS на текущий момент и базовые адреса, которые они должны использовать. Этот список (в виде текстового файла), я ожидаю в этом репозитории: https://bitbucket.org/sas_team/sas.lib.external

Как только будет такой список, я пересоберу нужные dll и закрою все связанные тикеты. Сам я составлять этот список не возьмусь.

(0013771)
vdemidov (manager)
13-02-2014 12:31

Тебе именно файлик нужен? Если я в конкретные тикеты повписываю? А то создание временного файлика в репозитории смотрится странно.

(0013772)
zed (manager)
13-02-2014 12:33

Почему же временного? При последующих обновлениях либ мне же нужно будет не забыть прописывать правильные адреса. Так что файлик будет более чем постоянный. И на него нужно будет ориентироваться при добавлении новых dll.

(0013775)
vdemidov (manager)
13-02-2014 12:57

Давай я все-таки где-то здесь выложу файлик, а в репу закинешь его сам. А то когда я это смогу сделать, я не знаю.

(0013776)
zed (manager)
13-02-2014 12:58

Ок.

(0013778)
zed (manager)
13-02-2014 13:52

Кстати, обрати внимание. На твоём же скриншоте у leveldb и libpng прописаны как бы правильные ImageBase. Но на самом деле у них всё те же 0x10000000h. И вообще этот адрес у всех сишных либ, что я собирал, но монитор почему-то его не показывает и всё выглядит как-будто бы ОК.

(0013779)
vdemidov (manager)
13-02-2014 14:44

Ты меня озадачил. Единственная мысль которая приходит в голову, что дело в использовании ASLR в Windows 7, а оба скриншота делались на Windows 7 хоть и с разной битностью. Для leveldb и libpng включена поддержка ASLR. При этом система выполняет реаллокацию, вроде как, один раз для всех процессов. Так что учитывая, что XP уже пропадает, можно попробовать ограничиться включением ASLR для собранных нами библиотек.

(0013780)
zed (manager)
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)

ну и приглядывать за этим моментом, при добавлении новых либ.

(0013781)
vdemidov (manager)
13-02-2014 15:07

Точно. Дело именно в ASLR, если я запускаю вторую копию Планеты до закрытия первой то адреса leveldb и libpng в ней будут точно такие же как и в первой, а если после закрытия, то у leveldb и libpng уже получаются новые адреса.

(0013782)
vdemidov (manager)
13-02-2014 15:10

> ну и приглядывать за этим моментом, при добавлении новых либ.
А какие из проблемных либ у нас студией собираются? FreeImage.dll и все?

(0013783)
zed (manager)
13-02-2014 15:12

Да. Там почему-то оказалось, что этот флаг снят. Надо будет посмотреть в настройки проекта.

(0013784)
zed (manager)
13-02-2014 15:24
edited on: 13-02-2014 15:25

ASLR решает проблему двойной загрузки dll в память, но при первой загрузке либы, у нас таки будет происходить реалокация адресов, о чём говорилось в статье, по мотивам которой и открыт тикет:

> Процесс загрузки по другому адресу долгий. Система пробегает по всему коду, и исправляет адреса на правильные, а таких адресов может быть десятки и сотни тысяч(!!!).

И возникает дилемма: с одной стороны современные технологии и ASLR, а с другой - быстродействие. Так что может имеет смысл наоборот, отключить эту фишку, если ты отдаёшь приоритет именно быстродействию?

Тот же zlib, который я сегодня обновил, не использует ASLR и у него уникальный image adress. Т.е. их выбор налицо.

(0013785)
vdemidov (manager)
13-02-2014 15:25

http://blogs.msdn.com/b/mattev/archive/2007/08/21/enabling-aslr-for-memory-savings.aspx

Судя по этой заметке я таки правильно понял работу ASLR и она таки решение проблемы с минимумом работы.

(0013786)
vdemidov (manager)
13-02-2014 15:27

Почитай статейку, при использовании ASLR реаллокация происходит в ядре, а не в процессе и она общая для всех экземпляров использующих dll. Так что никакой диллемы.

(0013787)
vdemidov (manager)
13-02-2014 15:28

http://stackoverflow.com/questions/3617600/does-aslr-cause-a-slow-loading-of-dlls

(0013788)
zed (manager)
13-02-2014 15:34

Ок, stackoverflow меня убедил. Значит переходим на ASLR где это возможно?

(0013789)
vdemidov (manager)
13-02-2014 15:37

Ну как по мне это логичный шаг. И вроде как проблем принести не должен. Кстати, а какие вообще могут быть проблемы? А то моя банальная эрудиция теряется и отказывается отвечать на этот вопрос. :)

(0013935)
zed (manager)
09-03-2014 11:53

64-Bit EurekaLog compiler crashes when enabling ASLR and NX

(0013936)
vdemidov (manager)
09-03-2014 12:12

Речь про 64-битную компиляцию, у нас она пока даже не планируется. Плюс как я понимаю сами эти библиотеки компилируются без подключения Эврики, а для самой САС.Планеты мы ASLR включать тоже не планировали.

(0013937)
zed (manager)
09-03-2014 12:21

> Плюс как я понимаю сами эти библиотеки компилируются без подключения Эврики
Некоторые (libge) с эврикой.

Я согласен, что для нас это пока не актуально, однако ж, могут быть и грабли.

Users who viewed this issue
User List	Anonymous (4729x), zed (1x)
Total Views	4730
Last View	21-11-2024 09:35

Issue History
Date Modified	Username	Field	Change
15-11-2013 14:51	vdemidov	New Issue
15-11-2013 14:51	vdemidov	Status	new => confirmed
15-11-2013 14:55	vdemidov	Relationship added	parent of 0002246
15-11-2013 14:56	vdemidov	Relationship added	parent of 0002247
15-11-2013 14:58	vdemidov	Relationship added	parent of 0002248
15-11-2013 15:00	vdemidov	Relationship added	parent of 0002249
15-11-2013 15:02	vdemidov	Relationship added	parent of 0002250
15-11-2013 15:04	vdemidov	Relationship added	parent of 0002251
15-11-2013 15:08	vdemidov	Status	confirmed => assigned
15-11-2013 15:08	vdemidov	Assigned To	=> zed
15-11-2013 16:49	zed	Note Added: 0013270
15-11-2013 18:22	vdemidov	Note Added: 0013272
15-11-2013 18:22	vdemidov	Note Edited: 0013272	View Revisions
15-11-2013 18:28	zed	Note Added: 0013273
15-11-2013 18:44	vdemidov	Note Added: 0013274
15-11-2013 18:47	zed	Note Added: 0013275
15-11-2013 19:01	vdemidov	Note Added: 0013276
15-11-2013 19:26	vdemidov	File Added: dll_base.png
15-11-2013 19:52	vdemidov	File Added: dll_base32.png
15-11-2013 19:54	vdemidov	Note Added: 0013277
15-11-2013 20:08	vdemidov	Note Added: 0013278
13-02-2014 11:57	zed	Note Added: 0013770
13-02-2014 11:58	zed	Status	assigned => feedback
13-02-2014 12:31	vdemidov	Note Added: 0013771
13-02-2014 12:31	vdemidov	Status	feedback => assigned
13-02-2014 12:33	zed	Note Added: 0013772
13-02-2014 12:57	vdemidov	Note Added: 0013775
13-02-2014 12:58	zed	Note Added: 0013776
13-02-2014 13:52	zed	Note Added: 0013778
13-02-2014 14:44	vdemidov	Note Added: 0013779
13-02-2014 15:05	zed	Note Added: 0013780
13-02-2014 15:07	vdemidov	Note Added: 0013781
13-02-2014 15:10	vdemidov	Note Added: 0013782
13-02-2014 15:12	zed	Note Added: 0013783
13-02-2014 15:24	zed	Note Added: 0013784
13-02-2014 15:25	vdemidov	Note Added: 0013785
13-02-2014 15:25	zed	Note Edited: 0013784	View Revisions
13-02-2014 15:27	vdemidov	Note Added: 0013786
13-02-2014 15:28	vdemidov	Note Added: 0013787
13-02-2014 15:34	zed	Note Added: 0013788
13-02-2014 15:37	vdemidov	Note Added: 0013789
03-03-2014 08:47	vdemidov	Target Version	140303 => 140404
09-03-2014 11:53	zed	Note Added: 0013935
09-03-2014 12:12	vdemidov	Note Added: 0013936
09-03-2014 12:21	zed	Note Added: 0013937
24-10-2014 11:40	vdemidov	Target Version	140404 => 141111
30-10-2014 12:10	zed	Status	assigned => resolved
30-10-2014 12:10	zed	Fixed in Version	=> 141111
30-10-2014 12:10	zed	Resolution	open => fixed

Notes
(0013270) zed (manager) 15-11-2013 16:49	Работает - не трогай.

(0013272) vdemidov (manager) 15-11-2013 18:22 edited on: 15-11-2013 18:22	Всего-то надо поменять базовый адрес и перекомпилировать. Хуже не будет.

(0013273) zed (manager) 15-11-2013 18:28	Нужно же чтобы ещё и адресное пространство всех dll не пересекалось. Т.е. если просто задать адрес одной либе $20000000, а другой $20000004 толку всё равно не будет.

(0013274) vdemidov (manager) 15-11-2013 18:44	Проще всего взять адреса на которые их сейчас преобразует система.

(0013275) zed (manager) 15-11-2013 18:47	Мне кажется, это будет зависеть от системы. Покажи скриншот со своими адресами?

(0013276) vdemidov (manager) 15-11-2013 19:01	Будет, на других системах могут быть программы внедряем длл с совпадающими адресами и произойдет релокация, но сейчас то релокация точно происходит.

(0013277) vdemidov (manager) 15-11-2013 19:54	Первый скриншот сделан на 64-битной винде, а второй на 32-битном нетбуке.

(0013278) vdemidov (manager) 15-11-2013 20:08	Кстати, я не предлагаю менять сразу все dll, потому и разбил на кучу дочерних хотелок. Можно поштучно, постепенно подкладывая в ночнушки.

(0013770) zed (manager) 13-02-2014 11:57	Мне нужен список: dll - base adress, в котором будут перечислены все dll, которые может использовать SAS на текущий момент и базовые адреса, которые они должны использовать. Этот список (в виде текстового файла), я ожидаю в этом репозитории: https://bitbucket.org/sas_team/sas.lib.external Как только будет такой список, я пересоберу нужные dll и закрою все связанные тикеты. Сам я составлять этот список не возьмусь.

(0013771) vdemidov (manager) 13-02-2014 12:31	Тебе именно файлик нужен? Если я в конкретные тикеты повписываю? А то создание временного файлика в репозитории смотрится странно.

(0013772) zed (manager) 13-02-2014 12:33	Почему же временного? При последующих обновлениях либ мне же нужно будет не забыть прописывать правильные адреса. Так что файлик будет более чем постоянный. И на него нужно будет ориентироваться при добавлении новых dll.

(0013775) vdemidov (manager) 13-02-2014 12:57	Давай я все-таки где-то здесь выложу файлик, а в репу закинешь его сам. А то когда я это смогу сделать, я не знаю.

(0013776) zed (manager) 13-02-2014 12:58	Ок.

(0013778) zed (manager) 13-02-2014 13:52	Кстати, обрати внимание. На твоём же скриншоте у leveldb и libpng прописаны как бы правильные ImageBase. Но на самом деле у них всё те же 0x10000000h. И вообще этот адрес у всех сишных либ, что я собирал, но монитор почему-то его не показывает и всё выглядит как-будто бы ОК.

(0013779) vdemidov (manager) 13-02-2014 14:44	Ты меня озадачил. Единственная мысль которая приходит в голову, что дело в использовании ASLR в Windows 7, а оба скриншота делались на Windows 7 хоть и с разной битностью. Для leveldb и libpng включена поддержка ASLR. При этом система выполняет реаллокацию, вроде как, один раз для всех процессов. Так что учитывая, что XP уже пропадает, можно попробовать ограничиться включением ASLR для собранных нами библиотек.

(0013780) zed (manager) 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) ну и приглядывать за этим моментом, при добавлении новых либ.

(0013781) vdemidov (manager) 13-02-2014 15:07	Точно. Дело именно в ASLR, если я запускаю вторую копию Планеты до закрытия первой то адреса leveldb и libpng в ней будут точно такие же как и в первой, а если после закрытия, то у leveldb и libpng уже получаются новые адреса.

(0013782) vdemidov (manager) 13-02-2014 15:10	> ну и приглядывать за этим моментом, при добавлении новых либ. А какие из проблемных либ у нас студией собираются? FreeImage.dll и все?

(0013783) zed (manager) 13-02-2014 15:12	Да. Там почему-то оказалось, что этот флаг снят. Надо будет посмотреть в настройки проекта.

(0013784) zed (manager) 13-02-2014 15:24 edited on: 13-02-2014 15:25	ASLR решает проблему двойной загрузки dll в память, но при первой загрузке либы, у нас таки будет происходить реалокация адресов, о чём говорилось в статье, по мотивам которой и открыт тикет: > Процесс загрузки по другому адресу долгий. Система пробегает по всему коду, и исправляет адреса на правильные, а таких адресов может быть десятки и сотни тысяч(!!!). И возникает дилемма: с одной стороны современные технологии и ASLR, а с другой - быстродействие. Так что может имеет смысл наоборот, отключить эту фишку, если ты отдаёшь приоритет именно быстродействию? Тот же zlib, который я сегодня обновил, не использует ASLR и у него уникальный image adress. Т.е. их выбор налицо.

(0013785) vdemidov (manager) 13-02-2014 15:25	http://blogs.msdn.com/b/mattev/archive/2007/08/21/enabling-aslr-for-memory-savings.aspx Судя по этой заметке я таки правильно понял работу ASLR и она таки решение проблемы с минимумом работы.

(0013786) vdemidov (manager) 13-02-2014 15:27	Почитай статейку, при использовании ASLR реаллокация происходит в ядре, а не в процессе и она общая для всех экземпляров использующих dll. Так что никакой диллемы.

(0013787) vdemidov (manager) 13-02-2014 15:28	http://stackoverflow.com/questions/3617600/does-aslr-cause-a-slow-loading-of-dlls

(0013788) zed (manager) 13-02-2014 15:34	Ок, stackoverflow меня убедил. Значит переходим на ASLR где это возможно?

(0013789) vdemidov (manager) 13-02-2014 15:37	Ну как по мне это логичный шаг. И вроде как проблем принести не должен. Кстати, а какие вообще могут быть проблемы? А то моя банальная эрудиция теряется и отказывается отвечать на этот вопрос. :)

(0013935) zed (manager) 09-03-2014 11:53	64-Bit EurekaLog compiler crashes when enabling ASLR and NX

(0013936) vdemidov (manager) 09-03-2014 12:12	Речь про 64-битную компиляцию, у нас она пока даже не планируется. Плюс как я понимаю сами эти библиотеки компилируются без подключения Эврики, а для самой САС.Планеты мы ASLR включать тоже не планировали.

(0013937) zed (manager) 09-03-2014 12:21	> Плюс как я понимаю сами эти библиотеки компилируются без подключения Эврики Некоторые (libge) с эврикой. Я согласен, что для нас это пока не актуально, однако ж, могут быть и грабли.

SASGIS