search

Genomicus / bedtools

Automatically exported from code.google.com/p/bedtools
0 stars 0 forks source link

bamToBed error:"terminate called after throwing an instance of 'std::out_of_range'" #162

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. bamToBed -i foo.bam -split

on the following foo.bam file

@HD VN:1.4  GO:none SO:coordinate       
@SQ SN:chr9 LN:124076172            
@RG ID:sample1  PL:IONTORRENT   LB:lib1 SM:sample1  
DI8BD:05389:09916   0   chr9    57332309    3   54M712N47M  *   0   0   CACAAACACTTTACATGGACCTTCATG
TCAAACTTGGTTTACCCAGGATCATTCCACAGGGATAACTGGCTTGTGGCGGCCAAGCGTTCATAGCGACGTCG  55588
49;::@28////*0:5=7;<=999;;58:7<077*788*5:477///)/)0088:2::;688848<4889388486:6:9
99268::8:8/////,    X2:i:40 MD:Z:101    RG:Z:sample1    NH:i:4  HI:i:1  NM:i:0  SM:i:3  XQ:i:
40  XS:A:-  XV:i:0  XW:i:0

What is the expected output? What do you see instead?
Expected: 
Output two lines in bed file, one for each side of split read
Observed: 
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr
/software/common/bedtools/git/bin/bamToBed: line 2: 16927 Aborted               
  ${0%/*}/bedtools bamtobed "$@"

What version of the product are you using? On what operating system?
Tool:    bedtools bamtobed (aka bamToBed)
Version: v2.17.0-81-g3b468dd-dirty

Linux RHEL 2.6.18-274.el5 

Please provide any additional information below.
I looked in previous posts that reported a related error but I am using a 
version later than the 'fix' in 2010 (see Issue 4: bamToBed cannot convert 
spliced alignments) and my seq header has the right chromosome, so I've run out 
of ideas to troubleshoot.

Original issue reported on code.google.com by sonia.le...@gmail.com on 24 Sep 2013 at 3:02

GoogleCodeExporter commented 9 years ago 
Hi,

All three of your SAM header lines have extra tabs at the end.  This is against 
the SAM specification and as such, it causes BAMTOOLS (the BAM liubrary that 
bedtools uses to be unable to properly read the header.  If I remove the extra 
tabs and convert the result to BAM, all is well.

The "^I" symbols below are TABs.

cat -t test.sam
@HD^IVN:1.4^IGO:none^ISO:coordinate^I^I
@SQ^ISN:chr9^ILN:124076172^I^I^I
@RG^IID:sample1^IPL:IONTORRENT^ILB:lib1^ISM:sample1^I
DI8BD:05389:09916^I0^Ichr9^I57332309^I3^I54M712N47M^I*^I0^I0^ICACAAACACTTTACATGG
ACCTTCATGTCAAACTTGGTTTACCCAGGATCATTCCACAGGGATAACTGGCTTGTGGCGGCCAAGCGTTCATAGCGACG
TCG^I5558849;::@28////*0:5=7;<=999;;58:7<077*788*5:477///)/)0088:2::;688848<4889
388486:6:999268::8:8/////,^IX2:i:40^IMD:Z:101^IRG:Z:sample1^INH:i:4^IHI:i:1^INM:
i:0^ISM:i:3^IXQ:i:40^IXS:A:-^IXV:i:0^IXW:i:0

Original comment by aaronqui...@gmail.com on 24 Sep 2013 at 4:37

GoogleCodeExporter commented 9 years ago 
perfect! It works for me too. Our BAMS came from GSNAP so we are
alerting the author of that tool as well.

Thank you so much.

Original comment by sonia.le...@gmail.com on 24 Sep 2013 at 4:50

GoogleCodeExporter commented 9 years ago 
scratch that - seems we post-processed GSNAP and introduced the error
ther, so the GSNAP output is fine.

Original comment by sonia.le...@gmail.com on 24 Sep 2013 at 4:52