DO NOT REPLY [Bug 3382] New: hang in read() in exclude.test of
testsuite
bugzilla-daemon at dp3.samba.org
bugzilla-daemon at dp3.samba.org
Fri Jan 6 21:23:38 GMT 2006
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 at samba.org
ReportedBy: enchanter at users.sourceforge.net
QAContact: rsync-qa at 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.
More information about the rsync
mailing list