igraph / python-igraph

Python interface for igraph
GNU General Public License v2.0
1.33k stars 249 forks source link

Testsuite fails on various architectures. #91

Closed hlef closed 8 years ago

hlef commented 8 years ago

Hi,

The Debian Package Auto-Building project has detected that python-igraph fails to build on various architectures because of testsuite failures. This makes our Debian package fails to build from source (FTBFS).

Here is a short extract of the error log:

======================================================================
FAIL: testMultilevel (igraph.test.decomposition.CommunityTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/<<PKGBUILDDIR>>/igraph/test/decomposition.py", line 243, in testMultilevel
    self.assertTrue(cls[0].membership == [0,0,0,1,0,0,1,1,2,2,2,3,2,3,2,2])
AssertionError: False is not true

----------------------------------------------------------------------
Ran 307 tests in 11.455s

Affected architectures are: i386, hurd-i386 and kfreebsd-i386. You can find full logs and additional informations here. A more recent build has been realized today here.

If you need access to i386 machines for test purpose, I can do it for you.

Regards, Hugo (hle)

ntamas commented 8 years ago

Thanks for the bug report! Would it be possible to arrange access to some i386 machines for me then? I'm afraid that I can't test python-igraph on those architectures on my own.

hlef commented 8 years ago

'direct access' will be hard, but I can build & test for you and send you back the logs if you want. :/

ntamas commented 8 years ago

Okay, let me think about it a bit then - maybe I can get around with setting up a VM on my side.

ntamas commented 8 years ago

I have managed to reproduce the issue in an i386 VM. Interestingly enough, it happens only with the libigraph0-dev package that ships with Debian (I tried with 0.7.1-2) but not with the source code downloaded directly from http://igraph.org/c. I'll keep digging.

hlef commented 8 years ago

Well, here is the list of patches applied to the upstream source code for the binary package libigraph0-dev. Nothing suspicious... It's unclear to me how the error could come from the Debian package of igraph. :)

ntamas commented 8 years ago

I have figured it out. The test case is a bit sloppy; it should check whether a partitioning of the graph obtained from some algorithm is equal to an expected partition, but it does not take into account cases when the partitions are identical but the numeric identifiers of the groups are permuted. I'll commit a patch soon.

ntamas commented 8 years ago

Okay, so the patch was committed to the master branch. It fixes other possible points of failure as well (all due to the same oversight). Can you simply add this patch to the list of patches applied in the Debian build to make the test suite pass? The line numbers might have to be adjusted.

hlef commented 8 years ago

Thanks ! I will do it as soon as possible.

hlef commented 8 years ago

Hi,

It looks like there's still a problem with the testsuite. It fails with following error message:


======================================================================
FAIL: testEigenvectorCentrality (igraph.test.atlas.IsoclassTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build/igraph/test/atlas.py", line 33, in testEigenvectorCentrality
    ec, eval = g.evcent(return_eigenvalue=True)
igraph._igraph.InternalError: Error at arpack.c:1174: ARPACK error, Maximum number of iterations reached

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build/igraph/test/atlas.py", line 35, in testEigenvectorCentrality
    self.assertTrue(False, msg="Eigenvector centrality threw exception for graph #%d: %s" % (idx, ex))
AssertionError: False is not true : Eigenvector centrality threw exception for graph #137: Error at arpack.c:1174: ARPACK error, Maximum number of iterations reached

----------------------------------------------------------------------
Ran 307 tests in 51.556s

You can find a full build log here.

hlef commented 8 years ago

By the way, the testsuite fails exclusively on armhf. It's fine for all other architectures.

hlef commented 8 years ago

Sorry for being insistent, but this issue is blocking python-igraph in Sid. If it doesn't get solved in the next months, python-igraph won't be included in Debian Stretch...

ntamas commented 8 years ago

Sorry for the delay, I'm a bit overwhelmed with work, but I'll try to get to the bottom of this in the next few days. I'm having difficulties figuring out how to test this on an arm64 host - do you happen to know whether it's possible to emulate the armhf environment somehow (e.g., via qemu)?

hlef commented 8 years ago

Yes, it's possible. I've never did it, but I think you just have to download an armhf Debian testing image (for example here) and run it with qemu-system-arm. Normally you won't need a custom kernel.

However, if you want to test a patch, you can also post it here and I'll do it for you.

ntamas commented 8 years ago

I'm having a hard time reproducing this, even on armhf. Does this occur deterministically or only once in a while?

I'm asking because I have now installed Sid in a qemu virtual machine, installed libigraph0-dev and its dependences from the repos, downloaded the source of python-igraph (also from the repos), extracted the source, ran python setup.py test quite a few times, and the tests did not fail at all. Eigenvector calculation is numerically unstable, so it may happen that every once in a while the test case fails because the process started from a vector that converges slower than usual (this happens if the initial vector is almost parallel to an eigenvector corresponding to a non-dominant eigenvalue). I could try raising the maximum number of iterations allowed for the eigenvector centrality calculation, but it would be useful to know whether the failure happens deterministically (in which case I need to figure out why the error does not happen in my VM).