Red Hat Bugzilla – Bug 1011662
threads created by gluster should block signals which are not used by gluster itself
Last modified: 2015-09-01 19:06:20 EDT
REVIEW: http://review.gluster.org/5995 (core: block unused signals in created threads) posted (#1) for review on master by Anand Avati (firstname.lastname@example.org)
REVIEW: http://review.gluster.org/5995 (core: block unused signals in created threads) posted (#2) for review on master by Anand Avati (email@example.com)
COMMIT: http://review.gluster.org/5995 committed in master by Vijay Bellur (firstname.lastname@example.org)
Author: Anand Avati <email@example.com>
Date: Tue Sep 24 09:45:08 2013 -0700
core: block unused signals in created threads
Block all signal except those which are set for explicit handling
in glusterfs_signals_setup(). Since thread spawning code in
libglusterfs and xlators can get called from application threads
when used through libgfapi, it is necessary to do this blocking.
Signed-off-by: Anand Avati <firstname.lastname@example.org>
Tested-by: Gluster Build System <email@example.com>
Reviewed-by: Amar Tumballi <firstname.lastname@example.org>
Reviewed-by: Vijay Bellur <email@example.com>
Thanks for fixing this quickly Anand!
The patch looks good, but why trap SIGABRT? In general, when using libgfapi the application handler for SIGABRT should be used.
A caller of assert() would need the SIGABRT to be caught in the same thread for things like printing a meaningful backtrace, and hence left it unblocked (in case the application has already setup a handler). It wasn't with the intention that libgfapi would handle SIGABRT with its handler.
That makes sense, thanks!
with 3.4.1 release of glusterfs
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.5.0, please reopen this bug report.
glusterfs-3.5.0 has been announced on the Gluster Developers mailinglist , packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist  and the update infrastructure for your distribution.