mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 21:35:58 +03:00
[GH-ISSUE #1771] s3fs crashes in function get_base_exp #913
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#913
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 @farblos on GitHub (Oct 6, 2021).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1771
Version of s3fs being used (s3fs --version)
Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse)
Kernel information (uname -r)
GNU/Linux Distribution, if applicable (cat /etc/os-release)
s3fs command line used, if applicable
/etc/fstab entry, if applicable
N/A - used s3fs from command line
s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs)
Details about issue
s3fs crashes in the middle of a rsync-based larger upload (source file system has ~1TB used disk space) with the following backtrace:
Out of curiosity I had a look at
get_base_exp... shouldn't there be a test on NULL for this one:I can provide information from the coredump but the need for screening sensitive information might make this difficult. Reproducing might be impossible.
@CarstenGrohmann commented on GitHub (Oct 26, 2021):
Can you share the line number of frame 4 (
get_base_exp()), please. Maybe this issue is similar to #1772.@farblos commented on GitHub (Oct 26, 2021):
Will try. IIRC I could not find the debug symbol package corresponding to package
s3fs-fuse-1.90-1.el7.x86_64, downloaded fromOracle Linux 7 EPEL Packages.Any other chances to get these except compiling s3fs myself?
@ggtakec commented on GitHub (Oct 26, 2021):
@farblos I'm sorry for my late replying.
I posted PR #1789 to fix this bug.
If you can still try it, please try the code #1789.
Thanks in advance for your kindness.
@farblos commented on GitHub (Nov 5, 2021):
@ggtakec I'd like to built v1.90 + your fixes. Since I do not use git on a daily basis, please confirm that the following steps would get me the sources as needed:
Thanks!
@farblos commented on GitHub (Nov 8, 2021):
At least executing above steps seem to result in a working
s3fsexecutable. Will do some larger scale uploads now using rsync.@farblos commented on GitHub (Nov 10, 2021):
Tests so far did not reproduce the problem.
But I observed a slow but steady increase of memory consumption by the s3fs process. Not anything close to an OOM condition, but when s3fs crashed with the stacktrace above it has been running already more than 48 hours of uploads.
IMHO this issue is more of #1483 than anything caused by a race condition. Will try to use valgrind to get more information.
@ggtakec commented on GitHub (Mar 26, 2023):
Close this issue. If you still need it, please reopen it.