4263 2004-05-31 01:34:57 +0400 valgrind does not even start if hard virtual memory limit is set 2007-10-23 15:17:47 +0400 1 1 4 Development Sisyphus valgrind unstable all Linux CLOSED FIXED P1 blocker --- 3459 7371 1 ldv iv iv mike rider qa-sisyphus oldest_to_newest 14419 0 ldv 2004-05-31 01:34:57 +0400 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. 14435 1 vsu 2004-05-31 16:31:05 +0400 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, похоже, уже забыли... 14436 2 ldv 2004-05-31 16:40:45 +0400 Раз valgrind раньше работал с ulimit -Hv, значит должен и теперь работать. Я могу пожертвовать работоспособностью valgrind'а на 2.2.x, но я не могу пожертвовать лимитами из-за valgrind'а. 14444 3 vsu 2004-05-31 18:38:02 +0400 Старые версии действительно работали. Там использовался совершенно другой механизм запуска - через LD_PRELOAD, откуда вытекали ограничения - неспособность работать со статически собранными программами и невозможность контроля за действиями процесса на ранних стадиях его запуска. Кроме того, в valgrind нельзя было пользоваться функциями glibc. Возвращаться к этому варианту явно бессмысленно. 14482 4 rider 2004-06-01 21:26:46 +0400 Дим, а какие у тебя стоят лимиты ? У нас по умолчанию: $ ulimit -Hv unlimited 14543 5 ldv 2004-06-02 15:38:59 +0400 У меня по умолчанию всегда установлен -Hv. Установлено, что новый valgrind с установленным -Hv не запускается. 14545 6 rider 2004-06-02 15:58:50 +0400 Серег, а что говорят разработчики valgrind ? Или они не в курсе ? 14652 7 inger 2004-06-03 17:45:15 +0400 какое состояние этой баги? 14661 8 vsu 2004-06-03 18:35:05 +0400 Всё как описано - при установленном ulimit -Hv valgrind не запускается (в последней сборке добавлен патч, чтобы падало сразу с выдачей сообщения, а не потом с SIGSEGV без сообщений). В конфигурации из коробки таких лимитов нет, и valgrind работает. Цель этих громадных mmap (start=0x80ec000, len=0xa7f14000 - больше 2,5 GB) - заставить обычный ld-linux.so.2 загрузить libc.so.6 и прочие библиотеки в нужные адреса, чтобы оставить адреса ниже 0xb0000000 свободными для загрузки отлаживаемой программы. Я не вижу другого способа добиться этого. Можно попробовать динамически выбирать границу для mmap (это осложняется тем, что эти адреса забиты в valgrind в нескольких местах)... 16024 9 vsu 2004-06-30 22:38:06 +0400 Как я понял, разработчикам Valgrind данная проблема неинтересна - см., например, http://article.gmane.org/gmane.comp.debugging.valgrind/1396 25664 10 rider 2005-06-14 12:33:45 +0400 на всякий случай делаю block для 3.0 25690 11 mike 2005-06-14 14:20:18 +0400 ой. т.е. на разработческие компоненты и прочее делать блоки? так они никогда не разгребутся... 25733 12 rider 2005-06-14 16:34:21 +0400 block перетащен с block'а для Master 2.4 36308 13 vsu 2006-02-27 22:15:59 +0300 В valgrind-3.1.0 проблема совместимости с ulimit -Hv решена (новый механизм запуска не требует занятия всего адресного пространства mmap-ами, правда, ценой статической сборки самого valgrind). Впрочем, теперь там появилась другая проблема - несовместимость с ядрами, использующими нестандартные значения user/kernel split (параметры конфигурации типа 1GLOWMEM, и тем более VMSPLIT_2G и VMSPLIT_1G). В результате в данный момент valgrind не работает с ядрами wks26, которые собраны с опцией 1GLOWMEM. 46457 14 vsu 2007-03-11 16:49:22 +0300 По сведениям из https://bugzilla.altlinux.org/show_bug.cgi?id=9169#c3 , valgrind-3.2.x работает и с ядрами, собранными с 1GLOWMEM.