A frg file created by TracearchiveToCA contains an entry with these values:
clv:0,-1
clr:0,-1
which would seem to be allowed by the description here:
http://wgs-assembler.sourceforge.net/wiki/index.php/FRG_Files
1. To indicate that either the vector or quality clear range is not known, omit the clv: or clq: entry. 2. To indicate no sequence is in a clear range, any begin >= end may be used, with 0,0 being the standard. For example, "clr:0,0".
(caveat, there is a warning that isn't up to to date, but I could not find the source for what was.) Unfortunately the 0,-1 pair is toxic to the gatekeeper built from trunk on 2014_07_03 because AS_PER_gkStore_clearRange.C contains:
assert(begin <= end);
assert(begin <= fr->gkFragment_getSequenceLength());
assert(end <= fr->gkFragment_getSequenceLength());
end is unfortunately passed as a uint32, so -1 turns into 2^32-1 which is longer than the sequencelength, and gatekeeper aborts.
Either TracearchiveToCA needs to use something other than 0,-1 or gatekeeper needs to handle that end as a signed value. Or both.
Hmm, changing the 0,-1 to 0,0 or 1,1 in the input file results in the same abort. Something in gatekeeper is calculating end, setting it to -1 in these cases, and that is blowing up in AS_PER_gkStore_clearRange.C.
Last edit: David Mathog 2014-07-17
Amendment to the preceding. 0,-1 to 0,0 does fix THOSE entries, but it turned out there were others like 3,-1 and 5,-1, and the first one of those it hit blew up gatekeeper.
Changing all -1 to 0 in the frg file detoxified it, as far as gatekeeper was concerned.
There is a bug in gatekeeper, as far as I am concerned. If it was going to store that value into a uint32_t it should have checked that it was in range.
Last edit: David Mathog 2014-07-17