mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 05:16:00 +03:00
[GH-ISSUE #1037] s3fs crash with segfault due to invalid access null path. gdb backtrace attached. #570
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#570
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jimhuaang on GitHub (Jun 13, 2019).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1037
Version of s3fs being used (s3fs --version)
V1.85
Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse)
$pkg-config --modversion fuse
2.9.2
$ dpkg -s fuse
Package: fuse
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 152
Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com
Architecture: amd64
Version: 2.9.2-4ubuntu4.14.04.1
Depends: libc6 (>= 2.14), libfuse2 (= 2.9.2-4ubuntu4.14.04.1), adduser, mount (>= 2.19.1), sed (>= 4), udev | makedev
Conffiles:
/etc/fuse.conf 298587592c8444196833f317def414f2
Kernel information (uname -r)
3.19.0-26-generic
GNU/Linux Distribution, if applicable (cat /etc/os-release)
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
s3fs command line used, if applicable
/etc/fstab entry, if applicable
s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs)
if you execute s3fs with dbglevel, curldbg option, you can get detail debug messages
Details about issue
[test 1]
gdb backtrace]
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000041382c in s3fs_truncate (_path=<error reading variable: Cannot access memory at address 0xfffffffffffffeb8>, _path@entry=<error reading variable: Cannot access memory at address 0x8>,
size=<error reading variable: Cannot access memory at address 0xfffffffffffffeb0>, size@entry=<error reading variable: Cannot access memory at address 0x8>) at s3fs.cpp:2095
2095 if(NULL == (ent = FdManager::get()->Open(path, &meta, static_cast<ssize_t>(size), -1, false, true))){
(gdb)bt
#0 0x000000000041382c in s3fs_truncate (_path=<error reading variable: Cannot access memory at address 0xfffffffffffffeb8>, _path@entry=<error reading variable: Cannot access memory at address 0x8>,
size=<error reading variable: Cannot access memory at address 0xfffffffffffffeb0>, size@entry=<error reading variable: Cannot access memory at address 0x8>) at s3fs.cpp:2095
Cannot access memory at address 0x8
[test 2]
(gdb) bt
#0 0x00007fd165a14216 in __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:1064
#1 0x00000000004096a6 in check_parent_object_access (path=0x0, mask=1) at s3fs.cpp:742
#2 0x000000000041529e in s3fs_flush (_path=0x0, fi=0x7fd159ffacd0) at s3fs.cpp:2276
#3 0x00007fd166d86fc7 in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
@gaul commented on GitHub (Jun 13, 2019):
What kind of S3 implementation do you use? Your server returns 500 for an UploadPart operation. You also have a relatively high
parallel_count; do these errors persist with a lower value?Also it looks like subsequent FUSE operations have an invalid path which doesn't make much sense. What series of operations did you issue?
@jimhuaang commented on GitHub (Jun 13, 2019):
Thanks for the quick response.
We used a in-house Object Store with Amazon S3 Compatibility API.
We have done a group of tests to backup 10 vm images in parallel to a directory:
The tests worked when images size is below 60G, and failed with server 500 and s3fs failure when images size is increased to 70G.
lscpu on each node output as following,
We will try to decrease paralle_count to 10 and will let you know the result asap.
@gaul commented on GitHub (Jun 13, 2019):
I cannot reproduce your symptoms when inducing 500 errors during multipart upload. I did verify that s3fs retries on 500 errors which should work around your server issue.
As for the segfault, please try running s3fs under Valgrind to see if it reports errors.
@jimhuaang commented on GitHub (Jun 14, 2019):
when decrease paralle_count to 10, server has no error, s3fs_flush get segfault due to the null path from fuse_operation. I have attached gdb backtrace with fuse-dbg installed as following
@gaul commented on GitHub (Jul 26, 2020):
Could you retest with 1.85 or preferably the latest master?
@gaul commented on GitHub (Oct 10, 2020):
Please reopen if symptoms persist.