valgrind-2.1.2-alt0.2.20040522 (и предыдущая сборка тоже) даже не запускается на: 2.4.20-alt13-up/glibc-core-i686-2.3.3.200405070341-alt1, 2.4.26-std-smp-alt2/glibc-core-i686-2.3.3.200405070341-alt1, 2.4.26-std-smp-alt2/glibc-core-2.3.3.200405070341-alt1. Не запускается (падает) сразу после munmap'а в функции valgrind/coregrind/vg_main.c:layout_remaining_space(). $ valgrind --tool=memcheck client base--end: 0--50000000 (50000000) client mapbase: 3c000000 shadow base--end: 50100000--aa100000 (5a000000) Segmentation fault Отладочный вывод в этой функции появился после замены if(0) на if(1). Такое ощущение, что после применения munmap на стек valgrind падает сразу по выходу из этого системного вызова. На 2.2.26-alt1-smp-secure тоже не запускается: $ valgrind --tool=memcheck fix_auxv: we didn't see enough auxv entries (seen=0) Удалось запустить этот valgrind только на 2.6.5-std26-up-alt1.
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.
