Description of problem: (Taken from http://lists.gnu.org/archive/html/gluster-devel/2014-04/msg00179.html) Hi, In QEMU, we initialize gfapi in the following manner: ******************** glfs = glfs_new(); if (!glfs) goto out; if (glfs_set_volfile_server() < 0) goto out; if (glfs_set_logging() < 0) goto out; if (glfs_init(glfs)) goto out; ... out: if (glfs) glfs_fini(glfs) ********************* Now if either glfs_set_volfile_server() or glfs_set_logging() fails, we end up doing glfs_fini() which eventually hangs in glfs_lock(). #0 0x00007ffff554a595 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007ffff79d312e in glfs_lock (fs=0x555556331310) at glfs-internal.h:176 #2 0x00007ffff79d5291 in glfs_active_subvol (fs=0x555556331310) at glfs-resolve.c:811 #3 0x00007ffff79c9f23 in glfs_fini (fs=0x555556331310) at glfs.c:753 Note that we haven't done glfs_init() in this failure case. - Is this failure expected ? If so, what is the recommended way of releasing the glfs object ? - Does glfs_fini() depend on glfs_init() to have worked successfully ? - Since QEMU-GlusterFS driver was developed when libgfapi was very new, can gluster developers take a look at the order of the glfs_* calls we are making in QEMU and suggest any changes, improvements or additions now given that libgfapi has seen a lot of development ? Regards, Bharata. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
*** Bug 1091372 has been marked as a duplicate of this bug. ***
REVIEW: http://review.gluster.org/7857 (glfs_fini: Fix a possible hang in glfs_fini.) posted (#1) for review on master by Poornima G (pgurusid)
COMMIT: http://review.gluster.org/7857 committed in master by Anand Avati (avati) ------ commit a96350fa2b68626b8592d5cbd67405e4d8416cca Author: Poornima G <pgurusid> Date: Fri May 23 12:58:56 2014 +0530 glfs_fini: Fix a possible hang in glfs_fini. glfs_fini is called when there is a failure in glfs_new, glfs_init etc. If an application sees a failure in glfs_new and calls glfs_fini, it will result in hang in glfs_fini. Fixed the hang. Change-Id: I80b52cd76d1d7f3fe9a10a91b7226d54176a8982 BUG: 1091335 Signed-off-by: Poornima G <pgurusid> Reviewed-on: http://review.gluster.org/7857 Reviewed-by: soumya k <skoduri> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Anand Avati <avati>
A beta release for GlusterFS 3.6.0 has been released. Please verify if the release solves this bug report for you. In case the glusterfs-3.6.0beta1 release does not have a resolution for this issue, leave a comment in this bug and move the status to ASSIGNED. If this release fixes the problem for you, leave a note and change the status to VERIFIED. Packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update (possibly an "updates-testing" repository) infrastructure for your distribution. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-September/018836.html [2] http://supercolony.gluster.org/pipermail/gluster-users/
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.6.1, please reopen this bug report. glusterfs-3.6.1 has been announced [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://supercolony.gluster.org/pipermail/gluster-users/2014-November/019410.html [2] http://supercolony.gluster.org/mailman/listinfo/gluster-users