Looks like it is trying to run TLP, which is still somewhat experimental. Set forceDLP=1 in yafu.ini or use forceDLP on command line. I should set the crossover point much higher.

Bug in SIQS
This number crashes YAFU when I try to factor it by SIQS: 18425466191500234497808154837889417418704176536401223
[code]C:\Numbers\aliqueit112>yafu siqs(18425466191500234497808154837889417418704176536401223) Applying tune_info entry for WIN64  Intel(R) Core(TM) i59300H CPU @ 2.40GHz YAFU Version 2.01 Built with Microsoft Visual Studio 1928 Using GMPECM 7.0.4, Powered by MPIR 3.0.0 Detected Intel(R) Core(TM) i59300H CPU @ 2.40GHz Detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes Using 1 random witness for RabinMiller PRP checks Cached 664579 primes; max prime is 9999991 =============================================================== ======= Welcome to YAFU (Yet Another Factoring Utility) ======= ======= bbuhrow@gmail.com ======= ======= Type help at any time, or quit to quit ======= =============================================================== >> starting SIQS on c53: 18425466191500234497808154837889417418704176536401223 ==== sieve params ==== n = 54 digits, 177 bits factor base: 1824 primes (max prime = 33317) single large prime cutoff: 2165605 (65 * pmax) double large prime range from 1110022489 to 122254169454 DLP MFB = 1.75 using AVX2 enabled 32k sieve core sieve interval: 2 blocks of size 32768 polynomial A has ~ 6 factors using multiplier of 7 using SPV correction of 20 bits, starting at offset 32 trial factoring cutoff at 59 bits ==== sieving in progress ( 8 threads): 1888 relations needed ==== ==== Press ctrlc to abort and save state ==== C:\Numbers\aliqueit112>[/code]factor.log (different number): [code]05/08/21 12:00:58, 05/08/21 12:00:58, **************************** 05/08/21 12:00:58, Starting factorization of 7441641010125238485066955189052433051233165900729353 05/08/21 12:00:58, using pretesting plan: deep 05/08/21 12:00:58, using tune info for qs/gnfs crossover 05/08/21 12:00:58, **************************** 05/08/21 12:00:58, rho: x^2 + 3, starting 1000 iterations on C52 05/08/21 12:00:58, rho: x^2 + 2, starting 1000 iterations on C52 05/08/21 12:00:58, rho: x^2 + 1, starting 1000 iterations on C52 05/08/21 12:00:58, pm1: starting B1 = 150K, B2 = gmpecm default on C52 05/08/21 12:00:58, current ECM pretesting depth: 0.00 05/08/21 12:00:58, scheduled 30 curves at B1=2000 toward target pretesting depth of 17.33 05/08/21 12:00:58, Finished 30 curves using GMPECM method on C52 input, B1=2k, B2=gmpecm default 05/08/21 12:00:58, current ECM pretesting depth: 15.18 05/08/21 12:00:58, scheduled 33 curves at B1=11000 toward target pretesting depth of 17.33 05/08/21 12:00:59, Finished 33 curves using GMPECM method on C52 input, B1=11k, B2=gmpecm default 05/08/21 12:00:59, final ECM pretested depth: 17.41 05/08/21 12:00:59, scheduler: switching to sieve method 05/08/21 12:00:59, starting SIQS on c52: 7441641010125238485066955189052433051233165900729353 05/08/21 12:00:59, random seed: 271793012 [/code] What could be causing this? 
Thanks for the report. I found the problem, will update github tonight.

Updated .exe, version 2.02, works for me for both inputs now.

Super slow SIQS job
Version 2.02. Is this a bug, or is this number just extra hard to SIQS?
[code]starting SIQS on c102: 587798871182819125651887557119241311895329541639294971678415636172181853499307568869458721586841379351 input from file = 14250842901942372507862702317705623516368553484793953297942917764303309346251613 input to yafu = 587798871182819125651887557119241311895329541639294971678415636172181853499307568869458721586841379351 assigning tdiv_medprimes_32k_avx2 ptr assigning tdiv_LP_avx2 ptr assigning resieve_medprimes_32k_avx2 ptr assigning med_sieveblock_32k_avx2 ptr assigning nextRoots_32k_sse41 ptr fb bounds small: 1024 SPV: 37 10bit: 104 11bit: 160 12bit: 288 13bit: 528 32k div 3: 688 14bit: 976 15bit: 1824 med: 2944 large: 16560 large_x2: 31466 all: 136784 start primes SPV: 251 10bit: 1093 11bit: 2063 12bit: 4099 13bit: 8233 32k div 3: 11083 14bit: 16477 15bit: 33181 med: 57653 large: 393073 large_x2: 786419 all: 3853613 ==== sieve params ==== n = 102 digits, 339 bits factor base: 136784 primes (max prime = 3853613) single large prime cutoff: 4194304 (2^22) double large prime range from 14850333153769 to 1786161908965 DLP MFB = 1.85 allocating 10 large prime slices of factor base buckets hold 2048 elements large prime hashtables have 1966080 bytes using AVX2 enabled 32k sieve core sieve interval: 12 blocks of size 32768 polynomial A has ~ 13 factors using multiplier of 1 using SPV correction of 21 bits, starting at offset 37 trial factoring cutoff at 100 bits ==== sieving in progress ( 8 threads): 136848 relations needed ==== ==== Press ctrlc to abort and save state ==== 30849 rels found: 29856 full + 993 from 4937 partial, ( 13.40 rels/sec)[/code]Notice how slow it's going (13.4 rels/sec). Definitely not normal for any number, especially <120 digits (my qs/nfs cutoff is about 107 digits). Also, if I hit Ctrl+C, it acts like it's going to stop and save progress, but then it resumes SIQS, and hitting Ctrl+C after that results in the same thing happening, ad infinitium. 
This composite shut down YAFU 2.0:
[CODE]05/23/21 17:33:05, 05/23/21 17:33:05, **************************** 05/23/21 17:33:05, Starting factorization of 103308857900791703352287869169508708227648131233709032715890962117020801090916449 05/23/21 17:33:05, using pretesting plan: normal 05/23/21 17:33:05, using tune info for qs/gnfs crossover 05/23/21 17:33:05, **************************** 05/23/21 17:33:05, rho: x^2 + 3, starting 1000 iterations on C81 05/23/21 17:33:05, rho: x^2 + 2, starting 1000 iterations on C81 05/23/21 17:33:05, rho: x^2 + 1, starting 1000 iterations on C81 05/23/21 17:33:06, pm1: starting B1 = 150K, B2 = gmpecm default on C81 05/23/21 17:33:06, current ECM pretesting depth: 0.00 05/23/21 17:33:06, scheduled 30 curves at B1=2000 toward target pretesting depth of 24.92 05/23/21 17:33:06, prp13 = 3872943390781 (curve 6 stg1 B1=2000 sigma=970380758 thread=0) 05/23/21 17:33:06, Finished 5 curves using GMPECM method on C81 input, B1=2k, B2=gmpecm default 05/23/21 17:33:06, current ECM pretesting depth: 0.00 05/23/21 17:33:06, scheduled 25 curves at B1=2000 toward target pretesting depth of 20.92 05/23/21 17:33:06, Finished 25 curves using GMPECM method on C68 input, B1=2k, B2=gmpecm default 05/23/21 17:33:06, current ECM pretesting depth: 15.18 05/23/21 17:33:06, scheduled 74 curves at B1=11000 toward target pretesting depth of 20.92 05/23/21 17:33:10, Finished 74 curves using GMPECM method on C68 input, B1=11k, B2=gmpecm default 05/23/21 17:33:10, current ECM pretesting depth: 20.24 05/23/21 17:33:10, scheduled 30 curves at B1=50000 toward target pretesting depth of 20.92 05/23/21 17:33:11, prp21 = 218508274628377506823 (curve 9 stg2 B1=50000 sigma=2404298899 thread=0) 05/23/21 17:33:11, Finished 8 curves using GMPECM method on C68 input, B1=50k, B2=gmpecm default 05/23/21 17:33:11, final ECM pretested depth: 20.43 05/23/21 17:33:11, scheduler: switching to sieve method 05/23/21 17:33:11, starting SIQS on c48: 122075503284873779273269492531896208174435532323 05/23/21 17:33:11, random seed: 673297527610098076 05/23/21 17:33:11, prp48 = 122075503284873779273269492531896208174435532323 05/23/21 17:33:11, Total factoring time = 6.8201 seconds 05/23/21 17:34:13, 05/23/21 17:34:13, **************************** 05/23/21 17:34:13, Starting factorization of 273968285551543561558929035118492073468079807518167517816153740095519155430779807 05/23/21 17:34:13, using pretesting plan: normal 05/23/21 17:34:13, using tune info for qs/gnfs crossover 05/23/21 17:34:13, **************************** 05/23/21 17:34:13, rho: x^2 + 3, starting 1000 iterations on C81 05/23/21 17:34:14, rho: x^2 + 2, starting 1000 iterations on C81 05/23/21 17:34:14, rho: x^2 + 1, starting 1000 iterations on C81 05/23/21 17:34:14, pm1: starting B1 = 150K, B2 = gmpecm default on C81 05/23/21 17:34:15, c38 = 48704721444132343902237399692386801093 05/23/21 17:34:15, final ECM pretested depth: 0.00 05/23/21 17:34:15, scheduler: switching to sieve method 05/23/21 17:34:15, starting SIQS on c43: 5625086797094281224029938254545114665121299 05/23/21 17:34:15, random seed: 673297527610098076 05/23/21 17:34:15, prp43 = 5625086797094281224029938254545114665121299 05/23/21 17:34:15, 05/23/21 17:34:15, **************************** 05/23/21 17:34:15, Starting factorization of 48704721444132343902237399692386801093 05/23/21 17:34:15, using pretesting plan: normal 05/23/21 17:34:15, no tune info: using qs/gnfs crossover of 95 digits 05/23/21 17:34:15, no tune info: using qs/snfs crossover of 75 digits 05/23/21 17:34:15, **************************** 05/23/21 17:34:15, rho: x^2 + 3, starting 1000 iterations on C38 05/23/21 17:34:15, rho: x^2 + 2, starting 1000 iterations on C38 05/23/21 17:34:15, rho: x^2 + 1, starting 1000 iterations on C38 05/23/21 17:34:15, final ECM pretested depth: 0.00 05/23/21 17:34:15, scheduler: switching to sieve method 05/23/21 17:34:15, starting SIQS on c38: 48704721444132343902237399692386801093 05/23/21 17:34:15, random seed: 16249113150029718896[/CODE] 
[QUOTE=richs;578962]This composite shut down YAFU 2.0:
[/QUOTE] Are you sure you have the latest executable version 2.02? It works for me in every version I can test with 2.02. 
[QUOTE=Stargate38;578815]Version 2.02. Is this a bug, or is this number just extra hard to SIQS?
... Definitely not normal for any number, especially <120 digits (my qs/nfs cutoff is about 107 digits). [/QUOTE] Thanks. Yeah, that's a bug... it is using (kind of) a table of parameters for TLP when it shouldn't be. I will upload a new executable tonight. [QUOTE=Stargate38;578815] Also, if I hit Ctrl+C, it acts like it's going to stop and save progress, but then it resumes SIQS, and hitting Ctrl+C after that results in the same thing happening, ad infinitium.[/QUOTE] You need to hit Ctrl+C twice somewhat rapidly. If it doesn't detect a second Ctrl+C soon enough it will resume. 
[QUOTE=bsquared;578977]Are you sure you have the latest executable version 2.02? It works for me in every version I can test with 2.02.[/QUOTE]
It works fine with 2.02. I was using 2.0 for that run. Sorry for the trouble. 
This C104 locks up my Windows 10 laptop:
[CODE]Applying tune_info entry for WIN64  Intel(R) Core(TM) i710510U CPU @ 1.80GHz YAFU Version 2.02 Built with Microsoft Visual Studio 1928 Using GMPECM 7.0.4, Powered by MPIR 3.0.0 Detected Intel(R) Core(TM) i710510U CPU @ 1.80GHz Detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes Using 1 random witness for RabinMiller PRP checks Cached 664579 primes; max prime is 9999991 =============================================================== ======= Welcome to YAFU (Yet Another Factoring Utility) ======= ======= bbuhrow@gmail.com ======= ======= Type help at any time, or quit to quit ======= =============================================================== >> siqs (57101411218654014741793559578775000033369536827633664601791874261717679856288033051871376889825129117307) starting SIQS on c104: 57101411218654014741793559578775000033369536827633664601791874261717679856288033051871376889825129117307 05/24/21 13:27:01, multiplying 0 primes from 4353163 to 1398101[/CODE] Nothing happens after this and I have to shut it down. Same thing happens with YAFU 2.0. SIQS on this number runs fine on YAFU 1.0. 
[QUOTE=richs;578987]This C104 locks up my Windows 10 laptop:
Nothing happens after this and I have to shut it down. Same thing happens with YAFU 2.0. SIQS on this number runs fine on YAFU 1.0.[/QUOTE] Thanks for the report. This is due to the same bug Stargate reported and will be fixed after I'm able to rebuild the project tonight. 
All times are UTC. The time now is 22:19. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.