Discussion related to cado-nfs

[Roberto Zanasi <zanasi.roberto@fermi.mo.it>]

Ok, thank you very much for your efforts.

On Wed, Mar 28, 2018 at 8:33 AM, Emmanuel Thomé <Emmanuel.Thome@inria.fr> wrote:

Ok, I've found your problem.

You're using a 32-bit machine.  ssize_t, which is used here and there, is
good only for 31-bit signed values. We should have used off_t there (and
we should have had #define _FILE_OFFSET_BITS 64 in cado.h, so that off_t
is a 64-bit type).

While this analysis may lead to a fix for the dup1 program, the
perspective is quite bleak. I confess that throughout the code, we
(collectively) have always thought that either:
 - (s)size_t is always large enough
 - any serious computation uses 64-bit anyway
 - nobody uses 32-bit machines
or sometimes combinations of the above.

Bottom line: I think one would need a huge amount of time to fix cado-nfs
so that computations above 120 digits run correctly on 32-bit machines,
given the pervasiveness of the above considerations: after dup1, you'd
probably hit similar issues in other filtering binaries, in linear
algebra, and so on.

32-bit platforms are among the routinely tested platforms for cado-nfs,
but the keyword here is "tested". We do such tests to catch compilation
errors, idiosyncrasies that may be dangerous in the long run, etc. 32-bit
platforms, really, aren't intended for large computations (admittedly,
rsa-129 barely qualifies as large, but still, it's too large for 32-bit
cado-nfs, sorry).

Regards,

E.

On Tue, Mar 27, 2018 at 02:38:40PM +0200, Emmanuel Thomé wrote:
> I think it would be best to move this discussion off-list.
> E.
>
> On Tue, Mar 27, 2018 at 02:34:18PM +0200, Paul Zimmermann wrote:
> >        Roberto,
> >
> > >  Just to be sure, did you check that all the files that this command is
> > >  trying to access are indeed present in the working directory ?
> > >
> > > Yes, they are all present. (The /tmp directory contains 75 .gz files, while
> > > c130.dup1.filelist.1 contains 74 files).
> >
> > did you try with revision 5a17a43 as advised by Emmanuel?
> >
> > What happens if you run manually the line "... antebuffer 24 ..." in c130.dup1.stderr.1,
> > with the final "| gzip -dc -" ? (Maybe redirecting the output to /dev/null.)
> >
> > Same question by replacing "... antebuffer 24" by "zcat", and removing
> > the final "| gzip -dc -".
> >
> > It might be that one of the .gz files is corrupted.
> >
> > >  The policy of the system regarding the automatic clean-up of /tmp can
> > >  vary, but in any case, files in there are not guaranteed to stay for
> > >  long. For a factorization that takes a bit long, it is better to use a
> > >  working directory in a more persistent place.
> > >
> > > How can I change the working directory?
> >
> > simply with cado-nfs.py ... workdir=...
> >
> > Paul Zimmermann
> > _______________________________________________
> > Cado-nfs-discuss mailing list
> > Cado-nfs-discuss@lists.gforge.inria.fr
> > https://lists.gforge.inria.fr/mailman/listinfo/cado-nfs-discuss