Bug 4263 - valgrind does not even start if hard virtual memory limit is set
: valgrind does not even start if hard virtual memory limit is set
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/valgrind)
: unstable
: all Linux
: P1 blocker
Assigned To:
:
:
:
:
: 3459 7371
  Show dependency tree
 
Reported: 2004-05-31 01:34 by
Modified: 2007-10-23 15:17 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-05-31 01:34:57
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 From 2004-05-31 16:31:05 -------
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 From 2004-05-31 16:40:45 -------
Раз valgrind раньше работал с ulimit -Hv, значит должен и теперь работать.

Я могу пожертвовать работоспособностью valgrind'а на 2.2.x, но
я не могу пожертвовать лимитами из-за valgrind'а.
------- Comment #3 From 2004-05-31 18:38:02 -------
Старые версии действительно работали.  Там использовался совершенно другой
механизм запуска - через LD_PRELOAD, откуда вытекали ограничения -
неспособность
работать со статически собранными программами и невозможность контроля за
действиями процесса на ранних стадиях его запуска.  Кроме того, в valgrind
нельзя было пользоваться функциями glibc.  Возвращаться к этому варианту явно
бессмысленно.
------- Comment #4 From 2004-06-01 21:26:46 -------
Дим, а какие у тебя стоят лимиты ?
У нас по умолчанию:
$ ulimit -Hv
unlimited
------- Comment #5 From 2004-06-02 15:38:59 -------
У меня по умолчанию всегда установлен -Hv.
Установлено, что новый valgrind с установленным -Hv не запускается.
------- Comment #6 From 2004-06-02 15:58:50 -------
Серег, а что говорят разработчики valgrind ?
Или они не в курсе ?
------- Comment #7 From 2004-06-03 17:45:15 -------
какое состояние этой баги? 
 
------- Comment #8 From 2004-06-03 18:35:05 -------
Всё как описано - при установленном 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 From 2004-06-30 22:38:06 -------
Как я понял, разработчикам Valgrind данная проблема неинтересна - см.,
например,
http://article.gmane.org/gmane.comp.debugging.valgrind/1396
------- Comment #10 From 2005-06-14 12:33:45 -------
на всякий случай делаю block для 3.0
------- Comment #11 From 2005-06-14 14:20:18 -------
ой.  т.е. на разработческие компоненты и прочее делать блоки?  так они никогда
не разгребутся...
------- Comment #12 From 2005-06-14 16:34:21 -------
block перетащен с block'а для Master 2.4
------- Comment #13 From 2006-02-27 22:15:59 -------
В valgrind-3.1.0 проблема совместимости с ulimit -Hv решена (новый механизм
запуска не требует занятия всего адресного пространства mmap-ами, правда, ценой
статической сборки самого valgrind).

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