дамп ядра от умирающего многопоточного процесса - PullRequest
Новая
       30

дамп ядра от умирающего многопоточного процесса

1 голос
/ 15 февраля 2011

Мое многопоточное приложение (C ++, SunOS) динамически связано с общими библиотеками.В программе несколько потоков, некоторые из них из библиотек.Один из таких потоков вызывает exit () , и это приводит к генерации дампов ядра из другого потока в общей библиотеке: 

(dbx) where
  [1] 0x0(0xbeee0b30, 0x0, 0x0, 0x1c00, 0x1, 0xbeee0b50), at 0x0
  [2] STLCollectionWrapper<std::vector<SM_Timer*,std::allocator<SM_Timer*> > >::empty(0xbeee0b30, 0x0, 0x0, 0x1c00, 0xbca12200, 0x0), at 0xbee04690
  [3] GenPtrSortVec<SM_Timer,std::less<SM_Timer>,std::allocator<SM_Timer> >::isEmpty(0xbeee0b30, 0x0, 0x0, 0x0, 0x4fb0e0, 0xbd436b90), at 0xbee04424
  [4] sm_tmr_process(0x341000, 0x8e400, 0xbeeba00f, 0x1c00, 0x1, 0xbeee0800), at 0xbee03968
  [5] sm_nm_process_timeouts(0xbc67bf94, 0xbc67bf98, 0xbd4c3800, 0x0, 0xbca12200, 0xbee830f0), at 0xbee813dc
  [6] TimerThreadObject::poll(0x0, 0xbc67c000, 0x0, 0x0, 0xbedf1530, 0x1), at 0xbedf15f4
(dbx) thread
current thread ($thread) is t@null
(dbx) lwps
  l@1 LWP suspended in __SLIP.FINAL__A()
  l@3 LWP suspended in find_composition_start()
o>l@6 signal SIGSEGV in 0x0()

Кадры стека 6-4 взяты из libA, кадры 3-2 из libB.Кадр 1 должен быть вызван из стандартной библиотеки C ++ (/usr/lib/libCstd.so.1?).Как видите, этот вызов не удался.

В кадре 4 код вызвал метод isEmpty () глобального объекта типа GenPtrSortVec.Этот объект находится в стеке того же модуля, где определен метод sm_tmr_process ().Позже в кадре 2 код вызвал метод empty () векторного объекта STL.Этот вектор является полем класса GenPtrSortVec.

У меня есть следующие вопросы относительно этой проблемы:

  1. Почему первый кадр имеет адрес 0x0?

  2. Возможно ли, что libCstd был выгружен из процесса умирания до отмены всех потоков в программе?Обратите внимание, что libCstd был автоматически загружен в процесс как динамическая зависимость.

И еще два вопроса о выходе из процесса:

  1. Является ли этоВозможно ли, что автоматически загруженные разделяемые библиотеки были автоматически выгружены до отмены всех потоков и уничтожения глобальных / статических объектов?

  2. Возможно ли, что глобальные или статические объекты были уничтожены до отмены всехтемы?

Ответы [ 2 ]

2 голосов
/ 15 февраля 2011

1.1 - возможно, вызов нулевого указателя (см. Йорген)

1,2 - нет

2,1 - нет

2,2 - возможно

1.2 / 2.1: Общие библиотеки загружаются при загрузке программы в память. Динамический компоновщик затем просканирует все внешние ссылки и исправит их. Это процесс динамического связывания. Это не будет отменено, то есть никакая библиотека, загруженная таким образом, не будет выгружена ОС. Весь образ процесса удаляется после завершения программы.

2.2 - это зависит от вашего приложения. Инициализация глобальных / общих объектов может быть проблематичной - смотрите фиаско статической инициализации. То же самое относится и к уничтожению. Порядок в обоих случаях определяется реализацией.

1 голос
/ 15 февраля 2011

Ответ на 1: Вы, вероятно, вызвали нулевой указатель на функцию. Возможно не напрямую, а косвенно. Не могли бы вы переписать vtable объекта с нулями и затем вызвать его виртуальные методы?

...