core dumped

Domrachev Ivan domrachev.ivan на gmail.com
Ср Дек 22 16:59:01 MSK 2010


>>
>> >> собственно subj.
>> >> воспроизвести не получается, но он сам переодически выпадает.
>> > [...]
>> >> (gdb) fr 0
>> >> #0  0x000000000048098b in ngx_http_fastcgi_create_request (r=0x8015bd000) at src/http/modules/ngx_http_fastcgi_module.c:954
>> >> 954                     ch = header[i].key.data[n];
>> >> (gdb) p header[i]
>> >> $1 = {hash = 34378479760, key = {len = 34378480481, data = 0x0}, value = {len = 0, data = 0x8011df890 "\001\001"}, lowcase_key = 0x8011dfc60 "@-\035\001\b"}
>> >> 
>> >> дебаг логи имеются, но т.к. в них сессионники - сюда не выкладываю.
>> >> готов их отправить вместе с конфигами отдельно на мыло, если надо.
>> 
>> > Я правильно понимаю, что в конфиге используются fastcgi_param
>> > HTTP_...?  Проблема судя по всему в них, и по коду там всё
>> > плохо - как минимум выделяется недостаточно памяти под ignored 
>> > (там нужно либо выделять по количеству заголовков в запросе, либо 
>> > менять логику).
>> 
>> > Это напрямую не объясняет мусор в header[i], но в принципе снести 
>> > может всё что угодно.
>> 
>> спасибо.
>> да, в конфиге используется:
>> fastcgi_param HTTP_REFERER $http_referer;
>> в принципе реферер для бэкенда не сильно критичен. попробую погонять без него.

> По умолчанию все заголовки запроса и так передаются как HTTP_*.  
> Использовать fastcgi_param HTTP_... имеет смысл только тогда, когда 
> по каким-то причинам нужно переопределить то, что увидит в 
> качестве заголовков запроса fastcgi-приложение.

логично.
мы похоже перезапрограммировались.
спасибо за помощь.




Подробная информация о списке рассылки nginx-ru