Current script_validator implementation contains next statements:
sprintf(cmd, "../bin/%s", init_script[0].c_str());
and
sprintf(cmd, "../bin/%s", compare_script[0].c_str());
It is dangerous to use this arrays
that are filled by parsing command line
without validating whether they contain any elements
and leads to next behavior:
Program received signal SIGSEGV, Segmentation fault.
0x000000000040f838 in compare_results (r1=..., r2=..., match=match@entry=@0x7ffffffb6c17: false) at script_validator.cpp:154
154 script_validator.cpp: No such file or directory.
(gdb) bt
#0 0x000000000040f838 in compare_results (r1=..., r2=..., match=match@entry=@0x7ffffffb6c17: false) at script_validator.cpp:154
#1 0x000000000040e85d in check_set (results=std::vector of length 2, capacity 2 = {...}, wu=..., canonicalid=@0x7ffffffb6dd0: 0,
retry=@0x7ffffffb6dcf: false) at validate_util2.cpp:134
#2 0x000000000040944e in handle_wu (validator=..., items=std::vector of length 3, capacity 4 = {...}) at validator.cpp:411
#3 0x000000000040a9f2 in do_validate_scan () at validator.cpp:730
#4 0x000000000040aae4 in main_loop () at validator.cpp:756
#5 0x00000000004039f6 in main (argc=5, argv=0x7fffffffdd48) at validator.cpp:929
This fix checks whether these arrays contain some elements
and output a readable error of missed inout parameter.
Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
The validator handler can now pass unknown arguments to the project specific handler.
Projects that have there own validator need to implement the validate_handler_init() function and handle project specific arguments there. They also need to supply a validate_handler_usage() function that printf()'s a description of the custom options. For examples see sample_substr_validator.cpp or script_validator.cpp
The validator test harness was also adopted to use this new functions.
This brings the implementation of the validator framework on the same level as the assimilator framework where similar changes where made in 0038d275c and dd004404a.
The SETI@home result table is about to run out of 32-bit IDs,
so we need to move to 64-bit result IDs.
This will happen to the workunit table at some point too.
I changed the server C++ code to use the "long" type for all DB IDs
(and to use appropriate conversion codes like %lu).
"long" is 64 bit on 64-bit machines.
For uniformity I did this for all tables,
even ones (like app) that will never get big.
I chose NOT to change the DB schema for now.
The new code will work with 32-bit ID fields in the DB.
As projects approach the 32-bit limit on a table they can change
its ID field, and fields that reference this table, to BIGINT.
This is likely to happen only on the result and workunit tables.
I put functions in html/ops/db_update.php
to change the IDs of these tables.
When a project is reset, the client deletes all the files from its dir
that BOINC knows about.
However, there may be other files, created by its apps.
On Android, where space is likely to be scarce,
delete these when the project is reset.
Maybe we should do this on all projects.
But we'd need to not to delete user-created files
like app_config.xml, and anonymous-platform stuff
like app_info.xml and the app files.
Vitalii Koshura