Re: regression burn-in summary over the last 7 days

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/04/2016 05:40 PM, Kaleb KEITHLEY wrote:
On 08/04/2016 08:07 AM, Niels de Vos wrote:
On Thu, Aug 04, 2016 at 12:00:53AM +0200, Niels de Vos wrote:
On Wed, Aug 03, 2016 at 10:30:28AM -0400, Vijay Bellur wrote:
....
...
./tests/bugs/gfapi/bug-1093594.t ; Failed 1 times
    Regression Links:
https://build.gluster.org/job/regression-test-burn-in/1423/consoleFull

I have not seen this fail yet... All gfapi tests are running in a loop
on a test-system now, we'll see if it reproducible in a few days or so.

It seems that glfs_fini() returns -1 every now and then (once after 1027
iterations, once after 287). Some of the gfapi test cases actually
succeed their intended test, but still return an error when glfs_fini()
fails. I am tempted to just skip this error in most tests and have only
tests/basic/gfapi/libgfapi-fini-hang error out on it. (Obviously also
intend to fix the failure.)

If you fix the bug in glfs_fini() then it should not be necessary to
ignore the failure in the tests, right?

Just fix the bug, don't hack the test.

--

Kaleb



I've faced similar issues with glfs_fini() while working on the bareos
integration. When using a libgfapi built with --enable-debug, an assert
causes the process to dump core.

https://bugzilla.redhat.com/show_bug.cgi?id=1233136 may be worth addressing.

Milind
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux