GMPECM fails on step 2 with B2 > 96M
This is using Jeff Gilchrist's 64bit Windows binary. It causes an AppCrash; no error message in the terminal.
[code]C:\Users\owner>ecm 220000 96000000 < worktodo.ini GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is 1367068808251152599825394438427050917834684642916714302956759433 86422659594169058181440482075770537702060920760622000611512112885689065092620523 67086659406684660725406254868457237857013392598889109586963845751962788430485745 46480919063486896437937504504918609630553338723042546990948035302151882510393267 90936647157153998296243151854164728032282229395280189647684579768987768465433627 26327994194404647247677789401390767522962971310416367164097299697923480332418205 47010144853874277914015150711842090339401717108310510152579121327166001211194406 72925246514490069720038091747256362721224766490216603 (597 digits) Using B1=220000, B2=96985362, polynomial x^2, sigma=821302594 Step 1 took 11278ms Step 2 took 2746ms C:\Users\owner>ecm 220000 97000000 < worktodo.ini GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is 1367068808251152599825394438427050917834684642916714302956759433 86422659594169058181440482075770537702060920760622000611512112885689065092620523 67086659406684660725406254868457237857013392598889109586963845751962788430485745 46480919063486896437937504504918609630553338723042546990948035302151882510393267 90936647157153998296243151854164728032282229395280189647684579768987768465433627 26327994194404647247677789401390767522962971310416367164097299697923480332418205 47010144853874277914015150711842090339401717108310510152579121327166001211194406 72925246514490069720038091747256362721224766490216603 (597 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=686306119 Step 1 took 11622ms[/code] [code]Problem signature: Problem Event Name: APPCRASH Application Name: ecm.exe Application Version: 0.0.0.0 Application Timestamp: 4c5c3146 Fault Module Name: ecm.exe Fault Module Version: 0.0.0.0 Fault Module Timestamp: 4c5c3146 Exception Code: c00000fd Exception Offset: 0000000000090147 OS Version: 6.0.6002.2.2.0.256.6 Locale ID: 1033 Additional Information 1: be3f Additional Information 2: ce5fbab7e41e663636907deea07da3fc Additional Information 3: 3425 Additional Information 4: 69c677deeaef3c7946313b796989e86a[/code] Any ideas? 
Memory usage shouldn't be a problem as only ~30MB.

Hmm, I use [url=http://mersenneforum.org/showpost.php?p=230017&postcount=204]Yamato's binary for ix CPUs[/url]
Even though I have Q6600, it is the fastest binary I encountered. [code]GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is 136706880825115259982539443842705091783468464291671430295675943386422659594169058181440482075770537702060920760622000611512112885689065092620523670866594066846607254062548684572378570133925988891095869638457519627884304857454648091906348689643793750450491860963055333872304254699094803530215188251039326790936647157153998296243151854164728032282229395280189647684579768987768465433627263279941944046472476777894013907675229629713104163671640972996979234803324182054701014485387427791401515071184209033940171710831051015257912132716600121119440672925246514490069720038091747256362721224766490216603 (597 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=2738948513 Step 1 took 14944ms Step 2 took 5320ms Run 2 out of 800: Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=980891661 Step 1 took 14961ms Step 2 took 5288ms Run 3 out of 800: Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=3061363078 Step 1 took 14914ms Step 2 took 5304ms Run 4 out of 800: Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=1692573487 Step 1 took 14898ms Step 2 took 5319ms Run 5 out of 800: Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=3209822111 Step 1 took 14930ms Step 2 took 5335ms Run 6 out of 800: Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=54315659 Step 1 took 14898ms Step 2 took 5288ms Run 7 out of 800: Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=2684259486 Step 1 took 14914ms Step 2 took 5226ms Run 8 out of 800: Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=374069699 Step 1 took 14852ms Step 2 took 5272ms Run 9 out of 800: Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=438075411 Step 1 took 14898ms Step 2 took 5304ms Run 10 out of 800: Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=1278366962[/code] 
I tried all 4 of Jeff's 64bit windows ecm binaries and found that the only one that crashed on my machine was the Ecm 6.3 Win64 Core2 MPIR 2.1.1.
I get the following with: ecm printconfig [CODE]Compilation options: Included GMP header files version 5.0.1 GWNUM_VERSION undefined HAVE_SSE2 undefined HAVE___GMPN_ADD_NC = 1 HAVE___GMPN_MOD_34LSUB1 = 1 HAVE___GMPN_REDC_1 undefined MEMORY_DEBUG undefined NATIVE_REDC = 1 TUNE_MULREDC_THRESH = 20 TUNE_SQRREDC_THRESH = 9 WINDOWS64_ABI undefined WANT_ASSERT undefined WANT_SHELLCMD undefined _OPENMP undefined MPZMOD_THRESHOLD = 249 REDC_THRESHOLD = 506 MUL_NTT_THRESHOLD = 256 NTT_GFP_TWIDDLE_DIF_BREAKOVER = 11 NTT_GFP_TWIDDLE_DIT_BREAKOVER = 11 PREREVERTDIVISION_NTT_THRESHOLD = 16 POLYINVERT_NTT_THRESHOLD = 256 POLYEVALT_NTT_THRESHOLD = 256 MPZSPV_NORMALISE_STRIDE = 128[/CODE] With the version that runs to completion on this number, which is Ecm 6.3 Win64 AMD64 MPIR 2.1.1, ecm printconfig gives: [CODE]Compilation options: Included GMP header files version 5.0.1 GWNUM_VERSION undefined HAVE_SSE2 undefined HAVE___GMPN_ADD_NC = 1 HAVE___GMPN_MOD_34LSUB1 = 1 HAVE___GMPN_REDC_1 undefined MEMORY_DEBUG undefined NATIVE_REDC = 1 TUNE_MULREDC_THRESH = 16 TUNE_SQRREDC_THRESH = 11 WINDOWS64_ABI undefined WANT_ASSERT undefined WANT_SHELLCMD undefined _OPENMP undefined MPZMOD_THRESHOLD = 128 REDC_THRESHOLD = 512 MUL_NTT_THRESHOLD = 256 NTT_GFP_TWIDDLE_DIF_BREAKOVER = 11 NTT_GFP_TWIDDLE_DIT_BREAKOVER = 11 PREREVERTDIVISION_NTT_THRESHOLD = 16 POLYINVERT_NTT_THRESHOLD = 256 POLYEVALT_NTT_THRESHOLD = 128 MPZSPV_NORMALISE_STRIDE = 128[/CODE] I don't know if that can help track down what might be happening. Maybe Jeff can recompile that one with g and run it through a debug session to find out what is happening? 
[QUOTE=henryzz;234827]Memory usage shouldn't be a problem as only ~30MB.[/QUOTE]
I have 4 GB on that machine. It's an i7 920 running Vista Business x64. 
Okay, another piece to the puzzle... This problem seems to be related to the size of the input. If the input is about 596 decimal digits or larger, this binary will silently crash. Here are several examples with the Ecm 6.3 Win64 Core2 MPIR 2.1.1 binary from Jeff's site. You will see those numbers with less than 596 digits always completing. Those over 596 digits always fail. There is one with 596 that finishes and one with 596 that fails. I hope this can help us track down this issue.
[CODE]D:\dir>ecm 220000 97000000 < number.txt GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is (5^8531)/(4*1489354539671) (584 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=2228289258 Step 1 took 12922ms Step 2 took 3984ms D:\dir>ecm 220000 97000000 < number.txt GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is (5^8591)/(4*395839975049) (589 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=1131407194 Step 1 took 12969ms Step 2 took 3937ms D:\dir>ecm 220000 97000000 < number.txt GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is (5^8631)/(4*5179) (599 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=3725603066 Step 1 took 13953ms D:\dir>ecm 220000 97000000 < number.txt GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is (7^7811)/(6*1123*293459*990643452963163*16900214506446855676567 6975247413756542145739) (592 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=896342154 Step 1 took 12938ms Step 2 took 3922ms D:\dir>ecm 220000 97000000 < number.txt GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is (7^7991)/(6*14009*2767631689*14985914192863*52705064796673*1372 2816749522711*63681511996418550459487) (596 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=2035771531 Step 1 took 12969ms Step 2 took 4000ms D:\dir>ecm 220000 97000000 < number.txt GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is (14^5231)/(13) (599 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=3878875125 Step 1 took 13985ms D:\dir>ecm 220000 97000000 < number.txt GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is (14^5211)/(13) (597 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=3694101610 Step 1 took 12906ms D:\dir>ecm 220000 97000000 < number.txt GMPECM 6.3 [configured with GMP 5.0.1 and enableasmredc] [ECM] Input number is (31^4311)/(2*3*5*863*124991*21285367*3105044681*4559973967*1552 37701543) (596 digits) Using B1=220000, B2=119750412, polynomial Dickson(3), sigma=896239599 Step 1 took 12938ms[/CODE] 
Hi All,
Yes, this is a bug in compiling GMPECM on 64bit systems. Some of the code assumes that a 'long' is 64bits on such systems but this is not true on Windows (where a 'long' is 32bits). I have a fix that I will pass to Jeff so that he can update the binaries. Brian 
It's strange that you say that. I have compiled my own 64bit gmpecm 6.3 with GMP 5.0.1 on my 64bit Windows computer. Also, of Jeff's 4 64bit windows binaries, 3 of them don't exhibit this behavior. Is there some code that is only called depending on compile time options that caused this problem? Maybe we should also send this patch up to PaulZ?
I'm glad you were able to find the problem code, I'm just curious why this didn't show up in several other different compiles? 
I have now corrected this bug in the GMPECM subversion repository.
Brian 
Hi WraithX,
The problem was that an intended prototype for an internal function in mul_fft.c had a _PROTO(x) guard around it to cope with very old compilers that don't use function prototypes. For MSVC the code defined _PROTO(x) to nothing so there was no function prototype and the parameters in question were hence assumed to be ordinary ints. The corrected code is: [QUOTE]#ifndef _PROTO #if (__STDC__0)  defined (__cplusplus)  defined( _MSC_VER ) #define _PROTO(x) x #else #define _PROTO(x) () #endif #endif [/QUOTE] so any compiler that doesn't see the first definition of _PROTO(x) is going to have the same problem. I wouldn't do it this way  I would identify any compilers that DON'T use prototypes so that the first form becomes the default rather than the second (obsolete) form. In fact, I don't like forward prototypes, which are very error prone since they are often not updated when a function is changed. So, unless it is impossible, I always put static functions before their first use. But it's not my code so I just fixed it for MSVC :) I have also just added build files for Visual Studio 2010. Brian 
All times are UTC. The time now is 08:20. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2021, Jelsoft Enterprises Ltd.