rsync - Jan 2006 - DO NOT REPLY [Bug 3382] New: hang in read() in exclude.test of testsuite

https://bugzilla.samba.org/show_bug.cgi?id=3382

           Summary: hang in read() in exclude.test of testsuite
           Product: rsync
           Version: 2.6.6
          Platform: Alpha
        OS/Version: OSF/1
            Status: NEW
          Severity: normal
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: enchanter@users.sourceforge.net
         QAContact: rsync-qa@samba.org


I just built rsync 2.6.6 on my Tru64 5.1B box, using the vendor C compiler. 
The build went fine and most of the testsuite passes (I'm running as myself,
so
a couple of the tests skip since they require root privs), but the exclude.test
hangs.

Using truss, I see that rsync is stuck in a tight read loop, calling read on fd
0 and getting back 0 bytes.

I attached to rsync with a debugger and stopped execution, and got this:

(ladebug) attach 198075 rsync
Reading symbolic information ...done
Attached to process id 198075  ....

Interrupt (for process)

Stopping process localhost:198075 (rsync).
stopped at [<opaque> __read(...) 0x3ff800d67d8] 

Information:  An <opaque> type was presented during execution of the
previous
command.  For complete type information on this symbol, recompilation of the
program will be necessary.  Consult the compiler man pages for details on
producing full symbol table information using the '-g' (and
'-gall' for cxx)
flags.

(ladebug) where
>0  0x3ff800d67d8 in __read(...) in /usr/shlib/libc.so
#1  0x3ff80177b20 in __read_nc(...) in /usr/shlib/libc.so
#2  0x3ff800da6d4 in __filbuf(...) in /usr/shlib/libc.so
#3  0x120023574 in parse_filter_file(listp=0x140000010, fname=Info: no
allocation applies for symbol fname at the current PC
<no value>, mflags=1024, xflags=1) "exclude.c":999
#4  0x120023140 in parse_rule(listp=0x140000010,
pattern=0x14000e3e7="",
mflags=0, xflags=0) "exclude.c":938
#5  0x120031140 in parse_arguments(argc=0x11fffbfd8, argv=0x11fffbfd0,
frommain=1) "options.c":749
#6  0x12002a878 in main(argc=9, argv=0x11fffc018) "main.c":1104
#7  0x1200187b8 in __start(...) in rsync

(ladebug) up
>1  0x3ff80177b20 in __read_nc(...) in /usr/shlib/libc.so
(ladebug) up
>2  0x3ff800da6d4 in __filbuf(...) in /usr/shlib/libc.so
(ladebug) up
>3  0x120023574 in parse_filter_file(listp=0x140000010, fname=Info: no
allocation applies for symbol fname at the current PC
<no value>, mflags=1024, xflags=1) "exclude.c":999
    999                         if ((ch = getc(fp)) == EOF) {
(ladebug) list $curline - 10 : 20
    989                         exit_cleanup(RERR_FILEIO);
    990                 }
    991                 return;
    992         }
    993         dirbuf[dirbuf_len] = '\0';
    994 
    995         while (1) {
    996                 char *s = line;
    997                 int ch, overflow = 0;
    998                 while (1) {
>   999                         if ((ch = getc(fp)) == EOF) {
   1000                                 if (ferror(fp) && errno ==
EINTR)
   1001                                         continue;
   1002                                 break;
   1003                         }
   1004                         if (word_split && isspace(ch))
   1005                                 break;
   1006                         if (eol_nulls? !ch : (ch == '\n' || ch
='\r'))
   1007                                 break;
   1008                         if (s < eob)
(ladebug) n
stopped at [void parse_filter_file(struct filter_list_struct*, const char*,
unsigned int, int):1000 0x1200235c4]        
   1000                                 if (ferror(fp) && errno ==
EINTR)
(ladebug) print fp
0x3ffc0080050
(ladebug) print errno
4
(ladebug) print line
"- /mid/for/foo/extra"



I checked errno.h, and "4" is indeed EINTR.  I think that the problem
may be
that clearerr() should be called before the continue -- otherwise there's
nothing that would ever clear out the error condition after it has happened
once.

I'm attaching a simple patch that fixes the problem.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3382





------- Comment #1 from enchanter@users.sourceforge.net  2006-01-06 14:46 MST
-------
Created an attachment (id=1652)
 --> (https://bugzilla.samba.org/attachment.cgi?id=1652&action=view)
clearerr() before trying getc() again, otherwise may loop indefinitely


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3382


wayned@samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #2 from wayned@samba.org  2006-01-06 15:20 MST -------
Thanks for the fix!  I've just checked this into CVS for the upcoming 2.6.7.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.