Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.6.7

Bug #18618 Incorrect CHUNK_SIZE
Submitted: 2011-06-20 21:19 UTC
From: gauthierm Assigned: gauthierm
Status: Closed Package: Crypt_GPG (version SVN)
PHP Version: Irrelevant OS: BSD/Linux
Roadmaps: (Not assigned)    
Comments Add Comment Add patch

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 11 + 30 = ?

 [2011-06-20 21:19 UTC] gauthierm (Michael Gauthier)
Description: ------------ "POSIX.1-2001 says that write(2)s of less than PIPE_BUF bytes must be atomic: the output data is written to the pipe as a contiguous sequence. Writes of more than PIPE_BUF bytes may be non-atomic: the kernel may interleave the data with data written by other processes." Most operating systems have PIPE_BUF as 4096 bytes. Setting CHUNK_SIZE to 8192 may cause php to do two 4k writes which can cause Crypt_GPG to hang forever. It hangs because $fdInput is returned as writable by stream_select(), the first 4k write succeeds (fully or partially) but because php will try to write the next 4k chunk it hangs as the fd is full and hasn't beed re-selected to test if it can be written. The other option is to set all file descriptors as non-blocking using stream_set_blocking(), the code correctly increments the buffers for the actual amount written/read. This will also fix bug 18526


 [2011-06-20 21:20 UTC] gauthierm (Michael Gauthier)
-: +: andy at fud dot org dot nz -Assigned To: +Assigned To: gauthierm
 [2011-06-20 21:24 UTC] gauthierm (Michael Gauthier)
Andy, thanks for your detailed report. When developing the file streaming operations for Crypt_GPG I tested a lot using strace to see what the buffer size used by PHP is. It seems PHP always reads in 8k chunks no matter what chunk size you specify. If you specify 4k chunks, PHP reads one 8k chunk and the next read comes from an internal buffer in PHP. Of course, this may be different for writes. Your description certainly sounds correct and I will have to do more testing to verify PHP itself works properly.
 [2011-06-20 21:27 UTC] gauthierm (Michael Gauthier)
Bug #18526 is a duplicate of this issue.
 [2011-09-12 11:06 UTC] gauthierm (Michael Gauthier)
-Status: Assigned +Status: Closed
Fixed in SVN in I will do a release this week. Out of curiosity, on what OS, kernel version and PHP version are you experiencing the issue? I was unable to reproduce it on Ubuntu Linux using a chunk size of 8192. Using higher-chunk sizes reproduced the issue so I was able to test it. In the end, I left the chunk size at 8192. PHP does some internal buffering of the streams and uses 8192 as its chunk size. Using larger chunks made things considerably slower. The delay mechanism included in the commit gives a nice speed boost though :) Thanks again for your bug report!
 [2011-09-13 00:54 UTC] gauthierm (Michael Gauthier)
Ok, I tested on FreeBSD 8.2 on a VM and easily reproduced the issue. Setting the chunk size to 4096 prevented hanging but was extremely slow. After the fix from SVN r316510, the 8192 chunk size works and the speed is excellent.