These packages are the same; SF source lasieve4_64 branch started from the privately forwarded tarball once everyone agreed that it was opensource... In SF, there are actually a few patches for 16e that could be relevant to this hang/crash (there was a hang/crash in the early lasieve4_64 linux binary as well and a couple internal loops were plugged even though the underlying reason was not found - it was assumed that it was obscured by asm code; now, if this bug is essentially the same, you too have two choices: find the true bug, or fix the hanging places: they look like this: [FONT=Arial Narrow]while(x<y) {do something; x+=d}[/FONT] where d actually happens to be zero).

Here is [URL="http://ggnfs.svn.sourceforge.net/viewvc/ggnfs/trunk/src/experimental/lasieve4_64/gnfs-lasieve4e.c?r1=385&r2=355"]the patch[/URL] collection you may want to adapt to the Windows part of the source, i.e. the asm-less ([SIZE=1]the infinite loops were in the portion around Line 2278, and a crash was around Line 3715, -- the latter is a division by zero. Why does that variable stored in x[0] rarely turn into 0? Nobody knows. Maybe a memory overrun, maybe 0x10000 becomes zero when it is coerced into u16_t. The original source operated with much smaller sieve sizes and this never happened to the original authors[/SIZE].)

I would put it, but how would I know that it does good or bad? -- I don't use Windows and I don't have the compiler/debugger.

Another test-case (reproducible crash) with SVN-400 (32 bit) from Jeff's homepage (15e siever), not sure if that's the same bug:

>gnfs-lasieve4I15e -r alq4788.2617.poly -o alq4788.2617_25.26a_01.out -f 25013159 -c 186841
Warning: lowering FB_bound to 25013158.
Special q 25013159 does not divide

***crash***

The poly file is:

[code]n: 2229348552361822129355877431354933637944777944345113399577912185681707793442268713514615675586421258420770429669349552195250785917635169750211125857968489791489287723679679
# norm 8.661335e-17 alpha -8.684199 e 2.548e-13 rroots 3
skew: 58927582.05
c0: -75835208698116436165893795763297338053392995
c1: 394274499523867352569474046681343689
c2: 271986736245998513067550648137
c3: -5670997805595833828841
c4: -102371276964158
c5: 353400
Y0: -1445381140453176527811641315884132
Y1: 5618925887111873447
rlim: 40000000
alim: 40000000
lpbr: 30
lpba: 31
mfbr: 60
mfba: 90
rlambda: 2.6
alambda: 3.6[/code]

Edit: and yet another crash:

>gnfs-lasieve4I15e -r alq4788.2617.poly -o alq4788.2617_25.26c.out -f 25414339 -c 185661
Warning: lowering FB_bound to 25414338.
Special q 25414339 does not divide

***crash***

Edit2: ooops, I just see that I accidentally sieved on the -r side. I should not modify copy/pasted command lines, better type them from scratch... :blush: :doh!:

yet another 15e crash - this time sieving on the "right" side (32 bit windows binary of SVN400 running under windows 7):

>gnfs-lasieve4I15e -a alq4788.2617.poly -o alq4788.2617_25.26e.out -f 25800000 -c 200000 -R
Warning: an incomplete line in the original file; if just a few, it's ok, they will be skipped
Resuming with -f 25872619 -c 127381
Warning: lowering FB_bound to 25872618.
Special q 25872619 does not divide

***crash***

[QUOTE=Andi47;249318]yet another 15e crash - this time sieving on the "right" side (32 bit windows binary of SVN400 running under windows 7):

>gnfs-lasieve4I15e -a alq4788.2617.poly -o alq4788.2617_25.26e.out -f 25800000 -c 200000 -R
Warning: an incomplete line in the original file; if just a few, it's ok, they will be skipped
Resuming with -f 25872619 -c 127381
Warning: lowering FB_bound to 25872618.
Special q 25872619 does not divide

***crash***[/QUOTE]

I have just committed a Visual Studio 2010 x64 build of the experimental lattice siever code in the ggnfs SVN.

Given the amount of assembler code I had to convert and then add Windows calling conventions, I am truly amazed that it does not crash. Sadly however, it doesn't work and gives 'pathology' messsages and terminaates:

SCHED_PATHOLOGY q0=43505239 k=1 excess=18130
SCHED_PATHOLOGY q0=43505251 k=1 excess=17702
SCHED_PATHOLOGY q0=43505291 k=1 excess=18054
SCHED_PATHOLOGY q0=43505323 k=1 excess=17936
SCHED_PATHOLOGY q0=43505327 k=1 excess=18084
total yield: 0, q=43505381 (1.#INF0 sec/rel)

I can debug it but I am going to need help from someone who knows much more about the inner workings of the code than I do.

Brian