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.