retitle 584344 speedy-cgi-perl: FTBFS: test failure on systems with a large socket write buffer size tag 584344 patch thanks
On Sun, Aug 15, 2010 at 09:45:42PM +0300, Niko Tyni wrote: > > On Thu, Jun 03, 2010 at 12:01:36PM +0200, Lucas Nussbaum wrote: > > > Source: speedy-cgi-perl > > > Version: 2.22-11 > > > Severity: serious > > > Tags: squeeze sid > > > User: debian...@lists.debian.org > > > Usertags: qa-ftbfs-20100602 qa-ftbfs > > > > > Justification: FTBFS on amd64 > > > > Test Summary Report > > > > ------------------- > > > > t/detach.t (Wstat: 0 Tests: 2 Failed: 1) > > > > Failed test: 2 > My best guess is that it's somehow related to bigger pipe buffers on > systems with more memory than mine or something like that, but I can't > see the problem in the code no matter how much I glare at it. Close enough, the thing that matters here is the socket write buffer size. The pipe buffers are always 64 kilobytes on Linux, that's hardcoded in the kernel source. The above test failure can be reproduced by setting the sysctl net.core.wmem_default to 470000 or so. (The default value on my system is 124928, and it most probably varies between systems depending on their available memory.) The first test in detach.t is basically checking that the persistent speedy backend can serve new requests after it's all done with the previous one, even if the frontend is still busy buffering the data to the client. The second test makes the buffer inside the frontend very small. When the client reads data in slowly, the backend will block on writes and doesn't get freed to handle a new request. However, when net.core.wmem_default is high enough, the data from the backend to the frontend will be buffered in the kernel and the backend can finish. This makes the second test fail. Increasing the amount of data sent from the backend fixes this when it becomes too much to fit in the kernel socket write buffer. The size of the 'large' buffer in detach.t also needs to be increased because the first test requires that all the data fit in it. I suppose the most correct thing to do here would be to check the size of the socket write buffer with SO_SNDBUF (see socket(7)) and set the data and frontend buffer size accordingly. However, I think I'll take the lazy route at least for squeeze and use my earlier patch that just hardcodes bigger numbers. Will revisit this decision in the future if necessary. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
