Python Driver for GGNFS and MSIEVE - Page 26

ET_ · 2010-03-06, 16:17

I followed Jeff's guide to GGNFS and downloaded all the executables on the right directories.

My machine is a corei5 with Ubuntu 9.10 and Python 2.6 installed.

I get this error:

Code:

-> This is client 1 of 1
-> Using 4 threads
-> Working with NAME = example
-> Error: Polynomial file example.poly does not exist!
-> Found n = 2881039827457895971881627053137530734638790825166127496066674320241571446494762386620442953820735453.
-> Running polynomial selection ...
-> msieve -s example/example.dat -l example/example.log -i example/example.ini -nf example/example.fb -v -np
Traceback (most recent call last):
  File "../factmsieve.py", line 1974, in <module>
    run_msieve_poly(fact_p)
  File "../factmsieve.py", line 905, in run_msieve_poly
    elif run_msieve('-v -np'):  
  File "../factmsieve.py", line 328, in run_msieve
    ret = run_exe(MSIEVE, args + ap)
  File "../factmsieve.py", line 300, in run_exe
    p = subprocess.Popen([ex] + args.split(' '), **al)
  File "/usr/lib/python2.6/subprocess.py", line 621, in __init__
    errread, errwrite)
  File "/usr/lib/python2.6/subprocess.py", line 1126, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

I guess it is an error related to the subprocess.py file while creating a pipe, but I just can't handle it

Any hints?

Luigi

Brian Gladman · 2010-03-06, 16:46

Did you edit the paths in facatmsieve.py to point to the locations of msieve and ggnfs. It looks as if the programme did not find the msieve executable file where it expected it to be.

Brian

ET_ · 2010-03-06, 17:59

Quote:

Originally Posted by Brian Gladman

Did you edit the paths in facatmsieve.py to point to the locations of msieve and ggnfs. It looks as if the programme did not find the msieve executable file where it expected it to be.

Brian

I did. msieve and ggnfs executables are in the same directory of factmsieve.py and the example directory (where the example.n is).

Code:

drwxr-xr-x 2 luigi luigi    4096 2010-02-27 14:35 backup
drwxr-xr-x 2 luigi luigi    4096 2010-03-06 17:10 example
-rw-r--r-- 1 luigi luigi      15 2010-03-06 17:09 example.job.resume
-rw-r--r-- 1 luigi luigi     268 2010-03-06 17:10 example.log
-rwxr-xr-x 1 luigi luigi   70071 2010-03-06 17:09 factmsieve.py
-rw-r--r-- 1 luigi luigi   70071 2010-03-06 17:09 factmsieve.py~
-rwxr-x--x 1 luigi luigi  991136 2009-04-15 10:38 gnfs-lasieve4I11e
-rwxr-x--x 1 luigi luigi  974752 2009-04-15 10:34 gnfs-lasieve4I12e
-rwxr-x--x 1 luigi luigi  970656 2009-04-15 10:34 gnfs-lasieve4I13e
-rwxr-x--x 1 luigi luigi  966560 2009-04-15 10:34 gnfs-lasieve4I14e
-rwxr-x--x 1 luigi luigi  958368 2009-04-15 10:34 gnfs-lasieve4I15e
-rwxrwxrwx 1 luigi luigi 1055887 2009-06-10 04:25 gnfs-lasieve4I16e
-rwxr-xr-x 1 luigi luigi  389490 2010-02-21 20:33 msieve

I run "python ../factmsieve.py example" from the example directory.

I just noticed that I don't have these files.

Code:

def-nm-params.txt
def-par.txt

Luigi

Brian Gladman · 2010-03-06, 18:16

You will certainly need the parameter files but it still looks as if it hasn't found msieve. What are the MSIEVE_PATH and GGNFS_PATH set to?

ET_ · 2010-03-06, 18:23

Quote:

Originally Posted by Brian Gladman

You will certainly need the parameter files but it still looks as if it hasn't found msieve. What are the MSIEVE_PATH and GGNFS_PATH set to?

Code:

# Set binary directory paths

GGNFS_PATH = '../'
MSIEVE_PATH = '../'

I tried and inserted the two default parameters files in the directory, and copied a example.fb file in the "example" directory: lasieve was startd without problems, altough the files were in the same directory of msieve.

I also successfully started msieve from command line to check if it was working, and it was.

Luigi

Brian Gladman · 2010-03-06, 18:49

I think the default files are in ggnfs\bin. They are certainly in the ggnfs distribution.

Brian

Brian Gladman · 2010-03-06, 19:51

One thing you could try is to set both the MSIEVE_PATH and the GGNFS_PATH as absolute paths rather than relative ones.

Brian

ET_ · 2010-03-06, 23:38

Quote:

Originally Posted by Brian Gladman

One thing you could try is to set both the MSIEVE_PATH and the GGNFS_PATH as absolute paths rather than relative ones.

Brian

It didn't work either...

I really don't understand... If I put a correct factorbase file, the script runs happily through the sieving phase, using the GGNFS executables on the same directory where msieve is, while if I run a barebone example.n file, it hangs.

Luigi

tmorrow · 2010-03-07, 00:23

Can you show us the latest log where you are using absolute paths for MSIEVE_PATH and GGNFS_PATH? Also show us the diff b/w your factmsieve.py and the original.

It looks like you are on a Unix platform. A few things you can check/try:

1. What happens if you run the large msieve command line (shown in the log) from your example directory? i.e. mimic what factmsieve.py is trying to do.
2. Is . in your current path? If not add it.
3. Does /usr/lib/python2.6/subprocess.py exist?

Note that in order to invoke msieve, factmsieve.py changes directories to where msieve is and reconstructs paths back to the example directory before starting msieve. This is different than how the ggnfs binaries are invoked so I could imagine the ggnfs working and the msieve not.

