Timeline for Error while calling bcftools mpileup - Failed to open -: unknown file type
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 30, 2021 at 19:04 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Nov 30, 2020 at 18:06 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Aug 2, 2020 at 17:07 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Apr 4, 2020 at 17:02 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Dec 6, 2019 at 16:02 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Aug 8, 2019 at 15:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jul 9, 2019 at 13:42 | comment | added | BCArg |
Just tried to run the original command (as in my question) on a cluster (24 cores, 48GB of RAM). It ran for an hour or so, then I got the same error Failed to open -: unknown file type, so I guess I will try some commands without piping to bcftools to see what output I will get
|
|
| Jul 9, 2019 at 10:07 | comment | added | John Marshall | Oh yeah, SIGKILL. Perhaps you were hit by the OOM Killer (cf stackoverflow.com/questions/12288550/…) so the lack of error message maybe isn't bcftools's fault. 14G isn't a big BAM file, but the level of coverage and nature of ONT data (long reads with maybe interesting CIGARs) would be things that could make mpileup take more than the usual amount of memory. | |
| Jul 9, 2019 at 9:58 | comment | added | BCArg |
Just before the program got killed I got Program terminated with signal SIGKILL, Killed. The program no longer exists. The output of backtrace was No stack That you cannot reproduce this error on non-ONT data, you think it can be related to the size of my input files? My bam is 14GB (coverage is about 2.000, we ran for about 48h, which we won't do routinely)
|
|
| Jul 9, 2019 at 9:17 | comment | added | John Marshall |
The latter is quite easy: run gdb --args bcftools mpileup -f ref_genbank/ref_genbank.fasta -o /dev/null ref494_aligned.sorted.bam, then type run and wait for it to crash. Then type backtrace; the output from this will be instructive.
|
|
| Jul 9, 2019 at 9:12 | comment | added | John Marshall | As noted below, killed due to memory exhaustion. However: you deserve an error message. Mpileup typically doesn't use that much memory and I have been unable to reproduce this on (non-ONT) data here. If you are able to, it would be interesting to try current develop bcftools to see if this still happens and/or to run it under the debugger and see where it crashes. | |
| Jul 9, 2019 at 7:49 | comment | added | BCArg |
I got Killed output to the terminal after a minute or two. Also this command generates an empty output.tmp file.
|
|
| Jul 9, 2019 at 7:28 | comment | added | John Marshall |
Please capture the output of the first command and show us the first few lines (via bcftools view if it's not text): bcftools mpileup -f ref_genbank/ref_genbank.fasta ref494_aligned.sorted.bam > output.tmp
|
|
| Jul 9, 2019 at 5:43 | answer | added | gringer♦ | timeline score: 1 | |
| Jul 8, 2019 at 16:15 | answer | added | terdon♦ | timeline score: 1 | |
| Jul 8, 2019 at 15:00 | review | First posts | |||
| Jul 8, 2019 at 18:09 | |||||
| Jul 8, 2019 at 14:59 | history | asked | BCArg | CC BY-SA 4.0 |