From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Sergey Stepanov To: =?koi8-r?Q?=CB=D5=CC=D8=D4=D5=D2=CE=D9=CA=20=CF=C6=D4=CF=D0=C9=CB?= Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: unknown via proxy [66.36.240.43] Date: Mon, 22 May 2006 21:12:38 +0400 In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Subject: Re: [room] =?koi8-r?b?b2JqZHVtcC0gxMnawdPTxc3CzMnSz9fBzsnFICwg09TS?= =?koi8-r?b?wc7O2cUgY2FsbC0gy8/O09TS1cvDyck=?= X-BeenThere: smoke-room@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: Sergey Stepanov , =?koi8-r?b?y9XM2NTV0s7ZyiDPxtTP0MnL?= List-Id: =?koi8-r?b?y9XM2NTV0s7ZyiDPxtTP0MnL?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2006 17:12:39 -0000 Archived-At: List-Archive: > > > Эта штука вылетает с Segmentation Fault на середине > > > дизассемблирования крупных o-файлов. Причем > > > запустив под gdb, вижу, что вылетает на функции strlen(), > > > библиотеки /lib/libc.so.6 > > > Что теперь делать - незнаю.. > > > Вот уткнулся в такую бяку. Кто чем может помоч? > > Посмотрите в сторону ndisasm из пакета nasm. > Ок, гляну. Надеюсь в ALTMaster2.4 он есть в репозитарии. Мда, посмотрел nasm - он еще более убогий чем objdump. Его назначение - тупо преобразовывать байт-код в ассемблерные инструкции. Большего он не умеет. Он не понимает хедеры *.o и ELF файлов, в общем как инструмент подходит только для элементарных действий. > ЗЫЖ Всеже obj2asm - харошая вещщ. Вот только не пойму, > кто в сегфолте виноват - obj2asm или libc.so.6? Помню, > были какие-то ugly-баги в str функциях, может это они > вылазиют? Это можно как-то пофиксить? Кароче, народ, рассказываю как поборол Segmentation Fault. Можно взять на заметку и использовать в таких критичных случаях, когда нужно запустить бинарник, в котором есть ошибка доступа к памяти. :) Что я сделал - запустил декомпиляцию под valgrind, в надежде посмотреть, что конкретно вызывает Segmentation Fault. Valgrind запускал с опциями --tool=memcheck и --suppressions=file.supp, где file.supp - это файл, в котором собран текст всех *.supp файлов из дистрибутива valgrind. Эта опция, согласно документации, просто подавляет вывод рапорта о обнаруженных ошибках. Но каково было мое удивление, когда декомпиляция прошла без ошибки! Самое интересное, что valgrind не выдал ни одного сообщения о неправильном обращении к памяти. Я так подозреваю что опция --suppressions не просто подавляет рапорт об ошибке, но и позволяет программе продолжить выполнение при возникновении ошибки! Во как. А может быть, просто распределение памяти декомпилятора при запуске под valgrind оказалось таким, что программа сработала без ошибок памяти. В любом случае, результат использования valgrind в качестве "багфиксера" меня удивил. Со всяческими пожеланиями, Сергей. http://xi.net.ru