OK, starting from a copy of the OP's last-checkpoint file and running the last few thousand iterations using a debug-enabled build under gdb, I have found the cause of the bug - there is a small-multiplier computation in PRP final-residue postprocessing which needed an additional (mod b^2) operation, where b is the PRP-test base. None of my PRP runs to date revealed the error.

Anyone who downloaded/built the current 3. Dec code snapshot can incremental-rebuild by compiling the attached patched Mlucas.c file and relinking. I'll upload updated source tarballs and ARM binaries over the weekend.

Once I see that OP has successfully completed the bug-affected run with the updated build and submitted the result I'll ask for an early double-check of the exponent, just to be on the safe side.

Thanks again for the bug report!

The PRP-residue postprocessing bug reported in post #10 above has been fixed - please grab latest code tarball (or ARM binary for folks running on ARM). If your current build is based on the 3 January code snapshot, my "fixed" Post #3 in the above thread has an incremental single-file-rebuild option.

[b]Update:[/b] Coincidentally, a few hours after I uploaded the patched code and posted the above 'fixed' message, my latest haswell-quad PRP test, of an exponent ~96M, completed and hit the very same postprocessing bug. So I sent the above [url=https://www.mersenne.org/report_exponent/?exp_lo=96365519&full=1]96M exponent[/url] from my run out for an early double-check, which completed yesterday and verified the first-time-test result.

Since no other bugs have been reported in the past month, I am officially pronouncing v19 as the current stable release, several PRP-functionality-related bugs having been turned up and fixed as a result of the last 2 months' shakedown testing. Going to update the README.html page now.

I downloaded mlucas19_c2simd for my Odroid N2 and obtained a couple of WR PRP assignments. The assignments end in ",2" but no P-1 performance was indicated in the ".stat" file. :help:

[QUOTE=paulunderwood;536828]I downloaded mlucas19_c2simd for my Odroid N2 and obtained a couple of WR PRP assignments. The assignments end in ",2" but no P-1 performance was indicated in the ".stat" file. :help:[/QUOTE]

The readme page notes that the fields related to p-1 testing are ignored by Mlucas. Thinking aloud, Is there a way to tweak the assignment-fetch to request only exponents for which p-1 has been done to the current default depth(s)?

[QUOTE=ewmayer;536829]The readme page notes that the fields related to p-1 testing are ignored by Mlucas. Thinking aloud, Is there a way to tweak the assignment-fetch to request only exponents for which p-1 has been done to the current default depth(s)?[/QUOTE]

I popped "PFactor=..." into my gpuowl worktodo.txt file (2nd and 3rd lines). I should know soon whether to continue PRP'ing them with Mlucas.

[QUOTE=paulunderwood;536831]I popped "PFactor=..." into my gpuowl worktodo.txt file (2nd and 3rd lines). I should know soon whether to continue PRP'ing them with Mlucas.[/QUOTE]

I just did similarly with my latest batch of PRPs to-be-farmed-out to my various devices running Mlucas. I'm planning to add a few lines to the Mlucas readme to detail this, but want to make sure I get the different assignment-line formats for PRP and LL right in this regard. Let's review:

PRP=C57FF1C644A0CB16F5E2B5B3A9FC4E1D,1,2,98024161,-1,77,0 - Trailing '0' indicates p-1 has been done. We only want to do p-1 if trailing digit = 1 or 2, in which case we change PRP to Pfactor and paste the resulting assignment into the worktodo file for Prime95/mprime or gpuOwl. (Does CudaLucas also support p-1? Unfamiliar with it.)

Test=DDD21F2A0B252E499A9F9020E02FE232,48295213,69,0 - Trailing '0' indicates p-1 has *not* been done. How to munge the assignment into a p-1 one?

For DC assignments of either type, the same 2 trailing-digit conventions hold, yes? And if some p-1 was done prior to the first-time test of a given exponent, in preparation for handing out a 2nd time as a DC, does the server ever change the trailing digit from "p-1 has been done" to "p-1 needed" to reflect that deeper p-1 should be done prior to the DC?

[QUOTE=ewmayer;537717]Let's review:

PRP=C57FF1C644A0CB16F5E2B5B3A9FC4E1D,1,2,98024161,-1,77,0 - Trailing '0' indicates p-1 has been done. We only want to do p-1 if trailing digit = 1 or 2, in which case we change PRP to Pfactor and paste the resulting assignment into the worktodo file for Prime95/mprime or gpuOwl. (Does CudaLucas also support p-1? Unfamiliar with it.)[/QUOTE]No, CUDALucas does LL only, without Jacobi check. If you want CUDA P-1, that would be CUDAPm1, a separate app described by its author as alpha software.[QUOTE]
Test=DDD21F2A0B252E499A9F9020E02FE232,48295213,69,0 - Trailing '0' indicates p-1 has *not* been done. How to munge the assignment into a p-1 one?

For DC assignments of either type, the same 2 trailing-digit conventions hold, yes? And if some p-1 was done prior to the first-time test of a given exponent, in preparation for handing out a 2nd time as a DC, does the server ever change the trailing digit from "p-1 has been done" to "p-1 needed" to reflect that deeper p-1 should be done prior to the DC?[/QUOTE]Requesting a manual or PrimeNet P-1 assignment for the exponent in question will generate the prime95 form of P-1 assignment record with the correct # of tests saved included. Prime95 uses that integer as input to select appropriate bounds to maximize probable testing time saved, as does CUDAPm1.
The reference post for assignment (worktodo entry) format by app, version and type is at [URL]https://www.mersenneforum.org/showpost.php?p=522098&postcount=22[/URL]

Readme has been updated with guidance re. doing preliminary p-1 using one of the GIMPS clients which support it. Ken, thanks for the comments.

Ken reports build failure using msys2 under Windows -- "signal issues and real time extensions lib not available."
[code]ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ gcc -c -O3 ../src/*.c >& build.log

ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ grep error build.log
../src/fermat_mod_square.c:1842:18: error: 'SIGHUP' undeclared (first use in this function); did you mean 'SIGFPE'?
../src/fermat_mod_square.c:1844:18: error: 'SIGALRM' undeclared (first use in this function); did you mean 'SIGABRT'?
../src/fermat_mod_square.c:1846:18: error: 'SIGUSR1' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/fermat_mod_square.c:1848:18: error: 'SIGUSR2' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/mers_mod_square.c:2533:18: error: 'SIGHUP' undeclared (first use in this function); did you mean 'SIGFPE'?
../src/mers_mod_square.c:2535:18: error: 'SIGALRM' undeclared (first use in this function); did you mean 'SIGABRT'?
../src/mers_mod_square.c:2537:18: error: 'SIGUSR1' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/mers_mod_square.c:2539:18: error: 'SIGUSR2' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/Mlucas.c:187:21: error: 'SIGHUP' undeclared (first use in this function); did you mean 'SIGFPE'?
../src/Mlucas.c:189:21: error: 'SIGALRM' undeclared (first use in this function); did you mean 'SIGABRT'?
../src/Mlucas.c:191:21: error: 'SIGUSR1' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/Mlucas.c:193:21: error: 'SIGUSR2' undeclared (first use in this function); did you mean 'SIG_ERR'?

ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ gcc -o Mlucas-x86 *.o -lm -lrt
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lrt
collect2.exe: error: ld returned 1 exit status

ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ pacman -Su librt
error: target not found: librt

ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ pacman -Su rt
error: target not found: rt[/code]
Any advice from fellow msys2 users welcome - I no longer have any Win-box to play with this myself.

Ken, which version of Windows, and which precise built-in Linux distro?

The preceding was on msys2/mingw64 (on Windows 7 x64 Pro, as fully patched as I could make it, HP Z600 dual E5645).
I went a few rounds with msys2's pacman implementation which is adapted from Arch Linux from what I've read, searching for the rt library without success. POSSIBLY it's on some mirror somewhere, if it has been ported.

I'm currently updating msys2 and its packages. This is taking a while, since I have a lot running and am frequently getting "Connection timed out after 10030 milliseconds" or similar from pacman.

"MSYS2 is a software distro and building platform for Windows

At its core, it is an independent rewrite of MSYS, based on modern Cygwin (POSIX compatibility layer) and MinGW-w64 with the aim of better interoperability with native Windows software. It provides a bash shell, Autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains.

It features a package management system, Pacman, to provide easy installation of packages. It brings many powerful features such as dependency resolution and simple complete system upgrades, as well as straight-forward package building." [URL]https://www.msys2.org/[/URL]

Mlucas v17 built ok on msys2, as did v17.1, a year ago. But V19 did not, this week, partly because it requires linking to the real time extensions library librt. [URL]https://docs.oracle.com/cd/E36784_01/html/E36873/librt-3lib.html[/URL]

But there is no librt in msys2's package list. [URL]https://github.com/msys2/MSYS2-packages[/URL] [URL]https://packages.msys2.org/search?t=pkg&q=rt[/URL]
And there's no libc listed either.

And v18 didn't go so well either, today, on msys2, after a full update of msys2.[CODE]ken@condorella MINGW64 ~/mlucas/mlucas_v18/build
$ grep error build.log
../src/fermat_mod_square.c:1869:18: error: 'SIGHUP' undeclared (first use in this function)
../src/mers_mod_square.c:2382:18: error: 'SIGHUP' undeclared (first use in this function)
../src/Mlucas.c:182:21: error: 'SIGHUP' undeclared (first use in this function)

ken@condorella MINGW64 ~/mlucas/mlucas_v18/build
$ gcc -o Mlucas-x86 *.o -lm -lrt
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lrt
collect2.exe: error: ld returned 1 exit status
[/CODE]