![]() |
![]() |
#1 |
Apr 2011
2·3 Posts |
![]()
Dear all,
I use factmsieve.py to factoring a big N, and it runs very well till the squre root step. The output is as following: Code:
xxx@xxx64:/data/corefile/xxx/factortool/test2> /usr/local/bin/python3 factmsieve2.py test2.n -> ________________________________________________________________ -> | Running factmsieve.py, a Python driver for MSIEVE with GGNFS | -> | sieving support. It is Copyright, 2010, Brian Gladman and is | -> | a conversion of factmsieve.pl that is Copyright, 2004, Chris | -> | Monico. Version 0.76 (Python 2.6 or later) 10th Nov 2010. | -> |______________________________________________________________| test2 -> This is client 1 of 1 -> Running on 4 Cores with 1 hyper-thread per Core -> Working with NAME = test2 -> Selected default factorization parameters for 163 digit level. -> Selected lattice siever: gnfs-lasieve4I15e -> No parameter change detected, resuming... -> Running lattice siever ... -> entering sieving loop -> File 'deps' already exists. Proceeding to sqrt step. -> Running square root step ... /data/corefile/xxx/factortool ./msieve -> ./msieve -s test2/test2.dat -l test2/test2.log -i test2/test2.ini -nf test2/test2.fb -t 4 -nc3 -> Computing 1.30423e+09 scale for this machine... -> procrels -speedtest> PIPE __________________________________________________________ | This is the procrels program for GGNFS. | | Version: 0.77.1-20060722-nocona | | This program is copyright 2004, Chris Monico, and subject| | to the terms of the GNU General Public License version 2.| |__________________________________________________________| b[a%1024] = 00000000 timeunit: 2.063 Traceback (most recent call last): File "factmsieve2.py", line 2124, in <module> output_summary(NAME, fact_p, pols_p, poly_p, lats_p) File "factmsieve2.py", line 1807, in output_summary tmp = grep_l('timeunit:', res) File "factmsieve2.py", line 190, in grep_l for l in lines: TypeError: 'NoneType' object is not iterable ... Sun May 1 14:15:58 2011 commencing square root phase Sun May 1 14:15:58 2011 reading relations for dependency 1 Sun May 1 14:16:01 2011 read 2845889 cycles Sun May 1 14:16:08 2011 cycles contain 7925904 unique relations Sun May 1 14:25:03 2011 read 7925904 relations Sun May 1 14:26:03 2011 multiplying 7925904 relations Sun May 01 14:35:20 2011 -> Computing 1.30423e+09 scale for this machine... Sun May 01 14:35:20 2011 -> procrels -speedtest> PIPE Is there any error with my whole step? |
![]() |
![]() |
![]() |
#2 |
Tribal Bullet
Oct 2004
5×709 Posts |
![]()
It looks like you got a reasonable dependency that crashed when you tried to use it. This would sometimes happen if you compiled Msieve or GMP with gcc 4.1.x, for reasons I've never been able to understand. gcc 4.2.x is reported to be safe. The other possibility is that you ran out of memory. If you're running on a 32-bit widows system that could be the problem, give that size of dataset.
|
![]() |
![]() |
![]() |
#3 | |
Mar 2006
3×173 Posts |
![]() Quote:
One way to see if this will complete successfully for you is to modify the script like so: Find the following two lines (the first is at line 1807 of your factmsieve2.py): Code:
tmp = grep_l('timeunit:', res) timescale = float(re.sub('timeunit:\s*', '', tmp[0])) Code:
# tmp = grep_l('timeunit:', res) # timescale = float(re.sub('timeunit:\s*', '', tmp[0])) timescale = 2.063 |
|
![]() |
![]() |
![]() |
#4 | |
Apr 2011
68 Posts |
![]() Quote:
I've executed msieve with the following command alone: ./msieve -v -s test2/test2.dat -l test2/test2.log -i test2/test2.ini -nf test2/test2.fb -t 4 -nc3 and get the output: commencing square root phase reading relations for dependency 1 read 2845889 cycles cycles contain 7925904 unique relations read 7925904 relations multiplying 7925904 relations Segmentation fault Note the "Segmentation fault". I've checked the gcc version, and it is exactly 4.1.x : gcc version 4.1.2 20070115 (prerelease) (SUSE Linux) and I compiled msieve under linux x86_64, the memory is 8GB, so it might not the problem of that run out of memory. I'll update gcc to 4.2.x to see if it will happen again. Thanks again. |
|
![]() |
![]() |
![]() |
#5 | |
Apr 2011
2·3 Posts |
![]() Quote:
I'm running python 3.2, and the operating system is SuSe Linux SP2 x86_64. Thanks for your help again. |
|
![]() |
![]() |
![]() |
#6 |
Apr 2011
2×3 Posts |
![]()
I've updated gcc to 4.6.0, and have compiled msieve again, but the problem still exists, am I must change gcc to 4.2.x?
|
![]() |
![]() |
![]() |
#7 |
(loop (#_fork))
Feb 2006
Cambridge, England
33·239 Posts |
![]()
I would suggest
a) build msieve against the newest version of gmp b) run 'ulimit -s unlimited' before trying the square-root step I have had this problem in the past and it came from gmp running out of stack space in the very-bignum arithmetic. |
![]() |
![]() |
![]() |
#8 | |
Apr 2011
2×3 Posts |
![]() Quote:
I've run 'ulimit -s unlimited' before trying the square root step, and msieve successfully passed the 1st dependency. It looks like follows: Tue May 3 10:49:46 2011 commencing square root phase Tue May 3 10:49:46 2011 reading relations for dependency 1 Tue May 3 10:49:49 2011 read 2845889 cycles Tue May 3 10:49:55 2011 cycles contain 7925904 unique relations Tue May 3 10:58:42 2011 read 7925904 relations Tue May 3 10:59:40 2011 multiplying 7925904 relations Tue May 3 11:58:43 2011 multiply complete, coefficients have about 420.10 million bits Tue May 3 11:58:50 2011 initial square root is modulo 34510537 till now, 5 hours has been passed, but the output is still shows as above, I don't know whether such a long time is normal or an exception has occured which caused msieve stop to running? Last fiddled with by loong on 2011-05-03 at 08:53 |
|
![]() |
![]() |
![]() |
#9 |
Apr 2011
68 Posts |
![]()
Thanks for all.
After 8 hours of square root phase, msieve successfully got the factors. ![]() |
![]() |
![]() |
![]() |
#10 |
Bamboozled!
"๐บ๐๐ท๐ท๐ญ"
May 2003
Down not across
101100011010102 Posts |
![]() |
![]() |
![]() |
![]() |
#11 |
Tribal Bullet
Oct 2004
5·709 Posts |
![]()
Redacted logfile, matrix of size 5.6M, I'd say somebody's RSA key :)
(8 hours is a little bit long for a dependency of this size, but not unusually so if the leading algebraic polynomial coefficient is at all large) Last fiddled with by jasonp on 2011-05-03 at 13:16 |
![]() |
![]() |
![]() |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Donยดt step on my toes... please! | lycorn | Lone Mersenne Hunters | 37 | 2011-10-09 16:09 |
GMP-ECM fails on step 2 with B2 > 96M | CRGreathouse | Factoring | 9 | 2010-10-30 16:38 |
Optimizing step 2 of ECM on Prime95 | alpertron | Software | 4 | 2006-01-11 17:27 |
Wildly differing times for step 2 with ecm-6.0.1 | Jushi | GMP-ECM | 7 | 2005-09-12 01:30 |
One-step Hangman | Ken_g6 | Puzzles | 1 | 2005-01-16 15:03 |