Segfault in calculate_clair3_full_alignment

[dpryan79]

While processing data we ran into a segfault in calculate_clair3_full_alignment on line 629. It turns out that when offset was calculated on line 628, that flanking_start was greater than flanking_index. This seems to happen fairly frequently in one dataset and avoiding it is easy enough (changing line 626 to:

if (flanking_index != -1 && flanking_index >= flanking_start)

however I don't really have a good enough understanding of what exactly is being done with these flanking regions to know how this might affect the results. It'll take me a bit of time to put together a minimal example to share, so in the interim perhaps you could advise one what exactly this region of code is doing (I can tell that flanking_candidates_p is holding a dictionary of positions, which as best as I can tell is a counter of modifications at a positions, but more than that I'm not sure).

Any advice while I work on getting a minimal example put together?

[zhengzhenxian]

@dpryan79

Thanks for reporting this.

In the code, we maintain a list of flanking candidates for each variant position, spanning -16 bp to +16 bp around the candidate. The flanking_index represents the specific position index we store, while the flanking_start should always be the minimum position index of the given candidate. Thus, we expect flanking_index to be greater than or equal to flanking_start. We guess the SF might happen only when the candidate hits sequence boundaries. It would help us a lot to share your mini-example and your run code for us to debug~

Zhenxian

[dpryan79]

You're absolutely correct that this seems to happen at the very beginning of an alignment (I have no clue how such CIGAR operations are even possible, we used minimap2 upstream). I'm attaching an example you can use to reproduce the issue. The command to use would be:

python3 $CONDA_DIR/bin/scripts/../clair3.py CallVariantsFromCffi \ --chkpnt_fn $CONDA_DIR/bin/models/hifi_revio/full_alignment \ --bam_fn ROI.bam \ --call_fn ROI.vcf \ --sampleName Test_run_for_Devon --vcf_fn EMPTY --ref_fn ROI.masked.fa \ --full_aln_regions ROI.bed \ --ctgName Chr01B.1 --add_indel_length --no_phasing_for_fa False --minMQ 5 --minCoverage 2 \ --phased_vcf_fn phasedHeader.vcf.gz \ --gvcf False --enable_long_indel False --samtools samtools --use_gpu False --keep_iupac_bases False \ --cmd_fn CMD \ --platform hifi

In case it's at all helpful, I added some debug symbols and such here that I was using for debugging.

debug.tar.gz

This is a VERY minimal example, so I'm sure the 1 alignment won't suffice for any actual variants to be called anywhere, but it's enough to trigger a flanking_index of 11 and a flanking_start 12 and thus an offset of -1.

[zhengzhenxian]

@dpryan79

Thank you for providing the example~

We noticed that it occurs only when an insertion is flanked by soft-clipping at the beginning of a read, such as the CIGAR representation "5S2I". We have not encountered this CIGAR representation before. It results that the insertion position is 1 bp smaller than the flanking_start (read start, the next position of the insertion in your case).

As you have done, we have added boundary checks for these rare cases. We will include this update in the next release.