ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | valgrind does not even start if hard virtual memory limit is set | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Dmitry V. Levin <ldv> |
| Component: | valgrind | Assignee: | placeholder <placeholder> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | blocker | ||
| Priority: | P1 | CC: | glebfm, ldv, mike, placeholder, rider, vsu |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| Bug Depends on: | |||
| Bug Blocks: | 3459, 7371 | ||
|
Description
Dmitry V. Levin
2004-05-31 01:34:57 MSD
Valgrind не работает при назначении лимитов на адресное пространство процесса (ulimit -Hv; soft limit автоматически увеличивается до соответствующего hard limit и не мешает запуску). Это обусловлено механизмом запуска valgrind. Статически собранный /usr/bin/valgrind (stage1) заполняет всё адресное пространство процесса ниже адреса 0xb0000000 mmap-ами временного файла (с атрибутами PROT_NONE, MAP_FIXED|MAP_PRIVATE), после чего осуществляет загрузку stage2 и ld-linux.so.2 в оставшееся адресное пространство и передаёт управление ld-linux.so.2. Далее ld-linux.so.2 стандартным образом загружает libc и другие используемые stage2 разделяемые библиотеки, которые благодаря занятости адресного пространства также размещаются выше 0xb0000000. После завершения инициализации stage2 убирает всё из адресов ниже 0xb0000000 (в том числе и stage1) и загружает клиентскую программу. Про ядра 2.2.x разработчики valgrind, похоже, уже забыли... Раз valgrind раньше работал с ulimit -Hv, значит должен и теперь работать. Я могу пожертвовать работоспособностью valgrind'а на 2.2.x, но я не могу пожертвовать лимитами из-за valgrind'а. Старые версии действительно работали. Там использовался совершенно другой механизм запуска - через LD_PRELOAD, откуда вытекали ограничения - неспособность работать со статически собранными программами и невозможность контроля за действиями процесса на ранних стадиях его запуска. Кроме того, в valgrind нельзя было пользоваться функциями glibc. Возвращаться к этому варианту явно бессмысленно. Дим, а какие у тебя стоят лимиты ? У нас по умолчанию: $ ulimit -Hv unlimited У меня по умолчанию всегда установлен -Hv. Установлено, что новый valgrind с установленным -Hv не запускается. Серег, а что говорят разработчики valgrind ? Или они не в курсе ? какое состояние этой баги? Всё как описано - при установленном ulimit -Hv valgrind не запускается (в последней сборке добавлен патч, чтобы падало сразу с выдачей сообщения, а не потом с SIGSEGV без сообщений). В конфигурации из коробки таких лимитов нет, и valgrind работает. Цель этих громадных mmap (start=0x80ec000, len=0xa7f14000 - больше 2,5 GB) - заставить обычный ld-linux.so.2 загрузить libc.so.6 и прочие библиотеки в нужные адреса, чтобы оставить адреса ниже 0xb0000000 свободными для загрузки отлаживаемой программы. Я не вижу другого способа добиться этого. Можно попробовать динамически выбирать границу для mmap (это осложняется тем, что эти адреса забиты в valgrind в нескольких местах)... Как я понял, разработчикам Valgrind данная проблема неинтересна - см., например, http://article.gmane.org/gmane.comp.debugging.valgrind/1396 на всякий случай делаю block для 3.0 ой. т.е. на разработческие компоненты и прочее делать блоки? так они никогда не разгребутся... block перетащен с block'а для Master 2.4 В valgrind-3.1.0 проблема совместимости с ulimit -Hv решена (новый механизм запуска не требует занятия всего адресного пространства mmap-ами, правда, ценой статической сборки самого valgrind). Впрочем, теперь там появилась другая проблема - несовместимость с ядрами, использующими нестандартные значения user/kernel split (параметры конфигурации типа 1GLOWMEM, и тем более VMSPLIT_2G и VMSPLIT_1G). В результате в данный момент valgrind не работает с ядрами wks26, которые собраны с опцией 1GLOWMEM. По сведениям из https://bugzilla.altlinux.org/show_bug.cgi?id=9169#c3 , valgrind-3.2.x работает и с ядрами, собранными с 1GLOWMEM. |
