>>> собственно 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;
> в принципе реферер для бэкенда не сильно критичен. попробую погонять без него.

больше суток прошло. корок больше не было.
значит в этом дело было.



_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru