worker process 7035 exited on signal 11 (core dumped)

[Igor Sysoev]

On Wed, Aug 29, 2007 at 10:24:16AM +0400, Alexey Rymonin wrote:

> Hello Igor,
> 
> Wednesday, August 29, 2007, 12:59:46 AM, you wrote:
> 
> >> Я могу поставить на них nginx и запустить стрес тест на всех трех
> >> вресиях ядра... Сэмулировать нагрузку превышающую текущую, на мелких
> >> файлах, тостых файлах, нот фаундах, форбиденах и больших клиенских
> >> запросах (чтобы в буфер не влезал)... если эта ошибка ядра, то скорее всего рано или поздно
> >> она повториться...
> 
> > Это было бы интересно при включённом отладочном логе. Его можно вращать
> > раз в минуту.
> 
> Я так и сделаю... поскольку на отладочный лог было бы очень интересно
> посмотреть...
> Игорь... у меня на этом же сервере в качестве MTA стоит Exim, который
> под соляркой также юзает /dev/poll. И он работает без нареканий с тех пор как сервак
> запустили... Странно это, поскольку если бы это был баг ядра, он бы
> тоже должен бы писать хоть что-то....

Это зависит от того, как обрабатывать. Я, наверное, сделаю там проверку
на NULL и буду писать в лог о таких случаях.

> Игорь, у меня к вам еще два вопроса есть:
> 1) А методы работы с событием(сокетом) синхронизированные?
> Не может ли появиться событие на сокет пока идет код его удаления из
> пула, встать в очередь и сразуже по окончанию процедцры вернуться и
> вызвать падение? Это бы объясняло редкость возникновения баги....

В nginx'е передача событий в ядро делается пачками, ровно перед получением
пачки готовых событий. Но при закрытии сокета вся накопивашая пачка
сразу скидывается в /dev/poll, а потом закрывается сокет.

После удаления события из ядра оно не должно приходить.
Если же оно приходит, то это race condition в ядре.

> 2) Игорь, а что такое DP_ISPOLLED?
> http://docs.sun.com/app/docs/doc/816-5177/6mbbc4g9q?l=de&a=view

Способ узнать, зарегистрирован ли дескриптор в /dev/poll.
Для программ типа nginx'а его использование бессмысленно, так как nginx
ведёт собственный учёт. Скорее всего, он предназначен для библиотек,
когда проще сходить в ядро, перед тем, как добавить события, чем вести
собственный учёт.

Кстати, в вышеупомянутой проверке на NULL я буду вызывать DP_ISPOLLED,
чтобы проверить, дейстивтельно ядро считает, что дескрптор ещё присутствует
в /dev/poll, или же это фантомные события, оставшиеся после удаления.

> Ну а я пока соберу с дебагом, и будем ждать еще одну корку... я
> думаю что тогда станет уже совершенно понятно...
>
> > p *ngx_cycle->files[28]
> (dbx) p *ngx_cycle->files[28]
> dbx: reference through nil pointer

Это выглядит старнно в сочетании с предыдущим удалением:

(dbx) p change_list[0]
change_list[0] = {
    fd      = 28
    events  = 2048
    revents = 0
}

и приходом событий для этого удалённого дескриптора:

(dbx) p event_list[0]
event_list[0] = {
    fd      = 28
    events  = 1
    revents = 1
}

По идее nginx, должен быть уже упасть на 28.


-- 
Игорь Сысоев
http://sysoev.ru