Re: [rdiff-backup-users] RDIFF-F!CKUP (Very frusttrated)

[dean gaudet]

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
> >  
>