# Кто запускает (и как отлаживать) процесс 'conftest'?

## init3

Некоторое время тому назад для ловли одного навязчивого таракана включил в системе запись core dump'ов.

Правильным согласно моим представлениям о здравом смысле образом (вопрос о дополнении соответствующего материала в wiki пока не ставлю), т.е. чтобы не искать дампы там, где они _могут_ быть, и где по идее их быть не должно — с записью _всех_ core в один каталог, и чтобы не делать лишних действий — с записью имени процесса и сигнала, коим он был убит в строку имени файла.

Баг был исправлен, но фича осталась, ибо хлеба не просит и вообще лень.

Жила-поживала фича (записи core) в моей системе, горя не знала, хлеба не просила.

Но стал я замечать, что временами при обновлении системы (и/или пересборке _некоторых_ пакетов в оном каталоге появляются файлы core dump'ов.

Например после отработки команды:

```
ebuild /usr/portage/gentoo/net-fs/samba/samba-3.6.23.ebuild configure
```

получается файл 

```
core_conftest-11.22302
```

А позже на этапе сборки самбы ещё один, но уже убитый SIGABRT.

Оно конечно совершенно некритично (сборка пакета завершается благополучно, а собранный пакет вполне работоспособен), но непорядок.

А способ промышления читаемой трассы (gdb) в данном случае не вполне понятен. Или я что-то упускаю?

----------

## TigerJr

Зря ты включил запись coredump. Если не занимаешься отладкой и не знаком с трассировкой gdb. 

Дурная голова ногам покоя не даёт. Вот и в твоём случае также. 

Дак ты ещё и наши ноги захотел помучить???

ЗЫ  [core-PIDNAME.PID] Это состояние оперативной памяти ID процесса. Если ты ни чего кроме ebuild не запускал тогда, он и был родительским процессом для conftest, другой вопрос кто передал процессу conftest сигнал SIGABRT (ядро или ebuild) нужно разбираться. Ты пробовал запустить conftest после сборки ebuild'a ?

ЗЫ2: Кстати для тебя данные в coredump скорее всего бесполезны, они нужны разработчикам для отладки, а не пользователям.

----------

