“4GB will always be enough”.
Порой разработчики приложений просто поражают своей храбростью и безудержным оптимизмом. Свежий пример – на днях получаю письмо с просьбой разобраться почему 32-битное приложение, нормально работавшее в Windows Server 2003 for Itanium перестало запускаться в Windows Server 2008 for Itanium. Что особенно приятно, так это то, что вместо традиционного «приложение падает, если сделать то, то и вот то», просто прислали сессию отладчика, остановленную непосредственно перед вызовом NtAllocateVirtualMemory, который и приводил к падению.
Сам вызов выглядел довольно невинно если не считать, что запрашивался блок памяти размером чуть более 1GB. После некоторого копания в незнакомом коде выяснилось, что размер запрашиваемого блока и был причиной – в адресном пространстве процесса просто не осталось свободного блока такого размера.
На этом мое расследование закончилось и я спихнул проблему на другого разработчика, так как все равно это не моя епархия, а дел по горло и т.д. Однако на следующий день этот баг всё равно вернулся ко мне. Как оказалось причиной все-таки скрывалась в Wow64. Одна из системных .dll, загружаемых этим процессом в Windows Server 2008 загружалась прямо по середине свободного адресного пространства, разбивая его пополам. В Windows Server 2003 же эта .dll ютилась на краю адресного пространства, никому при этом не мешая. Причиной этому были две вещи:
- Базовый адрес .dll изменился с 0×7xxxxxxx на 0×4xxxxxxx;
- Механизм dynamic rebase, который в обычных условиях не позволяет .dll занять «лучшее место в центре» не сработал на этот раз из-за того, что эта .dll была собрана с выравниванием на границу 4KB, а на IA-64 dynamic rebase работает только с библиотеками выровненными на границу 8KB.
В общем, починить эту проблему не составило труда. Однако оптимизм разработчиков приложения меня удивил. Затребовать больше половины адресного пространства одним куском и свято верить в успех этого безнадежного дела – это требует немалой выдержки. А если вспомнить, что набор системных библиотек разниться от версии к версии, да, к тому же, что в любой момент в процесс может внедриться посторонняя .dll, за какой-то своей надобностью, то вообще нужны стальные нервы, чтобы при этом спокойно спать.
Вечер добрый.
А что значит “просто прислали сессию отладчика”? Встали на вызов функции и сделали дамп? Или что-то другое?
Нет, дали живую отладочную сессию, к которой можно подключиться удалённо с помощью “windbg -remote xxx”. На одной машине запускается ядерный отладчик в режиме сервера: “kd.exe -server npipe:pipe=remote”. С другой машины к немe можно подсоединиться “windbg.exe -remote npipe:server=xxx,pipe=remote”. Все 4 отладчика (kd.exe, cdb.exe, ntsd.exe и windbg.exe) поддерживают это одинаково.
Понятно. Спасибо.
Кстати, а Вы не в курсе, сможет ли когда-нибудь VS заменить windbg?
Был бы ещё windbg удобней…
Это от его разработчиков зависит.
Пока что windbg и VS разрабатываются совсем разными людьми. И цели у них тоже разные. VS ориентируется на разработчиков приложений. Windbg – на тех, кто ковыряется в недрах системы.
По мне так было бы неплохо сделать Windbg c человеческим лицом. А то это ужас какой-то. Visual Studio я все равно практически не пользуюсь…
На самом деле не очень себе представляю адресное пространство равное двум в 64-ой степени.. Привычнее родные 4 ГБ.. Хотя считаю, что Itanium-64, это очень хороший прорыв. Окно в будущее… Теперь мало кто будет думать о том, чтобы экономить память, времена уходят в прошлое. Сейчас на первый план – выходят сроки сдачи проекта, увы.
Скажите, а невозможность загрузки в 64bit-процесс 32bit DLL – фатальна, или же возможны какие-то хаки, недокументированные обходные пути?
Ответил отделным постом: http://blog.not-a-kernel-guy.com/2008/02/28/293