[Gluster-devel] Regarding a consistent gfapi .t failure

[Niels de Vos]

On Wed, Dec 14, 2016 at 10:30:46AM +0100, Niels de Vos wrote:
> On Wed, Dec 14, 2016 at 04:10:38AM -0500, Poornima Gurusiddaiah wrote:
> > Oh ok. I see that in ./tests/basic/gfapi/bug1291259.c the function
> > glfs_upcall_get_reason() is causing segmentation fault, as per the
> > stderr messages. 
> > Adding Niels, if he wants to take a look at this. 
> 
> glfs_upcall_get_reason() can only segfault if the parameter it passes is
> NULL. It seems that it is possible to get a successful return value from
> glfs_h_poll_upcall(), setting a NULL value for the object with the
> details:
> 
>   https://github.com/gluster/glusterfs/blob/master/api/src/glfs-handleops.c#L2076
> 
> The test-case (and maybe others too?) should not only check for the
> return value from glfs_h_poll_upcall(), but also the errno (!ENOENT).
> 
> > We can mark the test bad by raising a Bz i suppose. 
> 
> Has a bug been filed for this test-case yet?

http://review.gluster.org/16131 is a patch for testing, on top of #16046
in the release-3.9 branch from Krutika. Lets see if this passes :)

Niels

> 
> Thanks,
> Niels
> 
> 
> > 
> > Thanks, 
> > Poornima 
> > 
> > ----- Original Message -----
> > 
> > > From: "Krutika Dhananjay" <kdhananj at redhat.com>
> > > To: "Poornima Gurusiddaiah" <pgurusid at redhat.com>
> > > Cc: "Soumya Koduri" <skoduri at redhat.com>, "Pranith Karampuri"
> > > <pkarampu at redhat.com>
> > > Sent: Wednesday, December 14, 2016 1:49:27 AM
> > > Subject: Re: Regarding a consistent gfapi .t failure
> > 
> > > No unfortunately I had no success with recreating the failure either on my
> > > setup or on a borrowed centos from jenkins cluster.
> > 
> > > Ok this is good information. I didn't know it had failed on other patches
> > > too. I thought it's only with my patch.
> > > Can this be marked as a bad test in that case?
> > 
> > > -Krutika
> > 
> > > On Wed, Dec 14, 2016 at 12:08 PM, Poornima Gurusiddaiah < pgurusid at redhat.com
> > > > wrote:
> > 
> > > > Hi,
> > > 
> > 
> > > > Are you able consistently reproduce this on your local system as well? If
> > > > so
> > > > can you share the system?
> > > 
> > > > I see that it has failed for many other patches as well.
> > > > http://fstat.gluster.org/weeks/1/failure/34
> > > 
> > 
> > > > Regards,
> > > 
> > > > Poornima
> > > 
> > 
> > > > > From: "Krutika Dhananjay" < kdhananj at redhat.com >
> > > > 
> > > 
> > > > > To: "Poornima Gurusiddaiah" < pgurusid at redhat.com >, "Soumya Koduri" <
> > > > > skoduri at redhat.com >
> > > > 
> > > 
> > > > > Cc: "Pranith Karampuri" < pkarampu at redhat.com >
> > > > 
> > > 
> > > > > Sent: Tuesday, December 13, 2016 8:47:57 AM
> > > > 
> > > 
> > > > > Subject: Regarding a consistent gfapi .t failure
> > > > 
> > > 
> > 
> > > > > Hi,
> > > > 
> > > 
> > 
> > > > > The test tests/basic/gfapi/bug1291259.t seems to be failing consistently
> > > > > on
> > > > > my 3.9 backport http://review.gluster.org/#/c/16046/
> > > > 
> > > 
> > 
> > > > > The patch itself makes changes only in compound fops, so it is unlikely
> > > > > that
> > > > > the failure is caused by the patch itself.
> > > > 
> > > 
> > 
> > > > > Here's a sample failure run:
> > > > > https://build.gluster.org/job/centos6-regression/2134/console
> > > > 
> > > 
> > 
> > > > > I ran the test on my laptop and it passes consistently.
> > > > 
> > > 
> > > > > I ran the test on a borrowed centos slave and it passes there as well.
> > > > 
> > > 
> > > > > I looked at the logfile bug1291259.log from the archived build failure
> > > > > logs
> > > > 
> > > 
> > > > > but there are no failures.
> > > > 
> > > 
> > 
> > > > > If you have any ideas on how to proceed further, could you please suggest
> > > > > the
> > > > > same?
> > > > 
> > > 
> > 
> > > > > -Krutika
> > > > 
> > > 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20161214/8416fbcd/attachment-0001.sig>