Maxim Dounin
March 06, 2014 09:38AM
Hello!

On Thu, Mar 06, 2014 at 06:04:06PM +0400, Maxim Dounin wrote:

> Hello!
>
> On Thu, Mar 06, 2014 at 05:39:16AM -0500, ddr400 wrote:
>
> > Судя по tcpdump страница отдается полностью http://pastebin.com/ZDkWPtdv
> >
> > а в терминале curl останавливается на таком
> >
> > </div>
> > <div class="span4">
> >
> > 71b
> > <section class="b-yellow-box">
> > * Received problem 3 in the chunky parser
> > * Closing connection #0
> > curl: (56) Received problem 3 in the chunky parser
> > <div class="b-yellow-box
>
> Взгляд глазами позволяет предположить, что ответ, возможно,
> повреждён где-то тут (начала chunk'а, ближе к концу которого curl
> ругается):
>
> <section class="b-layout b-layout_main">
> <div class="g-layout">
>
> 3e
> <!-- ............ ...... .................. .............. -->
> 3e
> <!-- ............ ...... .................. .............. -->
> 3057
> op7-for-main">
> <div class="span4">
> <div class="first-item">
> <a href="/news/2014/03/06/crimea/" class="js-dh"><img alt="............ .................. ...................." class="g-
>
> Говорить о чём либо однозначно - сложно, т.к. и вывод
> tcpdump'а, и debug log явно обрабатывались руками, и строки там
> как минимум местами двояться, не говоря уже про наивные попытки
> замены доменов. Но судя по всему этому соответствует вот этот
> кусок debug log'а:
>
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http chunk: 12586
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 000000000158B970, pos 000000000158B970, size: 4 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 000000000155BF60, pos 000000000155D42E, size: 66 file: 418, size: 30734
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 000000000158BA78, pos 00000000004920FD, size: 2 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 000000000158BAB0, pos 000000000158BAB0, size: 4 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 0000000000000000, pos 0000000000000000, size: 0 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 0000000001522CA8, pos 0000000001522CA8, size: 62 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 00000000013C3F90, pos 00000000004920FD, size: 2 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 00000000013C3E58, pos 00000000013C3E58, size: 4 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 0000000001522CA8, pos 0000000001522CA8, size: 62 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 0000000001522E48, pos 00000000004920FD, size: 2 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write new buf t:1 f:0 000000000158BB68, pos 000000000158BB68, size: 6 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write new buf t:1 f:1 000000000155BF60, pos 000000000155D4AB, size: 12586 file: 5869, size: 12586
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write new buf t:0 f:0 0000000000000000, pos 00000000004920FD, size: 2 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http write filter: l:0 f:0 s:12802
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http write filter limit 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 writev: 214
> 2014/03/06 09:56:08 [debug] 2251#0: *20 sendfile: @5931 12524
> 2014/03/06 09:56:08 [debug] 2251#0: *20 sendfile: 12524, @5931 12524:12524
> 2014/03/06 09:56:08 [debug] 2251#0: *20 writev: 2
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http write filter 0000000000000000
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http postpone filter wake "/includes/lists/last24?"
>
> По каким-то непонятным причинам sendfile'у предлагается послать
> 12524 вместо обозначенных в буфере 12586. Разница в 62 байта
> подозрительно похожа на размеры некоторых предыдущих буферов, и
> как бы намекает на ошибку в работе с sendfile'ом на linux'е в случаях,
> когда работа с файлами сильно перемешенана с буферами в памяти.
>
> Попробуйте выключить sendfile, должно помочь.

Впрочем нет, более подробное изучение вопроса позволяет
предположить, что всё-таки проблема где-то раньше, т.к. offset
посылаемых данных также сдвигается.

Такое ощущение, что по каким-то причинам в цепочке буферов для
вывода обоих блоков ssi stub использован один и тот же буфер.

Это очень странно, т.к. код честно проверяет, не использовался ли
уже этот блок, и в случае необходимости аллоцирует новые буфера, и
соответственно должны быть разные буфера, ссылающие на одну и ту
же память.

Что говорит nginx -V, нет ли каких-либо локальных изменений в коде?

--
Maxim Dounin
http://nginx.org/

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

Проблема с curl, proxy_cache и Content-Lenght

ddr400 March 05, 2014 07:44AM

Re: Проблема с curl, proxy cache и Content-Lenght

Maxim Dounin March 05, 2014 08:56AM

Re: Проблема с curl, proxy cache и Content-Lenght

ddr400 March 06, 2014 01:42AM

Re: Проблема с curl, proxy cache и Content-Lenght

Maxim Dounin March 06, 2014 05:08AM

Re: Проблема с curl, proxy cache и Content-Lenght

ddr400 March 06, 2014 05:39AM

Re: Проблема с curl, proxy cache и Content-Lenght

Maxim Dounin March 06, 2014 09:06AM

Re: Проблема с curl, proxy cache и Content-Lenght

Maxim Dounin March 06, 2014 09:38AM

Re: Проблема с curl, proxy cache и Content-Lenght

ddr400 March 06, 2014 11:44AM

Re: Проблема с curl, proxy cache и Content-Lenght

Maxim Dounin March 06, 2014 12:08PM

Re: Проблема с curl, proxy cache и Content-Lenght

Artem Suvorov July 08, 2016 09:42AM

Re: Проблема с curl, proxy cache и Content-Lenght

Валентин Бартенев July 08, 2016 09:48AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 189
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready