Attic segfaults

[sergiocallegari]

Tried a relatively large backup with latest attic, armel machine, backup to amd64 remote host.

Backup seems to start correctly, but at a certain point I get a "5808 Segmentation fault"

By using verbose mode, I see that this happens while baking up a large (1GB) file. A similarly large file goes through fine just before, though.

Can this be related to the armel arch or the limited amount of memory of the machine (512 MB)?
Any clue on how to provide better info to debug?

[sergiocallegari]

Very much likely, this is related. Now, if I try to remove the checkpoint, I get
Traceback (most recent call last):

File "/home/callegar/PythonEnvs/Py3-Attic/bin/attic", line 3, in
main()
File "/home/callegar/PythonEnvs/Py3-Attic/lib/python3.4/site-packages/attic/archiver.py", line 730, in main
exit_code = archiver.run(sys.argv[1:])
File "/home/callegar/PythonEnvs/Py3-Attic/lib/python3.4/site-packages/attic/archiver.py", line 720, in run
return args.func(args)
File "/home/callegar/PythonEnvs/Py3-Attic/lib/python3.4/site-packages/attic/archiver.py", line 236, in do_delete
archive.delete(stats)
File "/home/callegar/PythonEnvs/Py3-Attic/lib/python3.4/site-packages/attic/archive.py", line 347, in delete
self.cache.chunk_decref(items_id, stats)
File "/home/callegar/PythonEnvs/Py3-Attic/lib/python3.4/site-packages/attic/cache.py", line 248, in chunk_decref
count, size, csize = self.chunks[id]
File "attic/hashindex.pyx", line 152, in attic.hashindex.ChunkIndex.getitem (attic/hashindex.c:2946)
KeyError

Note that the PythonEnvs stuff is to assure execution with most recent msgpack.

[ThomasWaldmann]

Which ARM cpu is this precisely?
See also #309 for a recent ARM <v7 fix. If you have <v7 check your alignment handler.

[sergiocallegari]

This is an ARM V5 - in fact a Kirkwood OPENRD machine running Debian Jessie.

[sergiocallegari]

Funny enough, I see the problem when I try to delete the checkpoint. Checking the archive, no issue is reported:

Starting repository check...
Repository check complete, no problems found.
Starting archive consistency check...
Analyzing archive 150729.checkpoint (1/1)
Archive consistency check complete, no problems found.

[sergiocallegari]

Same hardware as in #309 in fact (ARM V5, not V7, though)

cat /proc/cpuinfo
processor : 0
model name : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS : 1191.93
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1

Hardware : Marvell OpenRD Client Board
Revision : 0000
Serial : 0000000000000000

[ThomasWaldmann]

Also, as you said it is a rather large backup: watch your free disk space and free (virtual) memory while the backup is running.

[sergiocallegari]

There does not seem to be pressure on either of them...

[sergiocallegari]

Looks like an alignment issue. Checked with echo 3 > /proc/cpu/alignment and the system log is flooded.

Should I try the git most recent commit?

[ThomasWaldmann]

Yes, please try latest git version.

[sergiocallegari]

OK... I'll test tomorrow... to late now for the slow arm machine...

[sergiocallegari]

Current git tip apparently works without any error.
I apologize for the noise, I had missed #309 initially...
May I kindly ask making a minor release with the ARM alignment fix?

[ThomasWaldmann]

@jborg ^^ (in case you didn't see)

[sergiocallegari]

I had seen the git repo. I don't know if I am still missing something. The fix in github is dated May 24.
Latest release in github and pypi is 0.16 dated May 16, that does not contain the fix.
I was suggesting tagging a minor release (e.g. 0.16.1) and putting it in pypi.

[jungle-boogie]

Hi @sergiocallegari,

Did you try with latest git master, not a release but the actual source files?

[sergiocallegari]

Yes, git master is fine. However, the fix is not present in any release. A 0.16.1 release would be very useful for people on arm.

[jungle-boogie]

Yes, releases are good.

Of course it's up to the maintainer on when to make a release but there are a couple hundred problems listed here that the maintainer may want to resolve first:
borgbackup/borg#5