Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Crash when "alt is the same as the reference" #34

Open
andreaswallberg opened this Issue · 5 comments

3 participants

@andreaswallberg

Dear freebayes devs,

I pulled and compiled freebayes from GIT today. It identifies itself as version 0.9.5. I have hundreds of BAM files but recent versions of freebayes (0.9.4 and 0.9.5) are not able to handle a particular site in one of these files. Version 0.8.9 handled the site (in that it didn't crash) but overall seemed considerably slower at SNP calling this data. Recent freebayes versions crash with an error message when it gets to a certain position at chromosome "Group12" in this file:

Command:

freebayes -b 10154640-10164640.bam -f ref.fasta -v test_Group12.20120503.vcf -r Group12:10154651..

Error:

variant at Group12:10154652
alt is the same as the reference
C == C
freebayes: ResultData.cpp:166: vcf::Variant& Results::vcf(vcf::Variant&, long double, long double, Samples&, std::string, std::vector >&, std::map, std::allocator >, int, std::less, std::allocator > >, std::allocator, std::allocator >, int> > >, std::vector, std::allocator >, std::allocator, std::allocator > > >&, int, GenotypeCombo&, bool, std::map, std::allocator >, std::vector >, std::less, std::allocator > >, std::allocator, std::allocator >, std::vector > > > >&, std::map >, std::less, std::allocator > > > >&, std::vector, std::allocator >, std::allocator, std::allocator > > >&, AlleleParser): Assertion `a != var.ref' failed.
Aborted (core dumped)

Samtools tview of that position reveals that 10154651 is followed by an "nc" insertion in a single read:

    10154641  10154651   10154661
cggattttcttttt*ccgggATCTGTGACgcg
.............. .................
..........      ,,,,,,,,,,,,,,,,
......                    ,,,,,,
..C...........*..
..............*..NNN......
NN.......
,,,,,,,,,,,c,nc,n,,,,,,,,,,,,,,,
.....NN.......*..........N......

It looks rather odd and probably represents an edge case that freebayes does not currently handle. I prepared an archive for Erik a while ago with a small BAM file and the reference genome. The archive although zipped is rather large and I'd like to keep the data at least pseudo-private for now, so contact me if more information and the data itself is needed to fix this bug.

In the meantime, is there anything I can do to make freebayes tolerate the site and just ignore? I suppose I can tweak my pipeline to for instance run freebayes twice, before and after the site, and then merge the outputs but that is an ugly solution :-)

Best regards,
Andreas

@andreaswallberg

Hmm, I actually get this error at several sites in several chromosomes with 0.9.5. I'll see if I can produce similar alignment snippets for those.

@andreaswallberg

This is still an issue in 0.9.6 as of 2012-05-16.

@chapmanb

Erik and Andreas;
I am running into this problem as well with the latest FreeBayes. Here is a small reproducible example BAM, which looks to have similar characteristics to Andreas' example:

https://s3.amazonaws.com/chapmanb/alt_ref_same_problem.bam

$ freebayes -f GRCh37.fa -b alt_ref_same_problem.bam -v test.vcf -r 2:133004350..133004400
@tom-bair

Here is a further test for this bug (https://xythos.uiowa.edu/tbair%40iowa.uiowa.edu/Public/test.bam), it is ABI-Solid data and your latest fix has taken care of it but hopefully this will help figure out a better way to deal with the N's

Thanks

@andreaswallberg

The error generated by my test case seems to be solved now. Freebayes prints the error message but does not crash after the recent patch.

If it is fixed for others, I suggest closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.