View Single Post
Old 2021-07-05, 20:19   #45
ewmayer's Avatar
Sep 2002
Rep├║blica de California

13×29×31 Posts

Bug Alert: This bug will cause around 6% of completed results to not be successfully submitted to the server via the v5-APIified script.

I first discovered the issue in March, around a month after v19.1 came out. It affects both v19.0 and 19.1. After reporting the problem to George and James Heinrich, I mis-read James' reply as meaning he had patched the API to accept the results in question; turns out he only patched the Manual Submission page. It seems there is no good way to work around this on the server/API-side, so users reading this, please check your nohup.out files for API error messages (keywords bolded) of the kind listed below, and then manually edit your results.txt file(s) to fix the offending entries. submit_one_line_v5: Submitting using V5 API
{"status":"C", "exponent":63327331, "worktype":"LL", "res64":" 5DFBB5BD815400A", "fft-length":3670016, "shift-count":3025624, "error-code":"00000000", "program":{"name":"Mlucas", "version":"19.1"}, "timestamp":"2021-07-03 17:47:01 UTC", "aid":"7D690A965943BDCE33448D5072CF9AE1"} submit_one_line_v5: ERROR while submitting result on assignment_id=7D690A965943BDCE33448D5072CF9AE1 submit_one_line_v5: INVALID PARAMETER: this is a bug in, please notify the author submit_one_line_v5: Reason: parameter rd: Invalid value/precision: ' 5DFBB5BD815400A'

The problem is due to a silly print-leading-zeros formatting bug in the new JSON-result-format function I added in v19 - for the res64-field I used C print format %16llX instead of %016llX - the former causes any leading 0-hexits in the res64 to get printed as blanks, and the server treats such less-than-16-hexits-wide results as 'Invalid'.

The problem has been fixed in the Mlucas v20 dev-code (which I plan to release by end of this week) - the reason I didn't rush out a patch to v19 is 2-fold:

1 - I thought James had successfully worked around the problem via API-side hack;

2 - Patched code only solves the problem going forward - I didn't want to ask all the users to manually scan their results files for completed runs left in submission limbo doe to this.

In your run directories, assuming you invoke Mlucas v19 in the recommended way, via 'nohup ./Mlucas [whatever]', do 'grep Invalid nohup.out'. If that shows 1 or more matches, edit results.txt and fill the leading blanks in the corresponding res64 fields with 0s, then save the file. The script will automatically try resubmitting the affected results on its next every-6-hour autoexec; I suggest you wait that long, then at your next opportunity check any such assignments for successful submission 2 ways:

1. grep for the exponent or res64 in results_sent.txt;

2. In a browser, load[your exponent here]&full=1 .

Alas, due to the elapsed months since I first noticed/reported the issue and having the not-patched-on-API-side-ness brought to my attention over the weekend, some of the affected results will inevitably have expired and been reassigned. For that, I apologize.

Last fiddled with by ewmayer on 2021-07-05 at 20:21
ewmayer is offline   Reply With Quote