Finding Wrong Factors
 

One of my machines seems to have been reporting invalid factors for several exponents for about the past week.

For example, trying to Factor=999787769,68,69 it found 311742316172014440111. I tried on another machine and found 311742316172019240401, which PrimeNet accepts as a correct factor.

I have a list of several other exponents that the machine has reported invalid factors for and so far, testing them on another machine, Prime95 is finding factors for all of them (but these factors are not the same as found by the problem machine).

Problem machine is Core2Quad running mprime 25.11 64-bit on Ubuntu 10.04. I think the problem started last Friday either during or after upgrading Ubuntu.

Has anyone else seen anything like this?



Addition: There is a pattern with the invalid factors. In the last seven digits of each invalid factor, the last three digits are always the same and the first three are always the same.

Samples
 

[FONT=Courier New][B]Exponent, B1,B2,ValidResult, InvalidResult[/B]
[/FONT][FONT=Courier New] 999787909,68,69,364402019246111335271,364402019246113335111[/FONT]
[FONT=Courier New]999716329,67,68,283325467725791515751,283325467725791115111
999716857,66,68,145165997612689815431,145165997612681115111
999717847,66,68,92591053177289526719,92591053177282226999
999251047,64,66,29719878604475321761,29719878604472221111
999251849,65,66,65825810769585187513,65825810769588887333
999252487,64,66,24647063161392847729,24647063161394447999
999253403,65,66,44269948430491857209,44269948430495557999
999254323,65,66,39011818845866218711,39011818845861118111
999255583,64,66,18915642833869934351,18915642833863334111
999257041,64,66,25428544219525899913,25428544219529999333
999257953,64,66,32968409107927176953,32968409107927776333
999258649,65,66,58752059026124461463,58752059026126661333
999260393,64,66,23349847179324681097,23349847179328881777
999260429,64,66,23661497880754771511,23661497880757771111
999261217,64,66,36307571671942157641,36307571671945557111
999261707,65,66,46750191615520862393,46750191615526662333
999262037,64,66,23895719937861499367,23895719937869999777
999262283,65,66,42606646060109502097,42606646060100002777
999262631,64,66,32822562818452800359,32822562818450000999
999263149,64,66,22448473454513813969,22448473454511113999
999266251,65,66,66870317015175339073,66870317015173339333
999266423,64,66,31741872264610755119,31741872264615555999
999266777,65,66,45512757982714266191,45512757982716666111
999266977,64,66,27550584757295047969,27550584757294447999
999270637,65,66,53058372939852700001,53058372939850000111
999271159,65,66,66535988907000045007,66535988907004445777
999272783,64,66,23521656269340045679,23521656269344445999
999274337,65,66,37498518416066705369,37498518416060005999
999276263,64,66,25049443710474931151,25049443710473331111
999279923,65,66,49038501027976076311,49038501027977776111
999280829,65,66,72060146189774967767,72060146189776667777
999284873,64,66,33967769329248966287,33967769329246666777
999285181,64,66,22741625647381979383,22741625647387779333
999286517,64,66,18525141525344525713,18525141525342225333
999287203,64,66,24768613367294831663,24768613367293331333
999288803,64,66,32062439854201483583,32062439854208883333
999290317,64,66,23895568803495442943,23895568803494442333
999292009,64,66,30309933338329653319,30309933338325553999
999293377,65,66,43457038550906883017,43457038550908883777
999293929,65,66,39273076378801673809,39273076378807773999
999296783,64,66,22492927843861912673,22492927843861112333
999297241,64,66,19582088103535274071,19582088103537774111
999297731,64,66,28701964912569773519,28701964912567773999
999299957,64,66,33163716538780200311,33163716538780000111
[/FONT]

Intriguing! The second and third digits (from the right) are replaced by the first digit, and the sixth and seventh digits are replaced by the fifth digit. I don't see how this could be caused by a hardware error. At least your machine is not missing factors, even though the tests have to be rerun on another machine.

Intriguing, indeed!

My top 2 cents is on either a bug or a random byte in the hex-to-decimal conversion function. I'd compare md5-sums of the prime95 executables to see if they match or not.

Here are the checksums from two versions of mprime that I have tried. Both versions find bad factors.


mprime from mprime259-linux64.tar.gz[INDENT] md5sum d268e83943cd1c32fa53854766eae2ba
sha1sum b3e1b636f02c5f26a8c19e75e59b23c605ae2e69
[/INDENT]mprime from mprime2511-linux64.tar.gz[INDENT] md5sum 5a0070a4f93b4f39cf6b9fb0020f3030
sha1sum 72ee20dee3004c6dae792497f801f37afb981710[/INDENT]

[quote=lindee;216524]Here are the checksums from two versions of mprime that I have tried. Both versions find bad factors.


mprime from mprime259-linux64.tar.gz[INDENT] md5sum d268e83943cd1c32fa53854766eae2ba
sha1sum b3e1b636f02c5f26a8c19e75e59b23c605ae2e69
[/INDENT]mprime from mprime2511-linux64.tar.gz[INDENT] md5sum 5a0070a4f93b4f39cf6b9fb0020f3030
sha1sum 72ee20dee3004c6dae792497f801f37afb981710[/INDENT][/quote]

