search for: __write_nocancel

Displaying 6 results from an estimated 6 matches for "__write_nocancel".

2012 Nov 14
1
Handling connection closes in (older) Sys::Virt
...distributions. The latest Perl bindings that can be installed from CPAN is thus 0.9.12 and it does not have support for close callbacks. Not only that, when a Perl program loses the (ssh) connection to libvirt, Perl just crashes: Program received signal SIGPIPE, Broken pipe. 0x00007ffff73de0d0 in __write_nocancel () from /lib/libpthread.so.0 Setting a?$SIG{PIPE} handler does not seem to help. Is there any possibility of a Perl program surviving and gracefully handling a closed libvirt connection with libvirt version 0.9.12 or older? Henrik
2007 Aug 02
4
Which rsync version?
Hi all. I once tried to rsync around 100 GB (10 million files), but version 2.6.6 needed too much RAM and was too slow. Is one of the snapshots stable enough to try this again? Greetings Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url :
2016 Jun 28
2
Fwd: rsync seem to be broken on sparc64
...r "exec-file" command. Reading symbols from /usr/bin/rsync...(no debugging symbols found)...done. (gdb) set args -a /export/test/* /export/test2 (gdb) run Starting program: /usr/bin/rsync -a /export/test/* /export/test2 Program received signal SIGPIPE, Broken pipe. 0xfffff80100528fb4 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) T thought i would bring this up here as well. Does anyone have any input on this?
2016 Jun 28
0
Fwd: rsync seem to be broken on sparc64
...gt; Reading symbols from /usr/bin/rsync...(no debugging symbols found)...done. > (gdb) set args -a /export/test/* /export/test2 > (gdb) run > Starting program: /usr/bin/rsync -a /export/test/* /export/test2 > > Program received signal SIGPIPE, Broken pipe. > 0xfffff80100528fb4 in __write_nocancel () at > ../sysdeps/unix/syscall-template.S:84 > 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) > (gdb) > > > > T thought i would bring this up here as well. Does anyone have any input > on this? > -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,...
2007 May 25
0
deadlock issue: 1.8.6/fastthread/memcached-client/mongrel
...000004130bc in match_fds (dst=0x7fbfff7520, src=0xf45bdc0, max=1025) at eval.c:10527 10527 eval.c: No such file or directory. in eval.c (gdb) source ruby-gdb (gdb) redirect_stdout $1 = 2 (gdb) eval "caller" Program received signal SIGPIPE, Broken pipe. 0x0000003add5b7ee2 in __write_nocancel () from /lib64/tls/libc.so.6 The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (rb_p) will be abandon...
2010 Mar 02
3
2.6.33 high cpu usage
With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports