mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > YAFU

Reply
 
Thread Tools
Old 2013-03-18, 17:00   #1
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

10001100110102 Posts
Default nextprime() appears to be limited...

There I was, thinking of being a smarta$$ in another thread, by proclaiming that there was nothing special about finding a prime of a particular length; just use ./yafu "nextprime(10^<desired length>)" and wait... when testing proved my theory to be false. nextprime() appears to have a limit on one of my machines:
Code:
$ ./yafu "nextprime(10^1945)"

ans = 1000...<lots more zeroes>...0005643
Code:
]$ ./yafu "nextprime(10^1946)"

*** glibc detected *** ./yafu: free(): invalid next size (normal): 0x0000000001d89e50 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3cee87c00e]
./yafu[0x4140df]
./yafu[0x414aad]
./yafu[0x4046a0]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x3cee821735]
./yafu[0x404af1]
======= Memory map: ========
00400000-0051e000 r-xp 00000000 fd:02 15467074                           /home/userID/Math/yafu/yafu
0071d000-00726000 rw-p 0011d000 fd:02 15467074                           /home/userID/Math/yafu/yafu
00726000-0072e000 rw-p 00000000 00:00 0 
01d80000-01db2000 rw-p 00000000 00:00 0                                  [heap]
3cee000000-3cee020000 r-xp 00000000 fd:01 262337                         /usr/lib64/ld-2.15.so
3cee21f000-3cee220000 r--p 0001f000 fd:01 262337                         /usr/lib64/ld-2.15.so
3cee220000-3cee221000 rw-p 00020000 fd:01 262337                         /usr/lib64/ld-2.15.so
3cee221000-3cee222000 rw-p 00000000 00:00 0 
3cee800000-3cee9ac000 r-xp 00000000 fd:01 262369                         /usr/lib64/libc-2.15.so
3cee9ac000-3ceebac000 ---p 001ac000 fd:01 262369                         /usr/lib64/libc-2.15.so
3ceebac000-3ceebb0000 r--p 001ac000 fd:01 262369                         /usr/lib64/libc-2.15.so
3ceebb0000-3ceebb2000 rw-p 001b0000 fd:01 262369                         /usr/lib64/libc-2.15.so
3ceebb2000-3ceebb7000 rw-p 00000000 00:00 0 
3ceec00000-3ceec16000 r-xp 00000000 fd:01 262646                         /usr/lib64/libpthread-2.15.so
3ceec16000-3ceee16000 ---p 00016000 fd:01 262646                         /usr/lib64/libpthread-2.15.so
3ceee16000-3ceee17000 r--p 00016000 fd:01 262646                         /usr/lib64/libpthread-2.15.so
3ceee17000-3ceee18000 rw-p 00017000 fd:01 262646                         /usr/lib64/libpthread-2.15.so
3ceee18000-3ceee1c000 rw-p 00000000 00:00 0 
3cef000000-3cef003000 r-xp 00000000 fd:01 262725                         /usr/lib64/libdl-2.15.so
3cef003000-3cef202000 ---p 00003000 fd:01 262725                         /usr/lib64/libdl-2.15.so
3cef202000-3cef203000 r--p 00002000 fd:01 262725                         /usr/lib64/libdl-2.15.so
3cef203000-3cef204000 rw-p 00003000 fd:01 262725                         /usr/lib64/libdl-2.15.so
3cef400000-3cef407000 r-xp 00000000 fd:01 262815                         /usr/lib64/librt-2.15.so
3cef407000-3cef606000 ---p 00007000 fd:01 262815                         /usr/lib64/librt-2.15.so
3cef606000-3cef607000 r--p 00006000 fd:01 262815                         /usr/lib64/librt-2.15.so
3cef607000-3cef608000 rw-p 00007000 fd:01 262815                         /usr/lib64/librt-2.15.so
3cef800000-3cef8fa000 r-xp 00000000 fd:01 262717                         /usr/lib64/libm-2.15.so
3cef8fa000-3cefaf9000 ---p 000fa000 fd:01 262717                         /usr/lib64/libm-2.15.so
3cefaf9000-3cefafa000 r--p 000f9000 fd:01 262717                         /usr/lib64/libm-2.15.so
3cefafa000-3cefafb000 rw-p 000fa000 fd:01 262717                         /usr/lib64/libm-2.15.so
3cf0c00000-3cf0c15000 r-xp 00000000 fd:01 262762                         /usr/lib64/libgcc_s-4.7.2-20120921.so.1
3cf0c15000-3cf0e14000 ---p 00015000 fd:01 262762                         /usr/lib64/libgcc_s-4.7.2-20120921.so.1
3cf0e14000-3cf0e15000 rw-p 00014000 fd:01 262762                         /usr/lib64/libgcc_s-4.7.2-20120921.so.1
3cf6c00000-3cf6c0e000 r-xp 00000000 fd:01 264214                         /usr/lib64/libgomp.so.1.0.0
3cf6c0e000-3cf6e0d000 ---p 0000e000 fd:01 264214                         /usr/lib64/libgomp.so.1.0.0
3cf6e0d000-3cf6e0e000 rw-p 0000d000 fd:01 264214                         /usr/lib64/libgomp.so.1.0.0
7f6b1c62f000-7f6b1c732000 rw-p 00000000 00:00 0 
7f6b1c732000-7f6b1c79c000 r-xp 00000000 fd:01 142321                     /usr/local/lib/libgmp.so.10.1.1
7f6b1c79c000-7f6b1c99b000 ---p 0006a000 fd:01 142321                     /usr/local/lib/libgmp.so.10.1.1
7f6b1c99b000-7f6b1c9a4000 rw-p 00069000 fd:01 142321                     /usr/local/lib/libgmp.so.10.1.1
7f6b1c9a4000-7f6b1ca00000 r-xp 00000000 fd:01 264906                     /usr/lib64/libecm.so.0.0.0
7f6b1ca00000-7f6b1cbff000 ---p 0005c000 fd:01 264906                     /usr/lib64/libecm.so.0.0.0
7f6b1cbff000-7f6b1cc00000 r--p 0005b000 fd:01 264906                     /usr/lib64/libecm.so.0.0.0
7f6b1cc00000-7f6b1cc09000 rw-p 0005c000 fd:01 264906                     /usr/lib64/libecm.so.0.0.0
7f6b1cc09000-7f6b1cc0a000 rw-p 00000000 00:00 0 
7f6b1cc29000-7f6b1cc2d000 rw-p 00000000 00:00 0 
7fff61a95000-7fff61ab6000 rw-p 00000000 00:00 0                          [stack]
7fff61b96000-7fff61b97000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted
I'm in that waiting part for a couple other machines, since they aren't limited at the same range, if they are limited at all. Should there be a limit to what YAFU's nextprime() can handle, or was my original thought valid?
EdH is offline   Reply With Quote
Old 2013-03-18, 17:15   #2
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