I actually meant comparing the executable in the .tar with the one installed, but since you've run both versions and both display the factors incorrectly, that cannot be it!

What about a bug in a shared library? I have no idea which libraries mprime is dynamically linked with, but if I'm right, then reinstalling/upgrading e.g. glibc should fix the problem.

There were some updates available, so I installed and rebooted. Still no luck.

Here's my current libc information (selected output from 'dpkg -l | grep libc'):

ii libc-bin 2.11.1-0ubuntu7.1 Embedded GNU C Library: Binaries
ii libc-dev-bin 2.11.1-0ubuntu7.1 Embedded GNU C Library: Development binaries
ii libc6 2.11.1-0ubuntu7.1 Embedded GNU C Library: Shared libraries
ii libc6-dev 2.11.1-0ubuntu7.1 Embedded GNU C Library: Development Librarie

What happens if you boot using a 64-bit live-CD from a different distro, run mprime (should have no errors), chroot, and run mprime again?

[QUOTE=__HRB__;216534]What happens if you boot using a 64-bit live-CD from a different distro, run mprime (should have no errors), chroot, and run mprime again?[/QUOTE]

Someone else should try to rerun those factors. could be something about the large exponents, maybe only on linux 64

[QUOTE=lfm;216595]Someone else should try to rerun those factors. could be something about the large exponents, maybe only on linux 64[/QUOTE]
64 bit mprime (both v25.11 build 2 and v25.9 build 4) found the correct factors in Ubuntu 9.04 64-bit on a Core2Quad Q9400.

[quote=lindee;216490]Problem machine is Core2Quad running mprime 25.11 64-bit on Ubuntu 10.04. I think the problem started last Friday either during or after upgrading Ubuntu.[/quote]

[quote=markr;216612]64 bit mprime (both v25.11 build 2 and v25.9 build 4) found the correct factors in Ubuntu 9.04 64-bit on a Core2Quad Q9400.[/quote]

I think that settles that we're not following in Thomas R. Nicely's footsteps. My bottom dollar is on a bug in a shared library in the (or your) Ubuntu installation/configuration.

64bit Prime95 25.11.2 finds the correct factors on Windows XP 64bit.

[quote=__HRB__;216534]What happens if you boot using a 64-bit live-CD from a different distro, run mprime (should have no errors), chroot, and run mprime again?[/quote]


Using the previous Ubuntu 9.10 disc, I mounted the local partition and tested one of the exponents; mprime returned the correct factor. When I chroot and run it again, mprime returns the incorrect factor.

[quote=lindee;216725]Using the previous Ubuntu 9.10 disc, I mounted the local partition and tested one of the exponents; mprime returned the correct factor. When I chroot and run it again, mprime returns the incorrect factor.[/quote]

[quote=__HRB__;216680]My bottom dollar is on a bug in a shared library in the (or your) Ubuntu installation/configuration.[/quote]

Maybe I should leverage my bottom dollar. :-)

Just created a virtual machine (on different hardware) and did a fresh install of Ubuntu 10.04 64-bit. The problem exists here as well.

[quote=lindee;216731]Just created a virtual machine (on different hardware) and did a fresh install of Ubuntu 10.04 64-bit. The problem exists here as well.[/quote]
Could you do a similar test with 9.10 or earlier(earlier than 8.04 would be a bit early)?

I performed the same test on the VM as suggested by _HRB_ and the results were the same as the original problem PC. Booting into Ubuntu 9.10 and running mprime found the correct factor. Doing a chroot to the Ubuntu 10.04 installation resulted in mprime returning the wrong factor.

I am currently downloading the 32-bit version of Ubuntu 10.04 to see whether or not this bug is limited to just the 64-bit version.

[quote=lindee;216951]I performed the same test on the VM as suggested by _HRB_ and the results were the same as the original problem PC. Booting into Ubuntu 9.10 and running mprime found the correct factor. Doing a chroot to the Ubuntu 10.04 installation resulted in mprime returning the wrong factor.

I am currently downloading the 32-bit version of Ubuntu 10.04 to see whether or not this bug is limited to just the 64-bit version.[/quote]
sorry i didn't notice you had tried 9.10
comes of being away for a couple of weeks

On the 32-bit Ubuntu 10.04, mprime found the correct factor.

ditto.
 

[quote=lindee;216490]One of my machines seems to have been reporting invalid factors for several exponents for about the past week.

[...]

Problem machine is Core2Quad running mprime 25.11 64-bit on Ubuntu 10.04. I think the problem started last Friday either during or after upgrading Ubuntu.

Has anyone else seen anything like this?



Addition: There is a pattern with the invalid factors. In the last seven digits of each invalid factor, the last three digits are always the same and the first three are always the same.[/quote]

Same problem here. Q6600, Ubuntu Lucid x64, mprime 25.11 x64.

83 exponents affected over the last 43 days. Range=90-91M, depth=64-65 bits.

Will rerun those expos under Windoze as resources permit.



Cheers,

Carsten

