Bug with particular large number

[VolMike]

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?

if it could still be of any use, there is one more "crashing" number:
18911778784739562144612741372843311631382033055424664965367805621.

[LaurV]

Is this linux-related?
I tried 40-50 times, both numbers, from inside the yafu and from outside (cmd line), no crash, numbers split by siqs every time in few seconds.

SIQS elapsed time = 21.3591 seconds.
Total factoring time = 33.6402 seconds

PRP38 = 12862397506386155909354558787876349793
PRP30 = 407110435562715649819424326729

starting SIQS on c65: ....

SIQS elapsed time = 13.1248 seconds.
Total factoring time = 20.9216 seconds

PRP30 = 602353664334842419891443250441
PRP35 = 31396470054885716002527004035803981

No crash. WindowsXP 32 on core2 duo, and windows7 64 on i7-2600k.

[VolMike]

Originally Posted by LaurV

Is this linux-related?
I tried 40-50 times, both numbers, from inside the yafu and from outside (cmd line), no crash, numbers split by siqs every time in few seconds.

SIQS elapsed time = 21.3591 seconds.
Total factoring time = 33.6402 seconds

PRP38 = 12862397506386155909354558787876349793
PRP30 = 407110435562715649819424326729

starting SIQS on c65: ....

SIQS elapsed time = 13.1248 seconds.
Total factoring time = 20.9216 seconds

PRP30 = 602353664334842419891443250441
PRP35 = 31396470054885716002527004035803981

No crash. WindowsXP 32 on core2 duo, and windows7 64 on i7-2600k.

It's windows-related problem on PC under Win7 x64 ult, corei7-860.
I have also TPC under the same OS on Core2Duo- T9300 and this problem is also occured.

[bsquared]

Thanks for the new test case. Although I guess I forgot to mention that I fixed the bug.... and it *was* a bug. It was some sort of VonNeumannbug, in that it only manifested itself on occasional random distributions of primes during the large prime bucket sort.

Valgrind ultimately was very helpful - it eventually pointed me toward the data structure that was overflowing. It just took quite a while to actually catch the vonneumannbug in Valgrind.

I hope to have v1.31 out in the next couple weeks.

[debrouxl]

Yeah, Valgrind is a great tool

clang+AddressSanitizer cuts much of the large speed penalty of Valgrind, and can detect several memory errors that Valgrind cannot; but conversely, Valgrind can detect some errors that AddressSanitizer cannot detect.

[VolMike]

...and one more "crashing" number: 21028701588210693904788721831286708149055869664064159654556833079

[Dubslow]

Originally Posted by VolMike

...and one more "crashing" number: 21028701588210693904788721831286708149055869664064159654556833079

It didn't crash for me, Linux 64 bit.

[bsquared]

Originally Posted by Dubslow

It didn't crash for me, Linux 64 bit.

It is a random bug, so it won't crash every time. Some data structures can overflow (with relatively low probability) for this size input.

I still hope to have the new version (with this issue fixed) out soon.