70418 Posts
Default

I love it when people test the functionality of YAFU far beyond anything I've considered using it for. This is sincere - I really do.

I confirm that it does indeed fail for nextprime(10^1946). At a first glace I have no idea why - there's no good reason why it should. Likely it is a problem with my underlying home-grown big integer arithmetic functions. nextprime() is one of the few places where those are still used.

Thanks for the report - I'll see if I can fix it.
bsquared is offline   Reply With Quote
Old 2013-03-18, 18:26   #3
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

2×3×751 Posts
Default

Quote:
Originally Posted by bsquared View Post
I love it when people test the functionality of YAFU far beyond anything I've considered using it for. This is sincere - I really do.

I confirm that it does indeed fail for nextprime(10^1946). At a first glace I have no idea why - there's no good reason why it should. Likely it is a problem with my underlying home-grown big integer arithmetic functions. nextprime() is one of the few places where those are still used.

Thanks for the report - I'll see if I can fix it.
It isn't failing on all my machines. One of them has so far worked up through 10^8000 and another one is still working on 10^10^4. The one that failed is Fedora 17 (AMD) and the two that haven't failed yet are Ubuntu 12.04 (one AMD, one Intel). All are 64-bit. I have another 64 bit with antiX on it that I will play with soon...

Thanks for all......
EdH is offline   Reply With Quote
Old 2013-03-18, 18:30   #4
Dubslow
Basketry That Evening!
 
Dubslow's Avatar
 
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

11100001101012 Posts
Default

Pointers, pointers, pointers.... it's always the bad pointers....
Dubslow is offline   Reply With Quote
Old 2013-03-18, 19:18   #5
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

106328 Posts
Default

My antiX (Intel) failed the same as the Fedora 17...

OTOH, the Ubuntu AMD machine is still working on 10^10^4... or it got lost and can't find its way back to let me know...
EdH is offline   Reply With Quote
Old 2013-03-18, 19:38   #6
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

3,617 Posts
Default

Another way to generate arbitrarily* large primes would be to use

Code:
"testrange(10^1946, 10^1946+10000, 1000000, 2)" -pscreen
increasing from 10000 as necessary.

*limited by your patience and, in extreme cases, your RAM
bsquared is offline   Reply With Quote
Old 2013-03-18, 21:12   #7
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

2×3×751 Posts
Default

The AMD Ubuntu machine has returned successfully from its adventure. I guess I'll have to give a point to Ubuntu in my overall score-keeping. Although I have been swapping to antiX when Ubuntu gives me trouble, in this case, the Ubuntu machines proved superior. They both, one with AMD and one with Intel, succeeded in finishing this task, while Fedora and antiX failed. Perhaps, there's a clue within these details and Dubslow's "point" he was trying to make.

BTW, I'm disappointed no one corrected my earlier error. I think the correct command would be:

./yafu "nextprime(10^<desired length - 1>)

Thanks for all.
EdH is offline   Reply With Quote
Old 2013-03-18, 22:09   #8
Dubslow
Basketry That Evening!
 
Dubslow's Avatar
 
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

3×29×83 Posts
Default

Ugh. The time I remember getting that crash error (invalid free size!) was a time where some other memory, related to but not the same as that being freed, was accidentally being malloc'd wrong: I had
Code:
struct_t** = malloc(n * sizeof(struct_t**));
where really I meant
Code:
struct_t** = malloc(n * sizeof(struct_t*));


I wasted a day of my life and countless Googling and Stack Overflowing tracing down that damned extra asterisk

(Of course, this particular bug crashed the program everytime in the same place -- unlike this problem.)

Last fiddled with by Dubslow on 2013-03-18 at 22:10
Dubslow is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
nextprime function is spooked by leading zero. shortcipher YAFU 5 2018-03-27 13:59
Prime95 appears in Gibberish Skeith Software 18 2017-04-25 04:29
mprime process appears to not be running... starionhost Software 15 2016-03-04 06:29
My v4 credit appears in: uigrad PrimeNet 14 2008-12-31 02:37
ZZMath appears to interfere with Prime95 Joe O Software 0 2003-01-08 23:46

All times are UTC. The time now is 09:34.


Sat May 21 09:34:25 UTC 2022 up 37 days, 7:35, 0 users, load averages: 1.32, 1.18, 1.11

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