search for: log_exit

Rsync 2.5.5; transfer via ssh; sparc-sun-solaris2.5 (Ultra 1); gcc 2.8.1. Every time rsync on this box causes boundary violation. I attached two strange examples. I have a few rsync's corefiles (100MB and above) and I can examine them. I will be grateful for any help. -Mirek <-------------------------------------------------------------------------> received 966761 names done

-----BEGIN PGP SIGNED MESSAGE----- I added the following code to log_exit(): void log_exit(int code, const char *file, int line) { static int error_count=0; if(error_count++ > 10) { abort(); } To force it to bail earlier instead of overflowing the stack. As you can see at frame #50, it is trying to log that the connection...

...out of disk quota at that point, so they might be bigger (and the gdb trace falling off suggests that they are). It does not occur on every run, but pretty close. It looks like it is has gotten into a loop trying to report an error, and we eventually blow the stack. I will attempt to put code into log_exit() to abort sooner, and see if I can find the root cause. The client is: bash-2.05$ rsync --version rsync version 2.5.5 protocol version 26 Copyright (C) 1996-2002 by Andrew Tridgell and others <http://rsync.samba.org/> Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfil...

...0x280fdfe1 in fprintf () from /usr/lib/libc.so.4 #2 0x281002b6 in vfprintf () from /usr/lib/libc.so.4 #3 0x280c98be in vsnprintf () from /usr/lib/libc.so.4 #4 0x80522f5 in rprintf (code=FERROR, format=0x8069920 "rsync error: %s (code %d) at %s(% d)\n") at log.c:295 #5 0x8052944 in log_exit (code=13, file=0x8069799 "log.c", line=279) at log.c:564 #6 0x804c655 in _exit_cleanup (code=13, file=0x8069799 "log.c", line=279) at cleanup.c:87 #7 0x80522a8 in rwrite (code=FERROR, buf=0xbbc00888 "rsync error: errors with program diagnostics (code 13) a...

in ocfs2_file_aio_write(), log_exit() could don't log the value which is really returned. this patch fixes it. Signed-off-by: Wengang Wang <wen.gang.wang at oracle.com> --- fs/ocfs2/file.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index 62442e4..a49fa44 1...

(problem encountered on Tru64Unix v4.0f with rsync 2.5.5) A failure to write to stdout or stderr in rwrite (log.c:279) will trigger an endless loop as follows: 0 rprintf calls rwrite 1 rwrite calls fwrite 2 fwrite fails 3 rwrite calls _exit_cleanup 4 _exit_cleanup calls log_exit 5 log_exit calls rprintf 6 rprintf calls rwrite 7 rwrite calls fwrite 8 fwrite fails (unknown errno) 9 rwrite calls _exit_cleanup continue from 4-9 ad infinitum until stack overflow and core dump. In my case, t...

...eport the failed write: #0 0x420503ac in vfprintf () from /lib/i686/libc.so.6 #1 0x42072f74 in vsnprintf () from /lib/i686/libc.so.6 #2 0x08052ca4 in rprintf (code=FERROR, format=0x8068a00 "rsync error: %s (code %d) at %s(%d)\n") at log.c:295 #3 0x080532b5 in log_exit (code=13, file=0x806878f "log.c", line=279) at log.c:564 #4 0x0804c9ad in _exit_cleanup (code=13, file=0x806878f "log.c", line=279) at cleanup.c:87 #5 0x08052c4e in rwrite (code=FERROR, buf=0xb1da4bf0 "rsync error: errors with program diag...

...sync source code, "Ignore SIGPIPE; we consistently check error codes and will see the EPIPE." The comment is wrong; it does *not* see the SIGPIPE. What happens is that as a result of the SIGPIPE, exit_cleanup gets called. That's a macro which calls _exit_cleanup. That calls log_exit That calls rwrite. Rwrite tries to write an error to stderr, but that fails because of (you guessed it!) SIGPIPE, and so rwrite calls exit_cleanup. Presto, an infinite loop is born. The most straightforward fix I came up with is to modify rwrite so that it doesn't actually try to w...

...t_inode (struct inode *inode) -{ - ocfs_super *osb; - - LOG_SET_CONTEXT(PUT_INODE); - - LOG_ENTRY_ARGS ("(0x%p, i_ino=%llu)\n", inode, OCFS_I(inode)->ip_blkno); - LOG_TRACE_ARGS ("put_inode: count=%d\n", atomic_read(&inode->i_count)); - osb = OCFS_SB(inode->i_sb); - LOG_EXIT (); - - LOG_CLEAR_CONTEXT(); - return; -} /* ocfs_put_inode */ - - void ocfs_sync_blockdev(struct super_block *sb) { #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) Index: src/inode.h =================================================================== --- src/inode.h (revision 1426) +++ sr...

...rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(545) [Receiver=3.0.7]\n", len=92, is_utf8=0) at log.c:285 #7 0x000000000041ede5 in rprintf (code=FERROR, format=0x4471b0 "rsync error: %s (code %d) at %s(%d) [%s=%s]\n") at log.c:405 #8 0x000000000041eeec in log_exit (code=20, file=0x4446f5 "rsync.c", line=545) at log.c:836 #9 0x00000000004133f9 in _exit_cleanup (code=20, file=0x4446f5 "rsync.c", line=545) at cleanup.c:190 #10 0x000000000040ab62 in sig_int (val=<value optimized out>) at rsync.c:545 #11 <signal handler called&gt...

https://bugzilla.samba.org/show_bug.cgi?id=3271 Summary: Rsync instances stay in memory when using in daemon mode Product: rsync Version: 2.6.7 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy:

...(status)); + else if (WIFEXITED(status) && WEXITSTATUS(status) == RERR_CRASH) + rprintf(FLOG, + "rsync error: (1) *** Child proccess has crashed. :-( ***\n"); } #endif } @@ -1070,6 +1085,12 @@ } #endif +static RETSIGTYPE rsync_panic_handler2(UNUSED(int whatsig)) +{ + log_exit(RERR_CRASH, "main.c", -1); + logfile_close(); + _exit(RERR_CRASH); +} int main(int argc,char *argv[]) { @@ -1085,6 +1106,11 @@ signal(SIGFPE, rsync_panic_handler); signal(SIGABRT, rsync_panic_handler); signal(SIGBUS, rsync_panic_handler); +#else /* !def MAINTAINER_MODE */ + sign...

