Что с этим багом? он регулярно воспроизводится, уже 4 попытки -
#56797 FAILED #4 t6 copy=bouncycastle

при этом на пакеты, собранные из bouncycastle свежий sisyphus_check из сизифа
не ругается при локальном запуске. Однако в incoming что-то идет не так :(

перевешиваю на incoming, 
так как локально с sisyphus_check все ок

что с этим багом? он происходит в incoming,
локально не воспроизводится

(In reply to comment #3)
> что с этим багом? он происходит в incoming,
> локально не воспроизводится

Я не умею это воспроизводить.

(В ответ на комментарий №4)
> Я не умею это воспроизводить.

ssh git.alt task run 56797
:)

см. напр.
http://git.altlinux.org/tasks/56797/logs/events.6.1.log
6 раз запускал 56797 и каждый раз воспроизводится как часы.

rpmquery выводит мусор, и я, кажется, нашел источник этого мусора.

$ env -i sisyphus_check --files /tasks/56797/build/100/i586/rpms/bouncycastle-javadoc-1.46-alt2_3jpp6.noarch.rpm 
$ env -i LD_PRELOAD=rpmhdrmemcache.so sisyphus_check --files /tasks/56797/build/100/i586/rpms/bouncycastle-javadoc-1.46-alt2_3jpp6.noarch.rpm 
/tasks/56797/build/100/i586/rpms/bouncycastle-javadoc-1.46-alt2_3jpp6.noarch.rpm: FHS violations: /uNistCertPathReviewerTest.html /uNistCertPathTest.html /upackage-frame.html /upackage-summary.html /upackage-tree.html
sisyphus_check: check-fhs ERROR: FHS violation
$ rpmquery -f /usr/lib64/rpmhdrmemcache.so 
rpmhdrmemcache-0.1.1-alt2

Удалось минимизировать пример команды, выводящей мусор:
$ env -i LD_PRELOAD=rpmhdrmemcache.so rpmquery -p --qf='%{summary}\n[%{filenames}\n]' -- /ALT/Sisyphus/files/noarch/RPMS/bouncycastle-javadoc-1.46-alt2_3jpp6.noarch.rpm

$ rpmquery -f /usr/lib64/rpmhdrmemcache.so 
rpmhdrmemcache-0.1.1-alt3
Эффект прежний.

Если в --qf заменить summary, например, на name, то эффект пропадает.

А может это memcached_get портит данные, кто его знает...

(In reply to comment #11)
> А может это memcached_get портит данные, кто его знает...

Нет, memcached_get не портит, блобы одинаковые.

В дополнение ко всему, memcached-1.4.7-alt1 падает...

Придется объезжать неработающий rpmhdrmemcache.

gb-sh-rpmhdrcache больше не используется на стадии проверки пакетов.

спасибо!

Альт линукс глючит.

(In reply to comment #17)
> Альт линукс глючит.

На самом деле это rpm глючит: последовательность headerUnload -> headerLoad на этом пакете превращает header в мусор.

C rpmhdrcache.so не могу воспроизвести.

$ hostname                                                                                                            at.local.altlinux.org

$ ls -l /tmp/.rpmhdrcache/c5/9a177ba64ad73b7703572b74fc4fbf3fc9208e
-rw-r--r-- 1 at at 119152 Oct 31 15:13 /tmp/.rpmhdrcache/c5/9a177ba64ad73b7703572b74fc4fbf3fc9208e

$ LD_PRELOAD=rpmhdrcache.so strace -o trace -f -e trace=file rpmquery -p --qf='%{summary}\n[%{filenames}\n]' -- /ALT/Sisyphus/files/noarch/RPMS/bouncycastle-javadoc-1.46-alt2_3jpp6.noarch.rpm |head
Javadoc for bouncycastle                                                       
/usr/share/javadoc/bouncycastle
/usr/share/javadoc/bouncycastle-1.46
/usr/share/javadoc/bouncycastle-1.46/bcmail
/usr/share/javadoc/bouncycastle-1.46/bcmail/allclasses-frame.html
/usr/share/javadoc/bouncycastle-1.46/bcmail/allclasses-noframe.html
/usr/share/javadoc/bouncycastle-1.46/bcmail/constant-values.html
/usr/share/javadoc/bouncycastle-1.46/bcmail/deprecated-list.html
/usr/share/javadoc/bouncycastle-1.46/bcmail/help-doc.html
/usr/share/javadoc/bouncycastle-1.46/bcmail/index-all.html

$ grep openat trace
30691 openat(4, "c5/9a177ba64ad73b7703572b74fc4fbf3fc9208e", O_RDONLY) = 6

$ LD_PRELOAD=rpmhdrcache.so strace -o trace -f -e trace=file rpmquery -p --qf='%{summary}\n[%{filenames}\n]' -- /ALT/Sisyphus/files/noarch/RPMS/bouncycastle-javadoc-1.46-alt2_3jpp6.noarch.rpm |md5sum
a39d33f1df90c4c7bde2811273e4895d  -

$ rpmquery -p --qf='%{summary}\n[%{filenames}\n]' -- /ALT/Sisyphus/files/noarch/RPMS/bouncycastle-javadoc-1.46-alt2_3jpp6.noarch.rpm |md5sum                        
a39d33f1df90c4c7bde2811273e4895d  -

Created attachment 5180 [details]
показывает что блоб меняется после загрузки

Мужчины, этот патч показывает что блоб меняется прямо во время лоуда. Это должно навести нас на ценные мысли, что мы смотрим в память, которую почикали.

Created attachment 5181 [details]
патч который исправляет мемори проблемз фо ю

Мужчины, короче патч вот такой. Но я вам советую использовать rpmhdrcache, в котором это давно исправлено.

(In reply to comment #21)
> Created an attachment (id=5181) [details]
> патч который исправляет мемори проблемз фо ю

Спасибо.

> Мужчины, короче патч вот такой.

А зачем эти манипуляции с blobsize?

> Но я вам советую использовать rpmhdrcache,

Опять на bdb?

rpmhdrmemcache-0.1.2-alt1 -> sisyphus:

* Tue Nov 01 2011 Dmitry V. Levin <ldv@altlinux> 0.1.2-alt1
- Fixed potential memory corruption and memory leak
  (by Alexey Tourbin; closes: #26463).

Блоб может храниться в сжатом виде. Тогда подразумевается логика

void *blob = ...;
int blobsize = ....;
if (сжатый) {
  void *ublob = ...;
  int ublobsize = ...;
  ...
  blob = ublob;
  blob = ublobsize;
}
... blob, blobsize ...

То есть это конечно так, педантизм, но всё же, логика состоит в том, что поскольку далее в функции сжатый блоб нас не интересует, то разжатый блоб просто подменяет собой сжатый. А ublob по идее должен существовать только на время разжатия (область видимости - в блоке if).  Но ublob объявлен как массив на стеке, поэтому его нельзя внести в блок if.  Поэтому получается такая полумера: blobsize в принципе мог бы потребоваться далее в функции (хотя для headerLoad он не требуется), а ublob нельзя внести в блок if.

В чём преимущество memcached?  То, что к памяти доступ памяти быстрее, чем к диску - это ну такое tongue-in-chick объяснение, если только поржать.

bdb раньше глючила в режиме DB_INIT_CDB (либо из-за ошибок/допущений в реализации, либо из-за того, что использовался слишком маленький размер cachesize по умолчанию).  Потом я просто оторвал CDB и прикрутил внешний flock на каталог.  Долго ломал голову, можно ли реализовать rwlock с помощью futex'а или нет.  Ничего не придумал.

Вместо bdb можно реализовать какую-нибудь такую свою штуковину, которая делает ровно то, что нужно. Тем более что размер ключей у нас фиксированный (sha1).  В книжке W. Richard Stevens'а прямо для дураков написано как сделать hash queues, free list и т.д.  Но что-то бесплатно неохота упражняться, а больших денег за такое упраженение наверное никто не даст!