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