Bug 4263

Summary: valgrind does not even start if hard virtual memory limit is set
Product: Sisyphus Reporter: Dmitry V. Levin <ldv>
Component: valgrindAssignee: 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-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.
Comment 1 Sergey Vlasov 2004-05-31 16:31:05 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, похоже, уже забыли...
Comment 2 Dmitry V. Levin 2004-05-31 16:40:45 MSD
Раз valgrind раньше работал с ulimit -Hv, значит должен и теперь работать.

Я могу пожертвовать работоспособностью valgrind'а на 2.2.x, но
я не могу пожертвовать лимитами из-за valgrind'а.
Comment 3 Sergey Vlasov 2004-05-31 18:38:02 MSD
Старые версии действительно работали.  Там использовался совершенно другой
механизм запуска - через LD_PRELOAD, откуда вытекали ограничения - неспособность
работать со статически собранными программами и невозможность контроля за
действиями процесса на ранних стадиях его запуска.  Кроме того, в valgrind
нельзя было пользоваться функциями glibc.  Возвращаться к этому варианту явно
бессмысленно.
Comment 4 Anton Farygin 2004-06-01 21:26:46 MSD
Дим, а какие у тебя стоят лимиты ?
У нас по умолчанию:
$ ulimit -Hv
unlimited
Comment 5 Dmitry V. Levin 2004-06-02 15:38:59 MSD
У меня по умолчанию всегда установлен -Hv.
Установлено, что новый valgrind с установленным -Hv не запускается.
Comment 6 Anton Farygin 2004-06-02 15:58:50 MSD
Серег, а что говорят разработчики valgrind ?
Или они не в курсе ?
Comment 7 inger@altlinux.org 2004-06-03 17:45:15 MSD
какое состояние этой баги? 
 
Comment 8 Sergey Vlasov 2004-06-03 18:35:05 MSD
Всё как описано - при установленном ulimit -Hv valgrind не запускается (в
последней сборке добавлен патч, чтобы падало сразу с выдачей сообщения, а не
потом с SIGSEGV без сообщений). В конфигурации из коробки таких лимитов нет, и
valgrind работает.

Цель этих громадных mmap (start=0x80ec000, len=0xa7f14000 - больше 2,5 GB) -
заставить обычный ld-linux.so.2 загрузить libc.so.6 и прочие библиотеки в нужные
адреса, чтобы оставить адреса ниже 0xb0000000 свободными для загрузки
отлаживаемой программы. Я не вижу другого способа добиться этого.

Можно попробовать динамически выбирать границу для mmap (это осложняется тем,
что эти адреса забиты в valgrind в нескольких местах)...
Comment 9 Sergey Vlasov 2004-06-30 22:38:06 MSD
Как я понял, разработчикам Valgrind данная проблема неинтересна - см., например,
http://article.gmane.org/gmane.comp.debugging.valgrind/1396
Comment 10 Anton Farygin 2005-06-14 12:33:45 MSD
на всякий случай делаю block для 3.0
Comment 11 Michael Shigorin 2005-06-14 14:20:18 MSD
ой.  т.е. на разработческие компоненты и прочее делать блоки?  так они никогда
не разгребутся...
Comment 12 Anton Farygin 2005-06-14 16:34:21 MSD
block перетащен с block'а для Master 2.4
Comment 13 Sergey Vlasov 2006-02-27 22:15:59 MSK
В valgrind-3.1.0 проблема совместимости с ulimit -Hv решена (новый механизм
запуска не требует занятия всего адресного пространства mmap-ами, правда, ценой
статической сборки самого valgrind).

Впрочем, теперь там появилась другая проблема - несовместимость с ядрами,
использующими нестандартные значения user/kernel split (параметры конфигурации
типа 1GLOWMEM, и тем более VMSPLIT_2G и VMSPLIT_1G).  В результате в данный
момент valgrind не работает с ядрами wks26, которые собраны с опцией 1GLOWMEM.
Comment 14 Sergey Vlasov 2007-03-11 16:49:22 MSK
По сведениям из https://bugzilla.altlinux.org/show_bug.cgi?id=9169#c3 ,
valgrind-3.2.x работает и с ядрами, собранными с 1GLOWMEM.