ET_ · 2010-03-07, 00:54

Quote:

Originally Posted by tmorrow

Can you show us the latest log where you are using absolute paths for MSIEVE_PATH and GGNFS_PATH? Also show us the diff b/w your factmsieve.py and the original.

It looks like you are on a Unix platform. A few things you can check/try:

1. What happens if you run the large msieve command line (shown in the log) from your example directory? i.e. mimic what factmsieve.py is trying to do.
2. Is . in your current path? If not add it.
3. Does /usr/lib/python2.6/subprocess.py exist?

Note that in order to invoke msieve, factmsieve.py changes directories to where msieve is and reconstructs paths back to the example directory before starting msieve. This is different than how the ggnfs binaries are invoked so I could imagine the ggnfs working and the msieve not.

Here is the 2 example.log from ggnfs and example directories:

Code:

Sun Mar 07 01:39:52 2010 -> msieve -s example/example.dat -l example/example.log -i example/example.ini -nf example/example.fb -v -np
-----
Sun Mar 07 01:39:52 2010 -> factmsieve.py (v0.57)
Sun Mar 07 01:39:52 2010 -> This is client 1 of 1
Sun Mar 07 01:39:52 2010 -> Using 4 threads
Sun Mar 07 01:39:52 2010 -> Working with NAME = example
Sun Mar 07 01:39:52 2010 -> Running polynomial selection ...

The only differences are in lines 59-62 (paths), 66 (NUM_CPUS) and 68 (USE_CUDA).

1 - msieve is not in my example directory. If I run it from where it is (ggnfs directory) I must add "./" before msieve to run it.
2 - Geee, it worked!

I used to type ./ to run a file.
3 - Yes, the affected python file exists.

Thank you tmorrow (and Brian), and sorry for my inexperience.

Maybe Jeff could add this "trick" in his "HOWTO" tutorial...

Luigi

tmorrow · 2010-03-07, 05:28

Excellent! I had a suspicion that it might be the missing . from the path.

We'll let Brian decide whether he wants to cater for the possibility it in factmsieve.py or whether it should be added as an assumption as to how your environment is setup.

Many tightened Unix systems will not have . in the path for users by default as a security precaution. Most Unix user I know compromise by adding it to the end of their PATH variable rather than at the start. The classic example of the vulnerability is where someone creates a rogue ls program that does something malicious and places it somewhere commonly accessed like the /tmp directory. Any user with . at the front of their path that are in the /tmp directory will unknowingly be accessing the rogue program whenever they type ls. Personally I think the risk is low on the Unix systems I use (either single user Linux systems or company Unix systems behind a company firewall).

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Msieve & ggnfs on MacOS	xilman	Msieve	8	2017-05-20 00:12
Factorizing with MSIEVE, GGNFS & Factmsieve.py	Romuald	Msieve	24	2015-11-09 20:16
Infinite loop for ggnfs or msieve	Greebley	Aliquot Sequences	4	2013-02-06 19:28
Error running GGNFS+msieve+factmsieve.py	D. B. Staple	Factoring	6	2011-06-12 22:23
A new driver? (or type of driver?)	10metreh	Aliquot Sequences	3	2010-02-15 15:57

2010-03-06, 16:46	#277
Brian Gladman May 2008 Worcester, United Kingdom 214₁₆ Posts	Did you edit the paths in facatmsieve.py to point to the locations of msieve and ggnfs. It looks as if the programme did not find the msieve executable file where it expected it to be. Brian

2010-03-06, 18:16	#279
Brian Gladman May 2008 Worcester, United Kingdom 1024₈ Posts	You will certainly need the parameter files but it still looks as if it hasn't found msieve. What are the MSIEVE_PATH and GGNFS_PATH set to?

2010-03-06, 18:49	#281
Brian Gladman May 2008 Worcester, United Kingdom 2²×7×19 Posts	I think the default files are in ggnfs\bin. They are certainly in the ggnfs distribution. Brian

2010-03-06, 19:51	#282
Brian Gladman May 2008 Worcester, United Kingdom 1000010100₂ Posts	One thing you could try is to set both the MSIEVE_PATH and the GGNFS_PATH as absolute paths rather than relative ones. Brian

2010-03-07, 00:23	#284
tmorrow Jan 2004 103 Posts	Can you show us the latest log where you are using absolute paths for MSIEVE_PATH and GGNFS_PATH? Also show us the diff b/w your factmsieve.py and the original. It looks like you are on a Unix platform. A few things you can check/try: 1. What happens if you run the large msieve command line (shown in the log) from your example directory? i.e. mimic what factmsieve.py is trying to do. 2. Is . in your current path? If not add it. 3. Does /usr/lib/python2.6/subprocess.py exist? Note that in order to invoke msieve, factmsieve.py changes directories to where msieve is and reconstructs paths back to the example directory before starting msieve. This is different than how the ggnfs binaries are invoked so I could imagine the ggnfs working and the msieve not.

2010-03-07, 05:28	#286
tmorrow Jan 2004 103 Posts	Excellent! I had a suspicion that it might be the missing . from the path. We'll let Brian decide whether he wants to cater for the possibility it in factmsieve.py or whether it should be added as an assumption as to how your environment is setup. Many tightened Unix systems will not have . in the path for users by default as a security precaution. Most Unix user I know compromise by adding it to the end of their PATH variable rather than at the start. The classic example of the vulnerability is where someone creates a rogue ls program that does something malicious and places it somewhere commonly accessed like the /tmp directory. Any user with . at the front of their path that are in the /tmp directory will unknowingly be accessing the rogue program whenever they type ls. Personally I think the risk is low on the Unix systems I use (either single user Linux systems or company Unix systems behind a company firewall).