LINUX.ORG.RU
Форум — Development  

pstack и core


0

0

Хочется уметь по наступлению некоторого события получать распечатку стека некоторого процесса. Система FC4. Процесс многонитевой, поэтому pstack неработоспособен (он не понимает NPTL).

Как решать задачу? Не приходилось ли кому-нибудь писать скрипт для решения этой задачи с помощью gdb?

Как проще всего получить файл core, не прерывая выполнения процесса?

anonymous

если не останавливая - то никак.

а вообще: 1)останавливаем, например сигналом

2)делаем корку

3)запускаем

PS: если останавливать сигналом то надо останавливать каждый тред в отдельности

cvv ★★★★★
()
Ответ на: комментарий от cvv

> если не останавливая - то никак.

Я так понимаю, что дальнейшие текст отвечает на вопрос о том, как получить файл core, не прерывая выполнения процесса.

> 1)останавливаем, например сигналом

этот пункт более-менее понятен.

> 2)делаем корку

как??

> 3)запускаем

этот пункт более-менее понятен.

> PS: если останавливать сигналом то надо останавливать каждый тред в отдельности

Почему? Я считал, что такой подход к доставке сигналов является особенностью linux threads, и в POSIX (и в NPTL) оно по-другому. Я заблуждаюсь? Ulrich Drepper http://people.redhat.com/~drepper/posix-signal-model.xml тоже заблуждается?

На самом деле, если останавливать все нити по очереди, то ценность полученной таким образом информации крайне сомнительна, поскольку мы получим стеки разных нитей по состоянию на разные моменты времени.

В Solaris, помнится, этому было посвящено много усилий - сначала все нити замораживают, а уже потом снимают с них стек. Какова в этом смысле ситуация под Linux? Как работает gdb, когда после attach я говорю bt интересующим меня нитям - можно ли быть уверенным в консистентности информации, и, если да, то каким путем эта консистентность достигается?

anonymous
()
Ответ на: комментарий от anonymous

> В Solaris, помнится, этому было посвящено много усилий - сначала все
> нити замораживают, а уже потом снимают с них стек.
>

Ну да, я помню останавливал процесс по SIGSTOP (извне или он сам
себя останавливал) и смотрел стек с помощью pstack (на Solaris).

Onanim ★
()
Ответ на: комментарий от Onanim

>Хорошо подумал?

Если бы cvv подумал, то 1. Он бы не был cvv. 2. Это было бы плохо для развития дискуссии: глядишь, кто-нибудь посмотрит, что он написал, и расскажет что-нибудь умное и толковое.

Так держать!

anonymous
()
Ответ на: комментарий от anonymous

>> PS: если останавливать сигналом то надо останавливать каждый тред в отдельности

>Почему? Я считал, что такой подход к доставке сигналов является особенностью linux threads, и в POSIX (и в NPTL) оно по-другому. Я заблуждаюсь? Ulrich Drepper http://people.redhat.com/~drepper/posix-signal-model.xml тоже заблуждается?

нет заблудился я. я почемуто считал что все сигналы обрабатываются однообразно.

cvv ★★★★★
()
Ответ на: комментарий от anonymous

насколько я знаю то альтернатив ptrace(PTRACE_GETREGS)/ptrace(PTRACE_PEEKDATA) не разгонишся.

как потом разгрести полученный дамп памяти - не знаю.

ЗЫ: NTPL в живую не трогал. только теоретически

cvv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development