|
 RDIFF-F!CKUP (Very frusttrated)
hmm that doesn't sound like a questionable config at all...
maybe you could try gdb... especially if you can set up a
local-fs-to-local-fs backup which causes the problem. then try this:
% gdb python
(gdb) run /usr/bin/rdiff-backup [rdiff-backup args here]
assuming the segfault still occurs you should get a (gdb) prompt again and
then type "where" ... and let us know what is spewed by "where".
there's a really good chance this won't tell us anything because debugging
symbols won't be available...
if that's the case then the only next option is to go into the
rdiff-backup code and start inserting print/log statements everywhere
trying to narrow down the exact line the problem occurs on (or maybe a
python wizard knows of a trick which will give us a python trace on
SIGSEGV).
-dean
On Fri, 14 Oct 2005, Golden Butler wrote:
yeah, I've starting to believe also that this is not an rdiff-backup problem.
I don't overclock and I don't have any inexpensive memory. I'm thinking I
should start from scratch. I'm running Suse Linux 9.2. I didn't compile or
optimize any package, cause actually I don't know how to do so. So how can I
completely an cleanly uninstall rdiff-backup, python, and gcc compiler, so
that I can reinstall again. Reinstalling the O.S. is not an option.
dean gaudet wrote:
On Thu, 13 Oct 2005, Golden Butler wrote:
./test-bkp: line 2: 20700 Segmentation fault rdiff-backup -v7
--print-statistics /home/golden/testy
you know, a segfault is very unlikely to be an rdiff-backup problem.
i'd be more tempted to blame the C compiler (which could be miscompiling
something rdiff-backup uses) and/or the hardware.
do you do anything crazy like run gentoo or any other distribution where
you've (re)compiled binaries with your own optimisation options and/or with
a bleeding edge gcc?
do you overclock your hardware or use inexpensive (non-ECC) memory? one
thing you could try here is running memtest86.
since it's a consistent segfault it's more likely to be a miscompile than a
hardware problem. if it were me i'd run the whole thing under gdb (and/or
with a non-zero coredumpsize limit) and disassemble the faulty code... but
that's not a solution for a beginner.
-dean
|