No need to rerun them; the first sixteen-or-so digits are right and you know the value has to be 1 mod p, so a very quick search around the wrong answer will give the right one. Post exponents and wrong factors here and I will post correct factors

Any volunteers to debug this? Look in the gtoc routine in gwnum/giants.c

Potentially related worktodo.txt parsing bug:

[code]
kossy@leela:~/leelaTF$ tail worktodo.txt
ECM2=N/A,1,2,4649153,-1,50000,5000000,1
ECM2=N/A,1,2,4649189,-1,50000,5000000,1
ECM2=N/A,1,2,4649191,-1,50000,5000000,1
ECM2=N/A,1,2,4649209,-1,50000,5000000,1
ECM2=N/A,1,2,4649219,-1,50000,5000000,1
ECM2=N/A,1,2,4649231,-1,50000,5000000,1
ECM2=N/A,1,2,4649261,-1,50000,5000000,1

#eof

kossy@leela:~/leelaTF$ ./mprime -s

[...]

[Main thread Jun 8 08:10] Illegal line in worktodo.txt file: ECM2=1,2,4649153[COLOR=Red]5[/COLOR]-1,50000,5000000,1
[Main thread Jun 8 08:10] Illegal line in worktodo.txt file: ECM2=1,2,4649189[COLOR=Red]5[/COLOR]-1,50000,5000000,1
[Main thread Jun 8 08:10] Illegal line in worktodo.txt file: ECM2=1,2,4649191[COLOR=Red]5[/COLOR]-1,50000,5000000,1
[Main thread Jun 8 08:10] Illegal line in worktodo.txt file: ECM2=1,2,4649209[COLOR=Red]5[/COLOR]-1,50000,5000000,1
[Main thread Jun 8 08:10] Illegal line in worktodo.txt file: ECM2=1,2,4649219[COLOR=Red]5[/COLOR]-1,50000,5000000,1
[Main thread Jun 8 08:10] Illegal line in worktodo.txt file: ECM2=1,2,4649231[COLOR=Red]5[/COLOR]-1,50000,5000000,1
[Main thread Jun 8 08:10] Illegal line in worktodo.txt file: ECM2=1,2,4649261[COLOR=Red]5[/COLOR]-1,50000,5000000,1
Below is a report on the work you have queued and any expected completion
dates.
[Worker thread #1]
No work queued up.
[Worker thread #2]
No work queued up.
[Worker thread #3]
No work queued up.
[Worker thread #4]
No work queued up.

kossy@leela:~/leelaTF$
[/code]Again: Q6600, Ubuntu Lucid x64, mprime 25.11 x64

[QUOTE=lindee;216490]One of my machines seems to have been reporting invalid factors for several exponents for about the past week.

For example, trying to Factor=999787769,68,69 it found 311742316172014440111. I tried on another machine and found 311742316172019240401, which PrimeNet accepts as a correct factor.[/QUOTE]

Fixed in 26.3

[QUOTE=ckdo;217770]Potentially related worktodo.txt parsing bug:[/QUOTE]

Fixed in 26.3

Great news! :fusion:

Same problem with Ubuntu 10.10 64 bit
 

Hi, I've got the same problem with finding a factor, but reporting a wrong one. The problem is with 64bit Ubuntu 10.10 and Prime95 v25.11. I saw that there is 26.3, which might fix it. Does it work with this one?
Another problem is that I still report my factors as ANONYMOUS, no mater what I do it is still under that name. Since it does not credit my account this issue annoys me. I hope someone could help me, otherwise an quadcore is lost for the project.

It does, and 26.4 is current.

Thanks! Any idea about the problem with the anonymousness? How to correct this.

[QUOTE=bloodIce;239744]Thanks! Any idea about the problem with the anonymousness? How to correct this.[/QUOTE]

Insert your v5UserID in prime.txt

for example:
V5UserID=your_mersenne.org_account_login

and insert your ComputerID in local.txt

ComputerID=your_computer_name

but first create the v5userid

[URL]http://v5www.mersenne.org/update/[/URL]

[QUOTE=bloodIce;239744]Thanks! Any idea about the problem with the anonymousness? How to correct this.[/QUOTE]
While you're on the [url]http://www.mersenne.org/update/[/url] page, check if you have a "public name". If you don't, your results will show as by anonymous to others, which includes you when you're not logged in.

After doing as moebius suggests, check that new results show up at [url]http://www.mersenne.org/results/[/url]. For that matter, do your older results appear there now?

Thank you for the help moebius and markr. Actually that was exactly what I was doing. However it did not work until I discovered the reason. My mistake was that after uncompressing the files I run the program directly from the folder's window. That creates the prime.txt and local.txt as ANONYMOUS and even if you change your details later I does not work. The way to go is after decompressing to run the program from a terminal window and answer patiently to all questions. After that the proper account is created with the correct details and assignments. What I recommend is to include that information in readme.txt or somewhere else, because in point-and-click generation the terminal window is an unnecessary hassle and is usually avoided. It should be stressed out that the way to go is through a terminal. A nice startup file could be added to the compressed pack also. And yes I have had an account for a year now and 5 computers with different operational systems, I was not complete newbie. Greets and thanks again.