bedtools coverage gives error received illegal bin number, but that number isn't in my data!

Question

[tara.alpert]

I am trying to calculate the coverage of a ChIP data set over a very limited set of gene coordinates. I have very simple bed files for both (after trying to eliminate any cause of the error) that are just the bare bones "chr start end" columns, and every time I run the command:

bedtools coverage -a a.bed -b b.bed

I get this error:

ERROR: Received illegal bin number 4294967295 from getBin call.
ERROR: Unable to add record to tree

I used grep to search for this number and it's nowhere to be found in either of my files, which makes sense given that my genome isn't that big. So why am I still getting this error?

Thanks for your input!

[Alex Reynolds]

4294967295 is a special number. Maybe an overflow error somewhere with an unsigned integer.

[tara.alpert]

Hmm interesting, could you explain a little more? I'm not terribly experienced yet.

[Alex Reynolds]

It's not your fault, probably, but when you see that number pop up, it usually indicates that an unsigned integer is being used incorrectly to store a negative number (which is signed).

[tara.alpert]

Ok, thanks so much. Any idea how to correct it?

[Alex Reynolds]

No idea. You might contact the developers.

[igor]

Can you provide a few lines of those BED files?

[tara.alpert]

a.bed

chrI   1001       1080
chrI   1003       1076
chrI   1008       1102

b.bed

chrI   143160   143210
chrII  126119   126169
chrII  142868   142918

[brianpenghe]

I got the same error and the cause was a little bit different:

In the bed file I downloaded there were lines with third column missing!

chr1    3139719
chr1    12645719
chr1    12959919
chr1    14960519
chr1    24616961
chr1    24808855
chr1    26688455
chr1    33991955
chr1    63630926
chr1    73551026

That file was claimed to be derived from UCSC liftover. So I suppose liftover program might have produced something partial?

[pangxy3]

I got same error when using subtract of bedtools. And I have tried to use bedops to check one of my input file:

bedops --ec --everything final.utr.raw.bed

I got this:

chr1    14361   29370   WASH7P_mergedExon_1 15010   -
chr1    17368   17436   MIR6859-1_mergedExon_1  69  -
chr1    29925   31295   LOC107985730_mergedExon_1   1371    +
chr1    30365   30503   MIR1302-2_mergedExon_1  139 +
chr1    34610   36081   FAM138A_mergedExon_1    1472    -
May use bedops --help for more help.

Error: in final.utr.raw.bed
End coordinates must be greater than start coordinates.
See row: 8

Then I used awk to delete illegal lines

awk '($2<$3){print $0}' final.utr.raw.bed > final.utr.bed

then subtract got right answer.

[Alex Reynolds]

You can also use awk to fix the input before running it through bedops:

$ awk -vFS="\t" -vOFS="\t" '{ if ($2 == $3) { $2--; } if ($2 > $3) { t = $3; $3 = $2; $2 = $3; } print $0; }' final.utr.raw.bed | sort-bed - | bedops --operations ... > answer.bed

You don't necessarily need to delete "illegal" lines, although you could if it makes sense to do so.

[iqra]

I am facing the same error. kindly guide me how i can i solve it.

> bedtools intersect -a SPRINT_identified_all.res.col3 -b wheat_col6.bed -wa -wb > output.bed
`ERROR: Received illegal bin number 37458 from getBin call.
ERROR: Unable to add record to tree.`

[Ram]

Please use the formatting bar (especially the code option) to present your post better. You can use backticks for inline code (`text` becomes text), or select a chunk of text and use the highlighted button to format it as a code block. I've done it for you this time.

[ATpoint]

Did you check the proposed solutions (hidden characters) etc?

Answer 1

[igor]

The BED files look reasonable.

Maybe there are invisible characters somewhere in the file? Can you try running mac2unix or dos2unix on them?

[tara.alpert]

This resolved the error... THANK YOU SO MUCH!

[ataaillah]

Hi ! I have the same problem ! could you please show the command you used with mac2unix to solve it ? thanks

[orlando.wong]

worked for me also! thanks!

[boczniak767]

I have the same error, it turns out that my bed file has positions reversed. So start coordinate was higher than stop.

Answer 2

[Alex Reynolds]

You can use bedops --ec <options> to do sanity checks on BED input:

$ echo -e 'chrZ\t123\t123' | bedops --ec --everything -
May use bedops --help for more help.

Error: in stdin
End coordinates must be greater than start coordinates.
See row: 1

The --ec makes operations take longer to complete, but it can be useful for identifying these and other common interval problems. For instance, non-Unix line endings in three-column BED:

$ echo -e 'chrZ\t123\t124\r' | cat -te
chrZ^I123^I124^M$

A bedops --ec run will report problems with the end coordinate:

$ echo -e 'chrZ\t123\t124\r' | bedops --ec --everything -
May use bedops --help for more help.

Error: in stdin
End coordinate contains non-numeric character:
See row: 1

You can then use awk or dos2unix or similar to clean up your BED.

The --ec option is also available in bedmap, as well as bedops.

Once you can "trust" that your BED data are "clean", you can remove the --ec option and recover the performance improvements.

[Ivan]

I had the same problem. In my case, the cause was the fact that some of the lines in bed file were in reverse order, e. g.

chr1    1134661    1134612

(value in column 3 is smaller than than in column 2), so simply

awk '{
if ($2 <=$3)
    print $0;
else
    print $1, $3, $2;
}' H1.txt > H2.txt

Solved the problem!

[Ram]

I'm moving this to a comment on Alex's answer as it is the awk complement to his start < end detection step.

Answer 3

[soloway]

I got the very same error code using bedtools intersect.

I used the following bash command to remove non-alpha numerical characters from bed1.bed. The resulting bed2.bed did not throw an error.

bed1.bed | sed "s/\W\W/\t/g" > bed2.bed

I did have strand info (+ or -) that was removed in the process.

Answer 4

[apa@stowers]

This can also happen if you have double-0 intervals, AND are using bedTools > 2.24.0.

Basically if one of your bed files has a line like

chrX  0  0  ...

intersectBed v2.24.0 will run it successfully, but intersectBed v2.26.0 will throw the error

Received illegal bin number 4294967295

yes with that exact same number 4294967295. At least, it did that on my CentOS7 box.

I prevent this by running something like:

cat original.bed | awk '{ if ($2!=$3) print $0 }' > fixed.bed

since BED data is 0-based and thus should never have start == end anyway...

Answer 5

[pengchy]

In my case, this problem is caused by the multiple space, which could be replaced by the following one line command:

perl -ne 'chomp;s/\s+/\t/g;print $_,"\n"'