Hi everyone I'm still getting strange sizes on the daemon logs. After transferring around 1.66GB over 14 hours (256kbit link) to an absolutely empty directory, I get: 2007/01/26 04:13:43 [26441] sent 57014 bytes received 44708 bytes total size 1947222268 du reports the final size of the directory on the daemon side as 1.6 G, and the "received" bytes can't be 44708?! I know

...buf=0xbfecae88 "rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(260) [generator=2.6.8]\n", len=93) at log.c:272 #6 0x0805c935 in rprintf (code=4294966782, format=0x8088eec "rsync error: %s (code %d) at %s(%d) [%s=%s]\n") at log.c:385 #7 0x0805d86c in log_exit (code=20, file=0x8086ecb "rsync.c", line=260) at log.c:792 #8 0x08051e3d in _exit_cleanup (code=20, file=0x8086ecb "rsync.c", line=260) at cleanup.c:154 #9 0x0804b395 in sig_int (val=15) at rsync.c:260 #10 <signal handler called> #11 0x473ad402 in __kernel_vsyscall () #1...

As I reported a while back rsync doesn't handle metadata (permissions and ownership) in dryrun mode. I offered to make a patch and that offer still stands. I didn't have the time for it until now and want to pick it up again. I had some ugly hack back then but I want to redo it in a clean way. I would like some input on my thoughts. IMHO, it would be ideally if the check for dry_run

...fffbcf0 "rsync error: error in rsync protocol data stream (code 12) at io.c(635) [receiver=3.0.2]\n", len=-1073761120, is_utf8=0) at log.c:339 #6 0x080632fc in rprintf (code=FERROR, format=0x8083c20 "rsync error: %s (code %d) at %s(%d) [%s=%s]\n") at log.c:398 #7 0x08064107 in log_exit (code=12, file=0x80895e0 "io.c", line=134780384) at log.c:829 #8 0x08058b1d in _exit_cleanup (code=12, file=0x80895e0 "io.c", line=635) at cleanup.c:191 #9 0x08068cc1 in whine_about_eof (fd=134888740) at io.c:635 #10 0x08068f21 in read_timeout (fd=5, buf=0xbfffe984 "\036&...

...tf(FINFO,"_exit_cleanup(code=%d, file=%s, line=%d): entered\n", + code, file, line); + if (cleanup_child_pid != -1) { int status; if (waitpid(cleanup_child_pid, &status, WNOHANG) == cleanup_child_pid) { *************** *** 80,85 **** --- 85,94 ---- } if (code) log_exit(code, file, line); + + if (verbose > 2) + rprintf(FINFO,"_exit_cleanup(code=%d, file=%s, line=%d): about to call exit(%d)\n", + ocode, file, line, code); exit(code); } Index: clientserver.c =================================================================== RCS file: /c...