your mail
Andrew
all at inbox.ru
Thu Jan 15 23:05:40 MSK 2009
Wednesday, January 14, 2009, 11:09:26 AM, you wrote:
IS> On Tue, Jan 13, 2009 at 11:06:41PM +0300, Andrew wrote:
>> > On Mon, Jan 12, 2009 at 08:43:10PM +0100, Andrew wrote:
>> >
>> > > Monday, January 12, 2009, 3:04:18 PM, you wrote:
>> > > IS> On Mon, Jan 12, 2009 at 03:38:42PM +0300, Igor Sysoev wrote:
>> > >
>> > > >> On Mon, Jan 12, 2009 at 01:30:54PM +0100, Andrew wrote:
>> > > >>
>> > > >> >
>> > > >> > > Если из вашего модуля, то скорее всего ошибка именно там.
>> > > >> >
>> > > >> > Показывает, что из моего модуля. Но ошибка, по которой произошло
>> > > >> > падение, подозрительно глубоко в ngx_slab_alloc_pages. Маловероятно,
>> > > >> > что мой модуль обнулил только кусочек структуры ngx_slab_page_t, а
>> > > >> > именно page->next = null.
>> > > >>
>> > > >> А какой размер зоны используется в своём модуле ?
>> > >
>> > > Если page->>slab:
>> > >
>> > > IS> (gdb) p* page
>> > > IS> $3 = {slab = 1095216660489, next = 0x0, prev = 46912546242592}
>> > >
>> > > IS> верный, то зона должна быть 1020G, что не похоже на правду.
>> > >
>> > > IS> Остаётся предположить, что чей-то код записал в начало ngx_slab_page_t,
>> > > IS> то есть, в slab и next "09 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00".
>> > >
>> > > А значение prev похоже на правду?
>> > >
>> > > Если посмотреть кусок памяти до ngx_slab_page_t и после,
>> > > то видно что там куча повторяющихся значений. Кажется маловероятным, что
>> > > свой модуль записал какие-то данные в начало ngx_slab_page_t, и они
>> > > оказались точно такими же как и данные, которые он не перезаписывал.
>> > >
>> > > (gdb) p page
>> > > $116 = (ngx_slab_page_t *) 0x2aaaadf4f440
>> > > (gdb) x/128d page-2
>> > > 0x2aaaadf4f410: 9 0 0 0 -1 0 0 0
>> > > 0x2aaaadf4f418: 0 0 0 0 0 0 0 0
>> > > 0x2aaaadf4f420: 1 0 0 0 0 0 0 0
>> > > 0x2aaaadf4f428: 1 0 0 0 0 0 0 0
>> > > 0x2aaaadf4f430: 80 -97 -12 -83 -86 42 0 0
>> > > 0x2aaaadf4f438: -16 -44 -12 -83 -86 42 0 0
>> > > 0x2aaaadf4f440: 9 0 0 0 -1 0 0 0
>> > > 0x2aaaadf4f448: 0 0 0 0 0 0 0 0
>> > > 0x2aaaadf4f450: 32 -128 -89 -83 -86 42 0 0
>> > > 0x2aaaadf4f458: 8 0 0 0 -1 0 0 0
>> > > 0x2aaaadf4f460: 0 0 0 0 0 0 0 0
>> > > 0x2aaaadf4f468: 32 -128 -89 -83 -86 42 0 0
>> > > 0x2aaaadf4f470: 9 0 0 0 -1 0 0 0
>> > > 0x2aaaadf4f478: 0 0 0 0 0 0 0 0
>> > > 0x2aaaadf4f480: 1 0 0 0 0 0 0 0
>> > > 0x2aaaadf4f488: 9 0 0 0 -1 0 0 0
>> >
>> > Можно сделать
>> >
>> > p/x *pool
>> > x/128x page-2
>> >
>> > ?
>>
>> Игорь, появилась ли какая-нибудь информация? Например, Вы посмотрели и точно уверены что с аллокатором все нормально или наоборот.
IS> Это больше похоже на проблемы с аллокатором.
Сегодня опять упал на том же самом месте.
0x000000000040ae1c in ngx_slab_alloc_pages (pool=0x2aaaada78000, pages=1) at src/core/ngx_slab.c:655
Может быть есть какие-то советы, как можно отловить причину?
(gdb) p/x *pool
$10 = {lock = 0x3bfc, min_size = 0x8, min_shift = 0x3, pages = 0x2aaaada78128, free = {slab = 0x0, next = 0x2aaaadf512d0,
prev = 0x2aaaadf52ce0}, start = 0x2aaaafbf4000, end = 0x2aac14e78000, mutex = {lock = 0x2aaaada78000}}
(gdb) p page
$11 = (ngx_slab_page_t *) 0x2aaaadf512b8
(gdb) x/128x page-2
0x2aaaadf51288: 0x00000007 0xffffffff 0x00000000 0x00000000
0x2aaaadf51298: 0x00000001 0x00000000 0x00000009 0x000000ff
0x2aaaadf512a8: 0x00000000 0x00000000 0x00000001 0x00000000
0x2aaaadf512b8: 0x00000009 0x000000ff 0x00000000 0x00000000
0x2aaaadf512c8: 0xada78020 0x00002aaa 0x00000008 0x000000ff
0x2aaaadf512d8: 0x00000000 0x00000000 0xada78020 0x00002aaa
0x2aaaadf512e8: 0x00000009 0x000000ff 0x00000000 0x00000000
0x2aaaadf512f8: 0x00000001 0x00000000 0x00000001 0x00000000
0x2aaaadf51308: 0xadf4fe30 0x00002aaa 0xadf529c8 0x00002aaa
0x2aaaadf51318: 0x00000009 0x000000ff 0x00000000 0x00000000
0x2aaaadf51328: 0x00000001 0x00000000 0x00000009 0x000000ff
0x2aaaadf51338: 0x00000000 0x00000000 0x00000001 0x00000000
0x2aaaadf51348: 0x00000009 0x000000ff 0x00000000 0x00000000
0x2aaaadf51358: 0x00000001 0x00000000 0x00000009 0x000000ff
0x2aaaadf51368: 0x00000000 0x00000000 0x00000001 0x00000000
0x2aaaadf51378: 0x00000007 0xffffffff 0x00000000 0x00000000
0x2aaaadf51388: 0x00000001 0x00000000 0x00000009 0x000000ff
0x2aaaadf51398: 0x00000000 0x00000000 0x00000001 0x00000000
0x2aaaadf513a8: 0x00000009 0x000000ff 0x00000000 0x00000000
0x2aaaadf513b8: 0x00000001 0x00000000 0x00000009 0x000000ff
0x2aaaadf513c8: 0x00000000 0x00000000 0x00000001 0x00000000
0x2aaaadf513d8: 0x00000001 0x00000000 0xadf4dfd0 0x00002aaa
0x2aaaadf513e8: 0xadf51ff0 0x00002aaa 0x00000009 0x000000ff
0x2aaaadf513f8: 0x00000000 0x00000000 0x00000001 0x00000000
0x2aaaadf51408: 0xffffffff 0xffffffff 0x00000000 0x00000000
0x2aaaadf51418: 0x00000002 0x00000000 0x00000007 0xffffffff
0x2aaaadf51428: 0x00000000 0x00000000 0x00000001 0x00000000
0x2aaaadf51438: 0x00000009 0x000000ff 0x00000000 0x00000000
0x2aaaadf51448: 0x00000001 0x00000000 0x00000009 0x000000ff
0x2aaaadf51458: 0x00000000 0x00000000 0x00000001 0x00000000
0x2aaaadf51468: 0x00000009 0x000000ff 0x00000000 0x00000000
0x2aaaadf51478: 0x00000001 0x00000000 0x00000001 0x00000000
More information about the nginx-ru
mailing list