sparsebundlefs[4000]: segfault at 18 ip 00007f2b36ceb434 sp 00007f2b35e25868 error 4 in libstdc++.so.6.0.17[7f2b36c72000+e8000]

[tmgstevens]

sparsebundlefs[4000]: segfault at 18 ip 00007f2b36ceb434 sp 00007f2b35e25868 error 4 in libstdc++.so.6.0.17[7f2b36c72000+e8000]

Don't know if that is enough info to go by - let me know if you'd like me to do anything to help reproduce.

[norpol]

Since there wasn't any reply yet: How did you compile sparsebundlefs, which kernel are you running (uname -a), how did you run sparsebundlefs (which flags), and are you able to access the sparse-file via. less (aka. do you've reading permissions?).

[torarnv]

Thanks @norpol for helping out! @tmgstevens can you replace -O2 with -g in the makefile and run sparsebundlefs with -s -f -D ? Is the crash reproducible always?

[tmgstevens]

Hi all, The system is Linux hostname 3.0.101.RNx86_64.2.1 #1 SMP Mon Apr 14 17:20:19 PDT 2014 x86_64 GNU/Linux. It was compile with the settings in the makefile as is, no modifications. It was segfaulting seemingly at random on different files. I had permission to access the files (running as root). I had a suspicion that it was only happening under load.

I didn't see any segfaults after that, however I did see the occasional lock-up where sparsebundlefs would go to 100% CPU until I killed it (I don't know whether it might have segfaulted if I left it). Again, this seemed to happen under load/when accessing lots of files in quick succession (e.g. rsync or cp -r).

I've since recompiled with -g and running with -s -f -D and am not seeing any problems. I'll keep monitoring, but I wonder whether the debugging is slowing it down enough that any race conditions are being avoided.

[torarnv]

You can also try recompiling with -g and then running like normal, until it locks up, and the attach a debugger and see where it's hanging

[torarnv]

Closed due to inactivity.