ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: your mail



> 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
> 
> ?
> 
> 
> -- 
> Игорь Сысоев
> http://sysoev.ru
> 


Игорь, появилась ли какая-нибудь информация? Например, Вы посмотрели и точно 
уверены что с аллокатором все нормально или наоборот.



  • References:
    • Re:
      • From: Igor Sysoev

 




Copyright © Lexa Software, 1996-2009.