Description of problem: Core was generated by `glusterfs --attribute-timeout=0 --entry-timeout=0 --volfile-id=/patchy --volfil'. Version-Release number of selected component (if applicable): How reproducible: 1/1 Steps to Reproduce: 1. 2. 3. Actual results: Expected results: It should not crash. Additional info:
REVIEW: http://review.gluster.org/13253 (Fuse: Check priv and active_vol variable for NULL before calling inode_table_dump) posted (#1) for review on master by Ashish Pandey (aspandey)
REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#2) for review on master by Ashish Pandey (aspandey)
This bug is reproducible while running the ec-notify.t test in loop. Immediately after starting a disperse volume (2+1) kill one brick and just after that try to mount it through fuse. This lead to crash.
REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#3) for review on master by Raghavendra G (rgowdapp)
REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#4) for review on master by Raghavendra G (rgowdapp)
REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#5) for review on master by Raghavendra G (rgowdapp)
REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#6) for review on master by Raghavendra G (rgowdapp)
REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#7) for review on master by Ashish Pandey (aspandey)
COMMIT: http://review.gluster.org/13253 committed in master by Raghavendra G (rgowdapp) ------ commit 8ad742de98da284539b8ae772e0990294412da01 Author: Ashish Pandey <aspandey> Date: Mon Jan 18 15:57:41 2016 +0530 Fuse: Add a check for NULL in fuse_itable_dump Problem: Immediately after starting a disperse volume (2+1) kill one brick and just after that try to mount it through fuse. This lead to crash. Our test scripts use process statedumps to determine various things like whether they are up, connected to bricks etc. It takes some time for an active_subvol to be be associated with fuse even after mount process is daemonized. This time is normally a function of completion of handshake with bricks. So, if we try to take statedump in this time window, fuse wouldn't have an active_subvol associated with it leading to this crash. This happened while executing ec-notify.t, which contains above steps. Solution: Check priv and priv->active_subvol for NULL before inode_table_dump. If priv->active_subvol is null its perfectly fine to skip dumping of inode table as inode table is associated with an active_subvol. A Null active_subvol indicates initialization in progress and fuse wouldn't even have started reading requests from /dev/fuse and hence there wouldn't be any inodes or file system activity. Change-Id: I323a154789edf8182dbd1ac5ec7ae07bf59b2060 BUG: 1299410 Signed-off-by: Ashish Pandey <aspandey> Reviewed-on: http://review.gluster.org/13253 Smoke: Gluster Build System <jenkins.com> CentOS-regression: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org> Reviewed-by: Raghavendra G <rgowdapp>
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.8.0, please open a new bug report. glusterfs-3.8.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user