Pasting inline for searchability (it's always better to put the backtrace inline, rather than attaching it as a file):


#0  __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
__preamble__
[KCrash Handler]
#3  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:262
#4  0x00007fa27c86f0b8 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#5  QByteArray::append (ba=..., this=0x7ffc6ecea2b8) at text/qbytearray.cpp:1997
#6  QByteArray::append (this=this@entry=0x7ffc6ecea2b8, ba=...) at text/qbytearray.cpp:1990
#7  0x00007fa27ce91d78 in File::readMetadata (this=0x560092914fb0, pMetadataStream=...) at ./kioslave/bupvfs.cpp:117
#8  0x00007fa27ce940d3 in ArchivedDirectory::generateSubNodes (this=0x5600928a59c0) at ./kioslave/bupvfs.cpp:382
#9  0x00007fa27ce91cd4 in Directory::subNodes (this=0x5600928a59c0) at ./kioslave/bupvfs.cpp:107
#10 0x00007fa27ce90358 in BupSlave::listDir (this=0x7ffc6ecea5b0, pUrl=...) at ./kioslave/bupslave.cpp:150
#11 0x00007fa27cd42796 in KIO::SlaveBase::dispatch(int, QByteArray const&) () from /lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#12 0x00007fa27cd42fd6 in KIO::SlaveBase::dispatchLoop() () from /lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#13 0x00007fa27ce913a4 in kdemain (pArgc=<optimized out>, pArgv=0x7ffc6ecea6a0) at ./kioslave/bupslave.cpp:372
#14 0x000056009158e5b8 in main (argc=5, argv=0x7ffc6ecea7f8) at ./src/kioslave/kioslave.cpp:146


bupvfs.cpp is not a built-in KIO thing; it's added by Kup. Keeping the bug report here.

Thanks for the bug report!

I am unable to reproduce the problem. Looking at the code around the place of the crash I am also unable to imagine what could be going wrong there, my imagination is not good enough... :)

To work towards a solution to this problem we will need to dig around a bit more in your saved backups, see what triggers this problem.
I am thinking that this could be related to the stored content of a file, perhaps it has gotten corrupted somehow. This could be any file in your home folder, since when you select the top level directory Kup will be scanning absolutely every single file that was saved in there. So when you say that individual folders work fine, perhaps you were just lucky to try with folders that had no problem.

If you want to help by looking for a file in your backups that triggers this problem, the easiest way is to just open dolphin and type in the address bar "bup:/path/to/backups". Then just navigate around there, into every saved directory. See if the bup kioslave crashes in the same way.

I hope you managed to get your files restored! While you have this problem, the alternative way to restore files would be to just use "bup restore" directly.

(In reply to Simon Persson from comment #2)
> Thanks for the bug report!
> 
> I am unable to reproduce the problem. Looking at the code around the place
> of the crash I am also unable to imagine what could be going wrong there, my
> imagination is not good enough... :)
> 
> To work towards a solution to this problem we will need to dig around a bit
> more in your saved backups, see what triggers this problem.
> I am thinking that this could be related to the stored content of a file,
> perhaps it has gotten corrupted somehow. This could be any file in your home
> folder, since when you select the top level directory Kup will be scanning
> absolutely every single file that was saved in there. So when you say that
> individual folders work fine, perhaps you were just lucky to try with
> folders that had no problem.
> 
> If you want to help by looking for a file in your backups that triggers this
> problem, the easiest way is to just open dolphin and type in the address bar
> "bup:/path/to/backups". Then just navigate around there, into every saved
> directory. See if the bup kioslave crashes in the same way.
> 
> I hope you managed to get your files restored! While you have this problem,
> the alternative way to restore files would be to just use "bup restore"
> directly.

Hi. Thanks. I did manage to restore my files by manually copying the files to my home folder.

Now, even after deleting some old backups and trying to restore new ones again I still see the crash. I also tried accessing all the folders using your instructions and couldn't make it crash.

I thought maybe the problem was that I had made the backup to an NTFS partition, but I did some tests by making a new backup of my Home EXT4 partition to a subfolder in it and the same happens.

I might have found a clue but I'm not sure. This might be a different problem related to trying to restore my /home backup to my actual /home (which a normal user has no permission to overwrite).

I made a new backup and if I try to restore it to my home folder Kioslave still crashes, but if I wait a bit it stops crashing and then it shows I have a folder with a duplicate name. If I set it to merge (or set a new name, it doesn't matter) it shows me the following error:

Traceback (most recent call last):
  File "/usr/lib/bup/cmd/bup-restore", line 319, in <module>
    wrap_main(main)
  File "/usr/lib/bup/cmd/../bup/compat.py", line 215, in wrap_main
    sys.exit(main())
  File "/usr/lib/bup/cmd/bup-restore", line 256, in main
    mkdirp(opt.outdir)
  File "/usr/lib/bup/cmd/../bup/helpers.py", line 194, in mkdirp
    os.makedirs(d)
  File "/usr/lib/python3.8/os.py", line 223, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: b'/home/_kup_temporary_restore_folder_'
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 153, in apport_excepthook
    with os.fdopen(os.open(pr_filename,
FileNotFoundError: [Errno 2] No such file or directory: '/var/crash/_usr_lib_bup_cmd_bup-restore.1000.crash'

Original exception was:
Traceback (most recent call last):
  File "/usr/lib/bup/cmd/bup-restore", line 319, in <module>
    wrap_main(main)
  File "/usr/lib/bup/cmd/../bup/compat.py", line 215, in wrap_main
    sys.exit(main())
  File "/usr/lib/bup/cmd/bup-restore", line 256, in main
    mkdirp(opt.outdir)
  File "/usr/lib/bup/cmd/../bup/helpers.py", line 194, in mkdirp
    os.makedirs(d)
  File "/usr/lib/python3.8/os.py", line 223, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: b'/home/_kup_temporary_restore_folder_'

---------------

If I run kup-filedigger from the terminal, while kioslave is crashing constantly the terminal outputs this several times a second:

kf.kio.core: UDSEntry for '.' not found, creating a default one. Please fix the "kio_bup" KIO slave

--------------

But, most importantly, I can still restore the backup if I tell it to restore to another folder that isn't /home/MyUser. I mean, Kioslaves still keeps crashing (only when in the checking file sizes step, as always), but if I select a folder inside my user dir, like /home/MyUser/backup and I just let it crash, eventually Kioslave stops crashing and the files do start to get restored. 

So apparently the crashes are not preventing Kup from restoring the backups when I tell it to restore to a subfolder in /home/MyUser.

I also tried running kup-filedigger as root and it works as I described above when selecting a subfolder in my home user, with the same crashes. I didn't try overwriting my files by restoring straight to /home because it would make all my files root-owned, but I suspect the problems with permissions I pasted above wouldn't happen when doing that.

-----------------------

If this can't be solved, maybe Kup should just forbid selecting /home or /home/user as folders to be restored, and instead, the interface could be changed to have checkboxes to the left of all folders. That way, the user could select all individual folders (preferably with a "Select all" button) within /home/user and it wouldn't trigger the bug since those would be copied individually instead of including the parents /home/user.

If there's anything else I can do to help diagnose the issue just tell me.

Oh, and I almost forgot a detail. I have no ideia if this influences anything or not but my install doesn't have a separate partition for /home.

I had the same problem. It appears to happen when there it tries to open a file and can't because of permissions or the file being open etc. I haven't done enough testing to be sure, but after dismissing all the crashes it worked and there were about an equal number of bad file opens in the logs. Everything else worked fine.