Bug with particular large number

[VolMike]

I found some bug in last version of YAFU_x64_64k in Win7.
YAFU stoppes with unhandled error while trying
factor(5236416251205655581276983781304293493778167548221438913831123517097).
Could anyone else confirm this problem?

[bsquared]

Originally Posted by VolMike

I found some bug in last version of YAFU_x64_64k in Win7.
YAFU stoppes with unhandled error while trying
factor(5236416251205655581276983781304293493778167548221438913831123517097).
Could anyone else confirm this problem?

Yes, I see it too. I'll look into it - thanks.

[Brian Gladman]

Originally Posted by bsquared

Yes, I see it too. I'll look into it - thanks.

This number does not cause any problems on my Windows 7 x64 version of YAFU.

[VolMike]

Originally Posted by Brian Gladman

This number does not cause any problems on my Windows 7 x64 version of YAFU.

Try it several times (delete siqs.dat each time in order to prevent getting factorization from dat file) and once you'd probably get an error in siqs stage.

[Brian Gladman]

Originally Posted by VolMike

Try it several times (delete siqs.dat each time in order to prevent getting factorization from dat file) and once you'd probably get an error in siqs stage.

No failures in 10 runs with an x64 binary built from the SVN with Visual Studio 2010.

[VolMike]

Originally Posted by Brian Gladman

No failures in 10 runs with an x64 binary built from the SVN with Visual Studio 2010.

Ok,thanks.

[Stargate38]

Weird. I also get an error when I try to factor 5236416251205655581276983781304293493778167548221438913831123517097. Why doesn't this number work in Yafu? I even tried rolling back to version 1.29. Here's the error I get:

 
Problem signature:
Problem Event Name: APPCRASH
Application Name: yafu.exe
Application Version: 0.0.0.0
Application Timestamp: 4ed799a7
Fault Module Name: yafu.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4ed799a7
Exception Code: c0000005
Exception Offset: 000000000001eee8
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 3365
Additional Information 2: 33654147fb0c2c75d9d3eaaf1fcc157a
Additional Information 3: 14fe
Additional Information 4: 14fe172b8c01b0bce213e14cb1111d45
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

Also, Why does Yafu 1.30 crash when I try to define the stage 1 bound for ECM (B1ecm) in the ini file?

[bsquared]

Originally Posted by Stargate38

Weird. I also get an error when I try to factor 5236416251205655581276983781304293493778167548221438913831123517097. Why doesn't this number work in Yafu? I even tried rolling back to version 1.29. Here's the error I get:

Also, Why does Yafu 1.30 crash when I try to define the stage 1 bound for ECM (B1ecm) in the ini file?

Refer to http://www.mersenneforum.org/showpos...postcount=1135.

I am extremely pressed for time lately, but I'll try to get a bugfix release out.

[bsquared]

I haven't made any progress on fixing this. Out of a 100 or so runs on a combination of systems (linux and windows, 32 and 64 bit) I saw it crash 4 or 5 times, twice with a "double free - corruption" error and 2 or 3 times with a seg fault. Haven't managed to catch it in a debugger yet. Are there any other test cases? Anyone else seen this or any other number mysteriously crash?

[Random Poster]

Originally Posted by bsquared

I haven't made any progress on fixing this. Out of a 100 or so runs on a combination of systems (linux and windows, 32 and 64 bit) I saw it crash 4 or 5 times, twice with a "double free - corruption" error and 2 or 3 times with a seg fault. Haven't managed to catch it in a debugger yet. Are there any other test cases? Anyone else seen this or any other number mysteriously crash?

Run it under Valgrind on Linux; that can catch memory errors even if they wouldn't otherwise lead to a crash.

[bsquared]

Originally Posted by Random Poster

Run it under Valgrind on Linux; that can catch memory errors even if they wouldn't otherwise lead to a crash.

I had already tried that and Valgrind didn't find anything suspicious. I then wasted a lot of time trying to catch it in gdb, and once that happened, trying with no luck to find an issue (my gdb-foo is not strong).

But I tried valgrind again and finally saw a few illegal read/write errors, even though the program didn't crash. Allocating a structure a little bit bigger seems to have fixed the problem. At least, I've factored that number 100+ times now with no crashes.