search

flintlib / flint

FLINT (Fast Library for Number Theory)
http://www.flintlib.org
GNU Lesser General Public License v3.0
436 stars 243 forks source link

Make check failure #255

Closed isuruf closed 4 years ago

isuruf commented 8 years ago 
pollard_brent.... 
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
FAIL : Pollard Rho - Brent failed too many times (2 times)

This is a 32 bit build on Windows in MSYS2 env, MinGW-w64 toolchain

Full log is here, https://ci.appveyor.com/project/isuruf/flint2/build/1.0.11/job/6nw8yfp5qd8jwfgi

wbhart commented 8 years ago

Thanks. It's safe to simply increase the percentage of cases that are allowed to fail on 32 bit machines. I assume it was running many more than two times.

On 11 April 2016 at 15:57, Isuru Fernando notifications@github.com wrote:

pollard_brent.... This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. FAIL : Pollard Rho - Brent failed too many times (2 times)

This is a 32 bit build on Windows in MSYS2 env, MinGW-w64 toolchain

Full log is here, https://ci.appveyor.com/project/isuruf/flint2/build/1.0.11/job/6nw8yfp5qd8jwfgi

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/wbhart/flint2/issues/255

isuruf commented 8 years ago

Yes, it was running 40 times and failed 2 times, but the test is designed to fail if there are more than 1 failure.

wbhart commented 8 years ago

Then the test can safely be changed to allow 2 failures. It's only supposed to check that the function is useful in a majority of cases. I guess it was set to a value that made the test code pass.

Technically the number of failures should be related somehow to the number of iterations. And if the number of iterations is related to flint_test_multiplier() then so should the number of failures be related to it.

Anyway, this is brand new code which I am delighted to hear works on 32 bit machines.

On 11 April 2016 at 16:17, Isuru Fernando notifications@github.com wrote:

Yes, it was running 40 times and failed 2 times, but the test is designed to fail if there are more than 1 failure.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/wbhart/flint2/issues/255#issuecomment-208368638

isuruf commented 8 years ago

Will do the change. Actually number of test cases is 40*flint_test_multiplier() and only flint_test_multiplier() failures are allowed. It's a 64 bit machine, but built using MinGW-w64 i686 toolchain.

isuruf commented 8 years ago

Another failure

get_mpn.... 
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
conversion failed.
n : 2251799813161472
converted value : 9671388110172963982541312
./Makefile.subdirs:91: recipe for target '../build/fmpz/test/t-get_mpn.exe_RUN' failed
make[1]: *** [../build/fmpz/test/t-get_mpn.exe_RUN] Error 3
wbhart commented 8 years ago

I think I've seen this one before. I don't know if I managed to figure out what caused it.

On 12 April 2016 at 14:44, Isuru Fernando notifications@github.com wrote:

Another failure

get_mpn.... This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. conversion failed. n : 2251799813161472 converted value : 9671388110172963982541312 ./Makefile.subdirs:91: recipe for target '../build/fmpz/test/t-get_mpn.exe_RUN' failed make[1]: *\ [../build/fmpz/test/t-get_mpn.exe_RUN] Error 3

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/wbhart/flint2/issues/255#issuecomment-208886097

wbhart commented 7 years ago

I fixed a related failure in n_factor_ecm today. I haven't seen either of the other failures yet.

wbhart commented 4 years ago

The first issue is fixed in trunk.

The second issue is a mystery. This is a particularly simple function which simply allocates an array, copies some limbs into it and returns the number of limbs. The test code had some dodgy bits, which I've fixed. But I don't think any of them are relevant to the bug.

I've added a regression test for this specific value of n with some printing of various things to see if we can identify the problem.

@isuruf Could you possible run this again on your 64 bit machine with the i686 toolchain (so that FLINT_BITS==32) and see if the problem still exists. I suspect this can only be a compiler bug as the code itself is trivial.

wbhart commented 4 years ago

@isuruf Don't worry, I can see that you fixed the test code, which was using 64 instead of 32 for the number of bits on a 32 bit machine, which explains the bug. If the CI passes now, this is fixed ages ago.