MSieve 1.45 Polyselection question (154 Digit Num) - Page 3

Carlo · 2010-08-24, 17:21

I looked, my num.dat is like 158 bytes now. The last back up I have is when it was at 75% (I'll restart from there), I guess somehow in the nc1 stage the num.dat got corrupted.

The .chk and .cyc files are new though, what are those for?

-Carlo

10metreh · 2010-08-24, 17:24

Quote:

Originally Posted by Batalov

P.S. The message
Tue Aug 24 08:45:55 2010 read 0 relations
doesn't look too good. Check if num.dat still exists. I hope that script didn't delete it? :surprised You hopefully have a backup? (You should. Always.)

The script could have deleted it - that once happened to me when I interrupted a linalg. I never found out for sure that it was the script, but I don't think anything else could have caused it.

Andi47 · 2010-08-24, 18:33

Quote:

Originally Posted by jasonp

Actually, when this error appears it could be for many reasons, chief of which is a hardware problem. The last time you got this error it was a programmer problem, i.e. my fault :)

Has this bug crept in in version 1.45 or 1.46? I have never seen someone complaining about a "corrupt state" error before these versions.

jasonp · 2010-08-24, 19:34

The orthogonality check that can generate these errors was added in v1.43 IIRC

tgrdy · 2010-08-25, 02:49

In v1.46, the "corrupt state" bug comes out.

I have factored C153, C157 numbers, successfully with v1.44, v1.45.

But with v1.46, and v1.47 svn(both on windows or linux x86, or x86-64, amd cpu or intel cpu), this "corrupt state" bug in Linear Algebra ocurrs everytime.

Quote:

Originally Posted by Andi47

Has this bug crept in in version 1.45 or 1.46? I have never seen someone complaining about a "corrupt state" error before these versions.

Batalov · 2010-08-25, 03:32

M919 was factored with 1.47 SVN various releases, and some 1.46.
So, I see no problems with 1.46 or 1.47.

I have seen occasional ortho errors for as long as the ortho check was written in (it was around 07/19/2009). And with M919, sure, a few. Before it was written, the silent consequences were known to the unfortunate few as the 101%+ bug (i.e. when a memory error was happening silently, your BL could finish ...never). Also don't forget about summer, plus the fact that everyone is doing larger and yet larger numbers -- these are all good alternative explanations for the observed effect. You won't see errors before you get to a decent size.

Jasonp promised (:wink-wink:) a valgrind tedious run some time soon. Hmmmm... maybe I could try a valgrind run too -- I am between matrices. Got some time but cannot promise. Anyone for a bug chasing rally? Build, valgrind, nail it. (If it is there, though.)

Jeff Gilchrist · 2010-08-25, 03:40

Quote:

Originally Posted by Batalov

Jasonp promised (:wink-wink:) a valgrind tedious run some time soon. Hmmmm... maybe I could try a valgrind run too -- I am between matrices. Got some time but cannot promise. Anyone for a bug chasing rally? Build, valgrind, nail it. (If it is there, though.)

I could spend some time, just let me know how you want me to set it up and I can try it out.

Batalov · 2010-08-25, 03:51

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.

Someone on their own system could find the bugs in Fedora's distro, instead of msieve. Who knows. <rant> I once built X from source, because the distro version had been crashing. Ah, the good old days, the 90s...</rant>

wblipp · 2010-08-25, 04:25

Quote:

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,

What size do you want? I can probably locate an SNFS candidate of any size, although it may be short on ECM.

Batalov · 2010-08-25, 05:00

I have no idea.
I think I will start with an easy (47*10^105-11)/9
The result is known and non-ECMable, just fine for a trivial SNFS.

Batalov · 2010-08-25, 05:42

Oh. So far it is a bag of fun.
You will (may) need something like this
Admin privileges may be a must because we are dealing with ld.so
Don't (Actually, do) try this at home.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Msieve v. 1.47 and 148 digit composite	Unregistered	Information & Answers	8	2010-10-04 07:31
Quick msieve question	alkirah	Msieve	2	2009-12-30 14:00
222-digit SNFS completed with msieve	frmky	Factoring	2	2007-10-01 18:23
Question about cycle counting in MSieve	schickel	Msieve	3	2006-11-25 07:14
MSieve - problem with 106-digit effort	schickel	Msieve	5	2006-08-31 03:19

2010-08-24, 17:21	#23
Carlo Jul 2010 8₁₆ Posts	I looked, my num.dat is like 158 bytes now. The last back up I have is when it was at 75% (I'll restart from there), I guess somehow in the nc1 stage the num.dat got corrupted. The .chk and .cyc files are new though, what are those for? -Carlo

2010-08-24, 19:34	#26
jasonp Tribal Bullet Oct 2004 3,541 Posts	The orthogonality check that can generate these errors was added in v1.43 IIRC

2010-08-25, 03:32	#28
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 22405₈ Posts	M919 was factored with 1.47 SVN various releases, and some 1.46. So, I see no problems with 1.46 or 1.47. I have seen occasional ortho errors for as long as the ortho check was written in (it was around 07/19/2009). And with M919, sure, a few. Before it was written, the silent consequences were known to the unfortunate few as the 101%+ bug (i.e. when a memory error was happening silently, your BL could finish ...never). Also don't forget about summer, plus the fact that everyone is doing larger and yet larger numbers -- these are all good alternative explanations for the observed effect. You won't see errors before you get to a decent size. Jasonp promised (:wink-wink:) a valgrind tedious run some time soon. Hmmmm... maybe I could try a valgrind run too -- I am between matrices. Got some time but cannot promise. Anyone for a bug chasing rally? Build, valgrind, nail it. (If it is there, though.)

2010-08-25, 03:51	#30
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶×13 Posts	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. Someone on their own system could find the bugs in Fedora's distro, instead of msieve. Who knows. <rant> I once built X from source, because the distro version had been crashing. Ah, the good old days, the 90s...</rant>

2010-08-25, 05:00	#32
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	I have no idea. I think I will start with an easy (47*10^105-11)/9 The result is known and non-ECMable, just fine for a trivial SNFS.

2010-08-25, 05:42	#33
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	Oh. So far it is a bag of fun. You will (may) need something like this Admin privileges may be a must because we are dealing with ld.so Don't (Actually, do) try this at home.