413
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
412
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
411
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
410
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
409
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
408
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
407
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
406
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
405
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
404
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
403
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
402
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
401
|
|
Fix bug in buffer module
While running under strace noticed strange readv()/writev() calls:
readv(5, [{iov_base="\0\0\0"..., iov_len=4096}, {iov_base="\0\0\0"..., iov_len=0}], 2) = 4096 writev(6, [{iov_base="\0\0\0"..., iov_len=4096}, {iov_base="\0\0\0"..., iov_len=0}], 2) = 4096
A second entry would be setup in the iov when filling an empty buffer or emptying a full buffer. This was due to edge case handling in setup_read_iov() and setup_write_iov() in buffer module. Fixed this edge case handling and added asserts to these functions to detect any similar defects. It doesn't appear this bug manifested any problems since the second zero length read or write appears to have been ignored.
|
Dustin Lundquist |
6 years ago
|
|
|
400
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
399
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
398
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
397
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
396
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
395
|
|
|
Dustin Lundquist |
6 years ago
|
|
|
394
|
|
|
Dustin Lundquist |
6 years ago
|
|
|