[проблемы из ниоткуда] ошибка сегментирования. как найти причину?

1) Посмотри, нет ли записей о сегфолтах в messages.
2) Попробуй временно переименовать ~/.ssh

ltrace ssh svn-server

Ну явно же написано, что у тебя known_hosts покоцан. Сдвинь его в сторонку и не парься.

Но таки программа не должна падать из-за проблемы в каком-то конфиге.

благодарю за толковые советы

1) нашёл вот что

Sep 26 11:37:32 workstation kernel: [13062.250544] ssh[16091] general protection ip:7fce31790c47 sp:7fff66de9050 error:0 in libcrypto.so.0.9.8[7fce31720000+163000]

поискал в сети, похоже, libcrypto.so.0.9.8 - часть openssl. однако aptitude reinstall openssl - не помогло

2)

andrey@workstation:~$ mv .ssh .ssh_old
andrey@workstation:~$ ssh svn-server
The authenticity of host 'svn-server (192.168.0.20)' can't be established.
RSA key fingerprint is [--skiped--].
Are you sure you want to continue connecting (yes/no)? yes
Ошибка сегментирования
andrey@workstation:~$

не, я ж написал, ltrace ничего не дал:

 
ltrace ssh svn-server 
--- SIGSEGV (Segmentation fault) --- 
+++ killed by SIGSEGV +++ 

да, кстати, вряд ли.. но я тем не менее сдвинул его.. не помогло..

можно ли как-то запустить проверку контрольных сумм всех файлов установленных пакетным менеджером?

> идеи?

Запустить под gdb и посмотреть почему упало.

отвечая на свой вопрос - debsums

да, но это я оставлял на крайняк. сейчас debsums'ом пройдусь, если без результата - полезу в gdb

segfault на ровном месте - верный признак проблем с ОЗУ.

Память, инфа 100%.

>не, я ж написал, ltrace ничего не дал:

тогда

strace ssh svn-server

chkrootkit и rkhunter попробуй

тестил мемтестом вчерась - всё было в порядке

и работал вчера ssh

ну и странно что на одном и том же месте.. скорее уж с диском проблемы..

мужик, я думаю специально для тебя нужно ввести звание Ъ^2.

> segfault на ровном месте - верный признак проблем с ОЗУ.

Где,ж он на ровном месте? Какова вероятность, что при многочисленных попытках считать файл он всегда будет попадать на битую область?

> ну и странно что на одном и том же месте..

Попробуй создать временного пользователя и ткнуться из под недго. Если проблема сохранится - сегфолтит не ssh, тогда ldd-шкой проверить зависимости (вплоть до glibc) и попробовать зареинсталлить. Кстати ошибки на fs уже выправлены? Или отложены?

>ошибка сегментирования

У меня эта штука половину портов засосала!!!1111 А дело всё было в слоте памяти на материнке. И memtest86+ молчал.

libc переставь и tls и прочие либы, которыми пользуется ssh. переустановка только ssh не приведет к переустановке этих либ

Хехе... вероятная причина кроется в svn.

Сам лично сталкивался с регулярными падениями СВН составляющих в дебе. Как правило это происходило при попытке СВНа обратиться в дбасу. Но и в других ситуациях тоже, но реже...

> Хехе... вероятная причина кроется в svn.

Причём тут svn?

open(«/home/andrey/.ssh/known_hosts», O_RDONLY) = 4 <--- тут открывается файл (4 - это дескриптор).

fstat(4, {st_mode=S_IFREG|0644, st_size=20944, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7838610000 read(4, «|1|Z68tL1zRxBLXRd5grpUAxp8376U=|»..., 4096) = 4096 <--- тут при попытке прочитать из него наступает экстерминатус. Либо коцанная фс, либо коцанная либа, из-за которой в качестве буфера чтения используется уже занятая память.

read() отработал нормально. Проблема где-то доальше в коде. Надо gdb.

Ага, я тоже сидел с gdb и дебажил почему svn up падает :) Проблема была глубоко-глубоко :) А на деле все оказалось куда проще.

Там цикл чтения по 4096. Еслибы он отработал нормально, мы бы увидели следующую итерацию (размер файла больше).

всем спасибо

помогло apt-get install --reinstall $(dpkg -S $(debsums -c) | cut -d : -f 1 | sort -u) из мануала по debsums

>тестил мемтестом вчерась - всё было в порядке

memtest'ом можно подтереться только. Инфа 100%.

[разуму ЛОРа] DDR память, подземный стук

Для таких вещей есть ключ для дебага. И gdb. И ещё strace.

А ещё подумай о том, что повреждение может быть в какой-то либе, которую он загружает.