MSieve 1.45 Polyselection question (154 Digit Num)

[Batalov]

Ok, reporting. I found one leak of ~9 bytes (not really a leak, but to please valgrind it is patched in SVN 380; it was mine*) and some more obscure uninit in -nc1
==11778== Syscall param write(buf) points to uninitialised byte(s)...
==11778== by 0x555A7A4: fwrite (iofwrite.c:45)
==11778== by 0x43332E: nfs_write_lp_file (singleton.c:135) <-- gnfs/filter/singleton.c
==11778== by 0x432A67: nfs_filter_relations (filter.c:287) <-- gnfs/filter/filter.c
==11778== by 0x41F232: factor_gnfs (gnfs.c:147)
==11778== by 0x4069A2: msieve_run (driver.c:160)
==11778== by 0x404750: factor_integer (demo.c:202)
==11778== by 0x405243: main (demo.c:563)
==11778== Address 0x4023006 is not stack'd, malloc'd or (recently) free'd

However, the good news is that there are no (immediately visible) leaks in BLanczos (at least in the small unthreaded test case). None. But of course, there are many more tests to run (a larger case where more than 1 thread will get activated).

A null result, rather, so far, in itself, up.
____________
*the purists will notice that this patch is rather a sweep under the carpet. If the program is called with -s test.dat.gz valgrind will again report a leak of 9 bytes out of strdup.

[jasonp]

Valgrind is extremely picky, it will happily report errors in libc as if they were your fault. It complains about pthreads too.

There are also errors that valgrind will not catch; buffer overflows in stack variables will always be missed, for example.

I vaguely remember the error in the filtering, and could not explain it at the time. The value being written is clearly a stack variable...

[wblipp]

Originally Posted by Batalov

possibly there are no useful numbers of valgrindable size,

Ah. Small enough that it must be "not very interesting" or somebody would have already factored it. Brent composites p^31-1 with p=1733 or 1753 or 1867 or 1873 look like they qualify.

William

[jasonp]

Originally Posted by Batalov

Some small (and better yet useful) number, say from t1200. Not large (under valgrind the speed is maybe several times slower, right?)
possibly there are no useful numbers of valgrindable size, then just some silly number. And then a run from start to finish, I guess, right? It is a test for leaks memory overruns, so apparently we don't know what we are going to catch. I haven't run it much. If it is anything like purify, then there's quite a bit of tediousness, because first one will have to suppress all the uninteresting messages (leaks from libraries), and then the interesting part starts.

Valgrind is a full emulation engine that annotates memory as it runs, so you should expect any run to be 10x slower (and possibly 50x slower) than the un-analyzed binary, and the memory use is typically 3x worse for code which does fancy dynamic memory allocation. The last time I ran it on a C200 SNFS dataset it needed most of a day to get through the filtering.

It tests for many problems, and if it finds leaks or errors then you can rerun in extra-verbose mode so that you get a call stack on every error or leak. It will also tell you who allocated leaked memory. You can even configure it to fire off a debugger whenever an error happens. Basically it's very much like purify.

[Batalov]

I have now valgrinded a medium old matrix that I found in archives, a gnfs-161 (5,391-), a 5M² matrix. Normally it took a few days, some time ago. Now, with valgrind, indeed, it took almost all memory (somewhere above 6Gb), and crawled slowly (Jason's 10x estimate is not far off); but it cranked cleanly for a number of hours (ETA was ~700hrs with 3 threads); wrote a few check files, performed many ortho checks (I've lowered the check_interval to 1000 and dump_interval to 3000). No leaks, no complains. All looks clean. This was done with SVN 381 (note a small change in SVN 381: it should make a restart from some unfortunate .chk files easier).

[miklin]

Originally Posted by Carlo

Hi Jeff,

I read your article at http://gilchrist.ca/jeff/factoring/nfs_msieve_poly_guide.html
and I'm trying to use the factmsieve.py script with a 154 digit number. I'm using
a CUDA enable nVidia GPU for the poly selection.

It has been running a few days longer than the 287.50hr time limit that was displayed
by the script/msieve. Is this to be expected?

I've attached some of the output, so you can see what I mean:


Tue Jun 29 16:32:05 2010 -> factmsieve.py (v0.72)
Tue Jun 29 16:32:05 2010 -> This is client 1 of 1
Tue Jun 29 16:32:05 2010 -> Using 4 threads
Tue Jun 29 16:32:05 2010 -> Working with NAME = bmw_mode_85 ( 10 85 )
Tue Jun 29 16:32:05 2010 -> Running polynomial selection ...
Tue Jun 29 16:32:05 2010
Tue Jun 29 16:32:05 2010
Tue Jun 29 16:32:05 2010 Msieve v. 1.45
Tue Jun 29 16:32:05 2010 random seeds: 5d81c030 bbab83df
Tue Jun 29 16:32:05 2010 factoring

8224973201493734039216932833462996815932154044113673505636726252834676063695616729466358005376619469264571014058650019804568205019013693877262015651491183 (154 digits)

Regards,
-Carlo

My offer is possible for you will seem not to the essential.
But so it seemed to me at first that you not correctly converted the initial data in a key.
If it probably send a key in an initial kind in the block a key begins here so 00 00 00 10 (where 10 is a quantity of the data in DWORD). Simply actually I have much made keys 5 Level. And such key didn't meet.
Or write the block name.

[warut]

Originally Posted by wblipp

Ah. Small enough that it must be "not very interesting" or somebody would have already factored it. Brent composites p^31-1 with p=1733 or 1753 or 1867 or 1873 look like they qualify.

William

I'm interested to factor those 4 numbers.

[wblipp]

Originally Posted by warut

I'm interested to factor those 4 numbers.

Be my guest. There doesn't appear to be any need for more valgrind numbers of this size.

[warut]

Just noticed that 1753^31-1 and 1873^31-1 were already in checkfacts.txt. I'll do the rest.