Damjan wrote
The problem is more general: consoles *also* break on short reads (Java 1.4.1's gdb takes 1 command then quits because it thinks it's the end of file)
Try my patch, it should help that case.
I'm sure short read != end of file for ordinary files either, especially in *nix where read() can easily be interrupted by a signal.
If you can come up with an example of a real app or even a test case that is currently broken, I'll gladly try to fix it. - Dan
On Feb 8, 2008 8:03 PM, Dan Kegel dank@kegel.com wrote:
Damjan wrote
The problem is more general: consoles *also* break on short reads (Java 1.4.1's gdb takes 1 command then quits because it thinks it's the end of file)
Try my patch, it should help that case.
It only helps if I change
+ if (type != FILE_TYPE_PIPE) {
to
+ if (type != FILE_TYPE_PIPE && type != FILE_TYPE_CHAR) {
I'm sure short read != end of file for ordinary files either, especially in *nix where read() can easily be interrupted by a signal.
If you can come up with an example of a real app or even a test case that is currently broken, I'll gladly try to fix it.
Well, if the MSDN is correct about ReadFile() returning only when the requested number of bytes is read unless an error occurs (it's a big if :-), then it would be an NTDLL NtReadFile() issue where pread() returns too soon due to a signal. But I haven't been able to get a signal to interrupt pread() in my tests, maybe wine handles signals.
- Dan
Thank you Damjan
On Feb 9, 2008 2:15 AM, Damjan Jovanovic damjan.jov@gmail.com wrote:
Try my patch, it should help that case.
It only helps if I change
if (type != FILE_TYPE_PIPE) {to
if (type != FILE_TYPE_PIPE && type != FILE_TYPE_CHAR) {
That makes me as uneasy as I bet it does you; switching to detecting EOF by noticing zero byte reads as you suggested sounds safer. Try the attached patch and let me know what you think.
Well, if the MSDN is correct about ReadFile() returning only when the requested number of bytes is read unless an error occurs (it's a big if :-), then it would be an NTDLL NtReadFile() issue where pread() returns too soon due to a signal. But I haven't been able to get a signal to interrupt pread() in my tests, maybe wine handles signals.
Wine's ReadFile already tries to handle interrupted reads, but it looks offhand like it only handles the case where the read is interrupted before getting any bytes. Wine uses signals internally, maybe a stress test that tickled that part of wine heavily while doing lots of extremely large ReadFile() calls would cause a partial read. But it's possible that no apps would care, especially if we get rid of the "short read = EOF" bug you pointed out in msvcrt. - Dan
On Feb 9, 2008 5:27 PM, Dan Kegel dank@kegel.com wrote:
On Feb 9, 2008 2:15 AM, Damjan Jovanovic damjan.jov@gmail.com wrote:
Try my patch, it should help that case.
It only helps if I change
if (type != FILE_TYPE_PIPE) {to
if (type != FILE_TYPE_PIPE && type != FILE_TYPE_CHAR) {That makes me as uneasy as I bet it does you; switching to detecting EOF by noticing zero byte reads as you suggested sounds safer. Try the attached patch and let me know what you think.
It works with jdb, and all msvcrt tests still pass. I was trying the same thing a while back, but some tests always kept failing, so well done!
Well, if the MSDN is correct about ReadFile() returning only when the requested number of bytes is read unless an error occurs (it's a big if :-), then it would be an NTDLL NtReadFile() issue where pread() returns too soon due to a signal. But I haven't been able to get a signal to interrupt pread() in my tests, maybe wine handles signals.
Wine's ReadFile already tries to handle interrupted reads, but it looks offhand like it only handles the case where the read is interrupted before getting any bytes. Wine uses signals internally, maybe a stress test that tickled that part of wine heavily while doing lots of extremely large ReadFile() calls would cause a partial read. But it's possible that no apps would care, especially if we get rid of the "short read = EOF" bug you pointed out in msvcrt.
- Dan
Thank you Damjan
-
Damjan Jovanovic -
Dan Kegel