You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Debian package of pyemdfails to build on the 32-bit powerpc port because the tests time out after 150 minutes of inactivity, while on other platforms including ppc64el and ppc64 they complete in under half a second. I logged into the powerpc porterbox perotto.debian.net, executed a build and noticed that the Python process running the tests uses 100% CPU. I deleted tests one at a time until the remaining tests were passing. Only three tests were hanging with 100% CPU: test_emd_3test_emd_with_flow_3test_emd_with_flow_4. The three hanging tests seem to have one thing in common, they all have a distance_matrix containing only zeros. One other test that passes has this feature too test_emd_with_flow_5 though. The three hanging tests also seem to have similar signature parameters. When running Python in gdb, interrupting the process gives a stack trace that indicates the compute_shortest_path function from min_cost_flow.hpp is using the CPU.
Any ideas on how to debug this?
The text was updated successfully, but these errors were encountered:
The Debian package of pyemd fails to build on the 32-bit powerpc port because the tests time out after 150 minutes of inactivity, while on other platforms including ppc64el and ppc64 they complete in under half a second. I logged into the powerpc porterbox perotto.debian.net, executed a build and noticed that the Python process running the tests uses 100% CPU. I deleted tests one at a time until the remaining tests were passing. Only three tests were hanging with 100% CPU:
test_emd_3
test_emd_with_flow_3
test_emd_with_flow_4
. The three hanging tests seem to have one thing in common, they all have adistance_matrix
containing only zeros. One other test that passes has this feature tootest_emd_with_flow_5
though. The three hanging tests also seem to have similar signature parameters. When running Python in gdb, interrupting the process gives a stack trace that indicates thecompute_shortest_path
function frommin_cost_flow.hpp
is using the CPU.Any ideas on how to debug this?
The text was updated successfully, but these errors were encountered: