20220517, 14:13  #628 
"Mark"
Apr 2003
Between here and the
15031_{8} Posts 
I tried switching to the cygwin g++ compiler, but it won't link. It appears to be a bug in primesieve or the linker or compiler used by cygwin. So I am now trying to use the llvmmingw compiler. It appears that I can debug with lldb or gdb for programs built on it.
This will require a bit of testing. It seems to crash when resetting the rounding mode for SSE, but only one sieve uses SSE, so I will probably just modify that sieve to use different logic and thus remove SSE assembler completely from the code. It is possible that something else I changed between releases triggered this crash, but it is odd that only srsieve2 seems to be affected by it. Without use of gdb on msys2 builds, I cannot diagnose the root cause of the crash. 
20220523, 13:30  #629 
Jun 2012
Boulder, CO
409 Posts 
Found what seems to be a bug in the latest SVN code. I have not had time to recompile or test with gdb.
Code:
$ ./srsieve2 P 1e14 W 64 s "39*2^n+1" o ferm39_10M_20M_sv1e14.txt n 10e6 N 20e6 srsieve2 v1.6.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic for p >= 3 Sieve started: 3 < p < 1e14 with 10000001 terms (10000000 < n < 20000000, k*2^n+1) (expecting 9659200 factors) Sieving with single sequence c=1 logic for p >= 257 BASE_MULTIPLE = 30, POWER_RESIDUE_LCM = 720, LIMIT_BASE = 720 Split 1 base 2 sequence into 408 base 2^720 sequences. Legendre summary: Approximately 40 B needed for Legendre tables 1 total sequences 1 are eligible for Legendre tables 0 are not eligible for Legendre tables 1 have Legendre tables in memory 0 cannot have Legendre tables in memory 0 have Legendre tables loaded from files 1 required building of the Legendre tables 518400 bytes used for congruent q and ladder indices 311200 bytes used for congruent qs and ladders Unable to lock mutex thread_6_worker. Exiting. Last fiddled with by ryanp on 20220523 at 13:31 Reason: added some details 
20220523, 15:00  #630  
"Mark"
Apr 2003
Between here and the
3·17·131 Posts 
Quote:
I do not recall if sr1sieve is faster (compared to srsieve2). I know it is slower than srsieve2cl. Last fiddled with by rogue on 20220523 at 15:13 

20220523, 17:16  #631  
Jun 2012
Boulder, CO
199_{16} Posts 
Quote:
* it fails consistently and only with s "39*2^n+1" * it fails with even W 4, though this produces: Code:
518400 bytes used for congruent q and ladder indices 311200 bytes used for congruent qs and ladders corrupted size vs. prev_size Aborted Code:
518400 bytes used for congruent q and ladder indices 311200 bytes used for congruent qs and ladders srsieve2: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex>__data.__owner == 0' failed. Aborted Code:
[New Thread 0x7ffff6ef9640 (LWP 206359)] [New Thread 0x7ffff5ef7640 (LWP 206360)] corrupted size vs. prev_size Thread 1 "srsieve2" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 49 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #1 0x00007ffff7a4a546 in __GI_abort () at abort.c:79 #2 0x00007ffff7aa1eb8 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7bbfa78 "%s\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x00007ffff7aa991a in malloc_printerr ( str=str@entry=0x7ffff7bbd714 "corrupted size vs. prev_size") at malloc.c:5628 #4 0x00007ffff7aaa816 in unlink_chunk (p=p@entry=0x5555555f9e00, av=<optimized out>) at malloc.c:1608 #5 0x00007ffff7aad24a in _int_malloc ( av=av@entry=0x7ffff7bf6ba0 <main_arena>, bytes=bytes@entry=112) at malloc.c:4263 #6 0x00007ffff7aae4b1 in __GI___libc_malloc (bytes=112) at malloc.c:3237 #7 0x00007ffff7e0e6bc in operator new(unsigned long) () from /lib/x86_64linuxgnu/libstdc++.so.6 #8 0x000055555556f308 in __gnu_cxx::new_allocator<primesieve::SievingPrime>::allocate (this=0x7fffffffd5f0, __n=14) at /usr/include/c++/11/ext/new_allocator.h:127 #9 0x000055555556efb2 in std::allocator_traits<std::allocator<primesieve::SievingPrime> >::allocate (__a=..., __n=14) at /usr/include/c++/11/bits/alloc_traits.h:464 #10 0x000055555556ea3c in std::_Vector_base<primesieve::SievingPrime, std::allocator<primesieve::SievingPrime> >::_M_allocate (this=0x7fffffffd5f0, __n=14) at /usr/include/c++/11/bits/stl_vector.h:346 #11 0x000055555556e6c4 in std::vector<primesieve::SievingPrime, std::allocator<primesieve::SievingPrime> >::reserve (this=0x7fffffffd5f0, __n=14) at /usr/include/c++/11/bits/vector.tcc:78 #12 0x000055555556ba1c in primesieve::EratSmall::init (this=0x7fffffffd5d0, stop=1021020, l1CacheSize=17017, maxPrime=17) at sieve/EratSmall.cpp:57 #13 0x000055555556f9d4 in primesieve::PreSieve::initBuffer ( this=0x55555583efd8, maxPrime=17, primeProduct=510510) at sieve/PreSieve.cpp:86 #14 0x000055555556f8dc in primesieve::PreSieve::init (this=0x55555583efd8, start=11924379, stop=23704475) at sieve/PreSieve.cpp:68 #15 0x0000555555564079 in primesieve::Erat::init (this=0x55555583ec70, start=11924379, stop=23704475, sieveSize=512, preSieve=...) at sieve/Erat.cpp:79 #16 0x000055555557793b in primesieve::PrimeGenerator::initErat ( this=0x55555583ec70) at sieve/PrimeGenerator.cpp:159 #17 0x00005555555778ad in primesieve::PrimeGenerator::init ( this=0x55555583ec70, primes=std::vector of length 256, capacity 256 = {...}, size=0x7fffffffd8f8) at sieve/PrimeGenerator.cpp:147 #18 0x0000555555577bab in primesieve::PrimeGenerator::sieveSegment ( this=0x55555583ec70, primes=std::vector of length 256, capacity 256 = {...}, size=0x7fffffffd8f8) at sieve/PrimeGenerator.cpp:232 #19 0x0000555555577d56 in primesieve::PrimeGenerator::fill ( this=0x55555583ec70, primes=std::vector of length 256, capacity 256 = {...}, size=0x7fffffffd8f8) at sieve/PrimeGenerator.cpp:291 #20 0x00005555555850d5 in primesieve::iterator::generate_next_primes ( this=0x7fffffffd8f0) at sieve/iterator.cpp:67 #21 0x0000555555560110 in primesieve::iterator::next_prime ( this=0x7fffffffd8f0) at sieve/primesieve/iterator.hpp:69 #22 0x0000555555560632 in primesieve::store_n_primes<std::vector<unsigned long, std::allocator<unsigned long> > > (n=216804, start=1257, primes=std::vector of length 783196, capacity 1000000 = {...}) at sieve/primesieve/StorePrimes.hpp:87 #23 0x000055555556028c in primesieve::generate_n_primes<unsigned long> ( n=1000000, start=1258, primes=0x5555556fb390) at core/../sieve/primesieve.hpp:62 #24 0x0000555555561fff in Worker::ProcessNextPrimeChunk (this=0x5555556fb380, startFrom=1257, maxPrimeForChunk=1257) at core/Worker.cpp:155 #25 0x000055555555cbe1 in App::Sieve (this=0x5555555d98e0) at core/App.cpp:450 #26 0x000055555555ca3b in App::Run (this=0x5555555d98e0) at core/App.cpp:405 #27 0x0000555555563288 in main (argc=13, argv=0x7fffffffdba8) at core/main.cpp:87 Last fiddled with by ryanp on 20220523 at 17:18 Reason: add gdb backtrace 

20220523, 18:15  #632 
Dec 2011
After milion nines:)
2·19·41 Posts 
What is range of n?
[QUOTE=ryanp;606344]I've been able to repro this on multiple machines. Observations: * it fails consistently and only with s "39*2^n+1" * it fails with even W 4, though this produces: [ Last fiddled with by pepi37 on 20220523 at 18:48 
20220523, 19:29  #633 
"Mark"
Apr 2003
Between here and the
3×17×131 Posts 
When I have some time I will play around with this using the latest build as it uses a different compiler. I have also upgraded to the latest primesieve code. One of those changes might fix this issue.

20220523, 21:58  #634 
Dec 2011
After milion nines:)
3026_{8} Posts 
fix for problem (temporary)
Make initial sieve with srsieve use srsieve2 version 1.5.3 working on 6 core CPU without problem srsieve2 P 1446900638801 W 6 w5e6 i a.txt o b.txt O fact39.txt srsieve2 v1.5.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic for p >= 100000000 Split 1 base 2 sequence into 204 base 2^360 sequences. 712822 bytes used for congruence tables 522 bytes used for Legendre tables Sieve started: 1e8 < p < 1446900638801 with 1353444 terms (11924391 < n < 23704473, k*2^n+1) (expecting 463052 factors) p=731561923, 679.7K p/sec, 142804 factors found at 476.8 f/sec (last 1 min), 0.0% done. ETC 20220525 14:45 
20220523, 22:00  #635  
Dec 2011
After milion nines:)
2·19·41 Posts 
Quote:
I noticed this on 12 core Ryzen ( HT is off) When I set 12 cores I only have 785% CPU utilization ( Linux) 

20220525, 23:37  #636 
"AMD YES!"
Jan 2020
Bellevue, WA
2×41 Posts 
sgsieve returning CC 2nd kind numbers in sieve file
Hi rogue,
I used the sgsieve program (part of mtsieve) in order to sieve for my SG search. This is a sample command that I used: sgsieve P 10e13 workers=5 w1e7 k 3 K 2500000000 n 143106 outputterms=143105.txt f NEWPGEN However, when I opened my sieve file, I see the first line (for the example above): 100000000000067:C:0:2:5 According to the LLR documentation, the C indicates that the sieve file wants LLR to search "CC 2nd kind len 2", which isn't what I asked the sieve to produce. However, the numbers do come out to match the sg criteria (both the original prime and the tobe sg prime are in +1 form). Could you explain why the sieve sieves for +1 candidates instead of the vast majority of 1 primes seen on t5k? Thank you, Daniel Last fiddled with by dannyridel on 20220525 at 23:43 
20220526, 12:14  #637  
"Mark"
Apr 2003
Between here and the
3·17·131 Posts 
Quote:
Cunningham Chain of the first kind of length 2: A prime p is said to be a Sophie Germain prime if both p and 2p+1 are prime. Cunningham Chain of the second kind of length 2: A prime p is said to be a Sophie Germain prime if both p and 2p1 are prime. You can see that the first two are the same. A "C" in newpgen formst corresponds to that. You can run newgpen yourself and discover that. newpgen can also sieve for Sophie Germain, but it uses p of the form k*2^n1. sgsieve uses with p of the form k*2^n+1, since the main code originated from gfndsieve. I can look into changing sgsieve to support either +1 or 1 terms for p. 

20220527, 04:27  #638 
"AMD YES!"
Jan 2020
Bellevue, WA
2·41 Posts 
So in essence, both types of Cunningham Chains, if they result in prime pairs, can count as SG pairs? Eg. SG pairs can be either (p,2p1) or (p,2p+1)?
Also, doesn't a C in newpgen correspond to CC 2nd kind? And S corresponds to first kind/SG? 