<div dir="ltr">Ok, thank you very much for your efforts.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 28, 2018 at 8:33 AM, Emmanuel Thomé <span dir="ltr"><<a href="mailto:Emmanuel.Thome@inria.fr" target="_blank">Emmanuel.Thome@inria.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, I've found your problem.<br>
<br>
You're using a 32-bit machine.  ssize_t, which is used here and there, is<br>
good only for 31-bit signed values. We should have used off_t there (and<br>
we should have had #define _FILE_OFFSET_BITS 64 in cado.h, so that off_t<br>
is a 64-bit type).<br>
<br>
While this analysis may lead to a fix for the dup1 program, the<br>
perspective is quite bleak. I confess that throughout the code, we<br>
(collectively) have always thought that either:<br>
 - (s)size_t is always large enough<br>
 - any serious computation uses 64-bit anyway<br>
 - nobody uses 32-bit machines<br>
or sometimes combinations of the above.<br>
<br>
Bottom line: I think one would need a huge amount of time to fix cado-nfs<br>
so that computations above 120 digits run correctly on 32-bit machines,<br>
given the pervasiveness of the above considerations: after dup1, you'd<br>
probably hit similar issues in other filtering binaries, in linear<br>
algebra, and so on.<br>
<br>
32-bit platforms are among the routinely tested platforms for cado-nfs,<br>
but the keyword here is "tested". We do such tests to catch compilation<br>
errors, idiosyncrasies that may be dangerous in the long run, etc. 32-bit<br>
platforms, really, aren't intended for large computations (admittedly,<br>
rsa-129 barely qualifies as large, but still, it's too large for 32-bit<br>
cado-nfs, sorry).<br>
<br>
Regards,<br>
<br>
E.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Mar 27, 2018 at 02:38:40PM +0200, Emmanuel Thomé wrote:<br>
> I think it would be best to move this discussion off-list.<br>
> E.<br>
><br>
> On Tue, Mar 27, 2018 at 02:34:18PM +0200, Paul Zimmermann wrote:<br>
> >        Roberto,<br>
> ><br>
> > >  Just to be sure, did you check that all the files that this command is<br>
> > >  trying to access are indeed present in the working directory ?<br>
> > ><br>
> > > Yes, they are all present. (The /tmp directory contains 75 .gz files, while<br>
> > > c130.dup1.filelist.1 contains 74 files).<br>
> ><br>
> > did you try with revision 5a17a43 as advised by Emmanuel?<br>
> ><br>
> > What happens if you run manually the line "... antebuffer 24 ..." in c130.dup1.stderr.1,<br>
> > with the final "| gzip -dc -" ? (Maybe redirecting the output to /dev/null.)<br>
> ><br>
> > Same question by replacing "... antebuffer 24" by "zcat", and removing<br>
> > the final "| gzip -dc -".<br>
> ><br>
> > It might be that one of the .gz files is corrupted.<br>
> ><br>
> > >  The policy of the system regarding the automatic clean-up of /tmp can<br>
> > >  vary, but in any case, files in there are not guaranteed to stay for<br>
> > >  long. For a factorization that takes a bit long, it is better to use a<br>
> > >  working directory in a more persistent place.<br>
> > ><br>
> > > How can I change the working directory?<br>
> ><br>
> > simply with cado-nfs.py ... workdir=...<br>
> ><br>
> > Paul Zimmermann<br>
> > ______________________________<wbr>_________________<br>
> > Cado-nfs-discuss mailing list<br>
> > <a href="mailto:Cado-nfs-discuss@lists.gforge.inria.fr">Cado-nfs-discuss@lists.gforge.<wbr>inria.fr</a><br>
> > <a href="https://lists.gforge.inria.fr/mailman/listinfo/cado-nfs-discuss" rel="noreferrer" target="_blank">https://lists.gforge.inria.fr/<wbr>mailman/listinfo/cado-nfs-<wbr>discuss</a><br>
</div></div></blockquote></div><br></div>