Bsquared. My gcc is 4.4.4. Comprehensive gcc -v output:
[code]
rekcahx@oah:~$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-4' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-4)[/code]

Relevant parts of session.log and factors.log are in compressed attachment.

[QUOTE=rekcahx;229594]
Relevant parts of session.log and factors.log are in compressed attachment.[/QUOTE]

Thanks, there are a few clues in there:

The lines containing "0 sieve locations out of 0", "using 0 polys (-1 A polys)", "sieving found inf rels/poly", etc, mean that this was a restart of a factorization. The significant number of errors when reading relations and the fact that there are about twice as many relations in the savefile as there should be suggest that relations were perhaps being dumped into the savefile from a different job.

The crash is apparently a symptom of the linear algebra not completing correctly (something is tried to be freed when it hasn't actually been allocated, is most likely), so I'll have to look into that, but the root cause of the error seems like save file corruption. Did you have more than one factorization going at once, somehow?

I think that there is only one factorization process at once, but I'm not sure. I've a trivial looping script which starts yafu, wait until yafu ends and then do something with results.

I've a quad core processor and I used 3 or 4 threads with yafu, but I think that this case is not thread related.

On a 64-bit i5, when using factor(), yafu uses QS time estimates for a 32-bit P3 to estimate the amount of ECM that needs to be done, so much more ECM is done than is necessary. Does this occur for anyone else?

[QUOTE=10metreh;234150]On a 64-bit i5, when using factor(), yafu uses QS time estimates for a 32-bit P3 to estimate the amount of ECM that needs to be done, so much more ECM is done than is necessary. Does this occur for anyone else?[/QUOTE]

This is similar to the problem over [URL="http://www.mersenneforum.org/showthread.php?p=234318#post234318"]here[/URL], in that the i3/5/7 processor and its features are not properly detected.

Its been awhile since I've worked on any updates - I'll try to get one out soon.

YAFU 1.20 available
 

... in the [URL="https://sites.google.com/site/bbuhrow/"]usual place[/URL].

New in version 1.20

+ faster SIQS for windows 64bit machines - up to 20% speedup observed for a c82
+ better cache and processor detection
+ new flag (vproc) prints TONS of cpu/cache info
+ tweaks to SIQS code for 1-3% speedup in core2, nehalem, and amd64 machines
+ enhancements to the general purpose factor routine and fermat factorization

This version should address the issue 10metreh was seeing.

I also just now realized that I never fixed the batch file processing code. Sorry - that will have to wait till the next release I guess.

Happy factoring!

small factor output
 

Using the 'factor' command with 'bigger' numbers will not print small factors.

Example:

Calling yafu with
[code]
factor(13998160709839581048153733514208588350923069415793585600447722863427118587832492939474407917725430759878249822)
[/code]

a 100-digit number (last index from aliquot seq. 25986) will print on screen:
[code]
factoring 13998160709839581048153733514208588350923069415793585600447722863427118587832492939474407917725430759878249822

div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 1, starting 1000 iterations on C104
rho: x^2 + 3, starting 1000 iterations on C104
rho: x^2 + 2, starting 1000 iterations on C104
pp1: starting B1 = 20K, B2 = 1M on C104
pp1: starting B1 = 20K, B2 = 1M on C104
pp1: starting B1 = 20K, B2 = 1M on C104
pm1: starting B1 = 100K, B2 = 5M on C104
ecm: 25 curves on C104 input, at B1 = 2K, B2 = 200K
ecm: 90 curves on C104 input, at B1 = 11K, B2 = 1100K
ecm: 168 curves on C104 input, at B1 = 50K, B2 = 5M
[/code]

and factor.log contains this:
[code]
11/06/10 18:07:00 v1.20 PC,
11/06/10 18:07:00 v1.20 PC, ****************************
11/06/10 18:07:00 v1.20 PC, Starting factorization of 13998160709839581048153733514208588350923069415793585600447722863427118587832492939474407917725430759878249822
11/06/10 18:07:00 v1.20 PC, ****************************
11/06/10 18:07:00 v1.20 PC, rho: x^2 + 1, starting 1000 iterations on C104
11/06/10 18:07:01 v1.20 PC, rho: x^2 + 3, starting 1000 iterations on C104
11/06/10 18:07:01 v1.20 PC, rho: x^2 + 2, starting 1000 iterations on C104
11/06/10 18:07:01 v1.20 PC, pp1: starting B1 = 20K, B2 = 1M on C104
11/06/10 18:07:01 v1.20 PC, pp1: starting B1 = 20K, B2 = 1M on C104
11/06/10 18:07:01 v1.20 PC, pp1: starting B1 = 20K, B2 = 1M on C104
11/06/10 18:07:01 v1.20 PC, pm1: starting B1 = 100K, B2 = 5M on C104
11/06/10 18:07:03 v1.20 PC, Finished 25 curves using Lenstra ECM method on C104 input, B1 = 2000, B2 = 200000
11/06/10 18:07:19 v1.20 PC, Finished 90 curves using Lenstra ECM method on C104 input, B1 = 11000, B2 = 1100000
[/code]

So for the original C110 there were small factors found and the remaining C104 is testing now.

Breaking this job won't print the small factors (not on screen nor file).

Better:
Receiving the CTRL-C command will print the small factors found so far [b]and[/b] the remaining Cxx.

I was using YAFU siqs to factor a C94 and I get the following application error while reading the relations:

The instruction at "0x00424ad6" referenced memory at "0x00000008". The memory could not be "written".

Click OK to terminate.
Click CANCEL to debug the program.


I've restarted YAFI twice after saving the siqs.dat file and received the same error each time. Any advice? Thanks....

A couple questions:
Is this the latest version, 1.20?
What OS are you using, linux or windows? 32 or 64 bit?
If you post the relations on [URL="www.sendspace.com"]sendspace [/URL]i'll take a look.

I'm using the latest version 1.20 on Windows XP 32 bit. Here is the link to the siqs.dat file: [url]http://www.sendspace.com/file/tkwgr1[/url]

The C94 is 7068706539813365378146651705387378799401977279120346480088927073809694130066011392618070305369

Thanks!

I've verified the problem, and I have a fix. This fix drastically reduces the amount of memory consumed during post-processing, which was a problem noted in a different thread. 32bit system should now be usable for larger problems and not limited by memory during post-processing.

I'll try to get the fixed version posted in the next day or so.