On Fri, Apr 03, 2015 at 11:26:40AM +0530, Pranith Kumar Karampuri wrote:
I still don't understand why http://review.gluster.org/10109 is working.
Does anyone know the reason? How are you guys re-creating the crash? I ran
crypt.t but no crashes on my laptop. Could some one help me re-create this
On 04/01/2015 03:27 PM, Emmanuel Dreyfus wrote:
Hi
crypt.t was recently broken in NetBSD regression. The glusterfs returns
a node with file type invalid to FUSE, and that breaks the test.
After running a git bisect, I found the offending commit after which
this behavior appeared:
On 04/02/2015 12:27 AM, Raghavendra Talur wrote:
On Wed, Apr 1, 2015 at 10:34 PM, Justin Clift jus...@gluster.org
mailto:jus...@gluster.org wrote:
On 1 Apr 2015, at 10:57, Emmanuel Dreyfus m...@netbsd.org
mailto:m...@netbsd.org wrote:
Hi
crypt.t was recently broken
On Thu, Apr 02, 2015 at 01:58:39PM +0530, Raghavendra Bhat wrote:
On Thursday 02 April 2015 01:00 PM, Pranith Kumar Karampuri wrote:
On 04/02/2015 12:27 AM, Raghavendra Talur wrote:
On Wed, Apr 1, 2015 at 10:34 PM, Justin Clift jus...@gluster.org
mailto:jus...@gluster.org wrote:
On Thursday 02 April 2015 01:00 PM, Pranith Kumar Karampuri wrote:
On 04/02/2015 12:27 AM, Raghavendra Talur wrote:
On Wed, Apr 1, 2015 at 10:34 PM, Justin Clift jus...@gluster.org
mailto:jus...@gluster.org wrote:
On 1 Apr 2015, at 10:57, Emmanuel Dreyfus m...@netbsd.org
I think, crypt xlator should do a mem_put of local after doing STACK_UNWIND
like other xlators which also use mem_get for local (such as AFR). I am
suspecting crypt not doing mem_put might be the reason for the bug
mentioned.
My understanding was that mem_put should be called automatically
On 04/02/2015 07:27 PM, Raghavendra Bhat wrote:
On Thursday 02 April 2015 05:50 PM, Jeff Darcy wrote:
I think, crypt xlator should do a mem_put of local after doing
STACK_UNWIND
like other xlators which also use mem_get for local (such as AFR). I am
suspecting crypt not doing mem_put might be
On Thursday 02 April 2015 05:50 PM, Jeff Darcy wrote:
I think, crypt xlator should do a mem_put of local after doing STACK_UNWIND
like other xlators which also use mem_get for local (such as AFR). I am
suspecting crypt not doing mem_put might be the reason for the bug
mentioned.
My
Hi
crypt.t was recently broken in NetBSD regression. The glusterfs returns
a node with file type invalid to FUSE, and that breaks the test.
After running a git bisect, I found the offending commit after which
this behavior appeared:
8a2e2b88fc21dc7879f838d18cd0413dd88023b7
mem-pool:
Raghavendra Talur raghavendra.ta...@gmail.com wrote:
I found one issue that local is not allocated using GF_CALLOC and with a
mem-type.
This is a patch which *might* fix it.
It does. The memory corruption disapeared and the test can complete.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
I found one issue that local is not allocated using GF_CALLOC and with a
mem-type.
This is a patch which *might* fix it.
It does. The memory corruption disapeared and the test can complete.
Interesting. I suspect this means that we *are* in the case where the
previous comment came from.
Jeff Darcy jda...@redhat.com wrote:
It does. The memory corruption disapeared and the test can complete.
Interesting.
FWIW I made 147 successful runs in a row with the patch, while it always
failed without.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
On 1 Apr 2015, at 10:57, Emmanuel Dreyfus m...@netbsd.org wrote:
Hi
crypt.t was recently broken in NetBSD regression. The glusterfs returns
a node with file type invalid to FUSE, and that breaks the test.
After running a git bisect, I found the offending commit after which
this behavior
On Wed, Apr 1, 2015 at 10:34 PM, Justin Clift jus...@gluster.org wrote:
On 1 Apr 2015, at 10:57, Emmanuel Dreyfus m...@netbsd.org wrote:
Hi
crypt.t was recently broken in NetBSD regression. The glusterfs returns
a node with file type invalid to FUSE, and that breaks the test.
After
- local = mem_get0(this-local_pool);
+ local = GF_CALLOC (sizeof (*local), 1, gf_crypt_mt_local);
As I understand it, mem_get0 is a valid (and even more
efficient) way to allocate such objects. The frame cleanup
code should recognize which method to use when deallocating.
If that's broken,
As I understand it, mem_get0 is a valid (and even more
efficient) way to allocate such objects. The frame cleanup
code should recognize which method to use when deallocating.
If that's broken, we're going to have more numerous and
serious problems than this. I'll look into it further.
I
16 matches
Mail list logo
