10XGenomics / bamtofastq

Convert 10x BAM files to the original FASTQs compatible with 10x pipelines
MIT License
59 stars 6 forks source link

_thread 'main' panicked at 'not a string' running bamtofastq #1

Closed guilhermesena1 closed 5 years ago

guilhermesena1 commented 6 years ago

I'm trying to run bamtofastq on a BAM file generated by cellranger count (cellranger version 1.3) but I got the following error:

thread 'main' panicked at 'not a string', /home/sena/.cargo/registry/src/github.com-1ecc6299db9ec823/rust-htslib-0.12.1/src/bam/record.rs:367:18

I'm attaching the first 4 lines of the bam file I used, which are enough to reproduce the error.

The command I used was straightforward:

_RUSTBACKTRACE=1 ./bamtofastq debug.bam.txt test

This is the RUST_BACKTRACE=1 output. It seems like this is an error using string() in the htslib. I'm not sure how to fix this so any help would be greatly appreciated. Thank you!

stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::print at /checkout/src/libstd/sys_common/backtrace.rs:68 at /checkout/src/libstd/sys_common/backtrace.rs:57 2: std::panicking::default_hook::{{closure}} at /checkout/src/libstd/panicking.rs:381 3: std::panicking::default_hook at /checkout/src/libstd/panicking.rs:397 4: std::panicking::rust_panic_with_hook at /checkout/src/libstd/panicking.rs:577 5: std::panicking::begin_panic at /checkout/src/libstd/panicking.rs:538 6: rust_htslib::bam::record::Aux::string at /home/sena/.cargo/registry/src/github.com-1ecc6299db9ec823/rust-htslib-0.12.1/src/bam/record.rs:367 7: bamtofastq::FormatBamRecords::bam_rec_to_fq at src/main.rs:515 8: bamtofastq::FormatBamRecords::format_read at src/main.rs:595 9: bamtofastq::proc_single_ended at src/main.rs:1065 10: bamtofastq::inner at src/main.rs:950 11: bamtofastq::go at src/main.rs:865 12: bamtofastq::run at src/main.rs:846 13: bamtofastq::main at src/main.rs:815 14: std::rt::lang_start::{{closure}} at /checkout/src/libstd/rt.rs:74 15: std::panicking::try::do_call at /checkout/src/libstd/rt.rs:59 at /checkout/src/libstd/panicking.rs:480 16: rust_maybe_catch_panic at /checkout/src/libpanic_unwind/lib.rs:101 17: std::rt::lang_start_internal at /checkout/src/libstd/panicking.rs:459 at /checkout/src/libstd/panic.rs:365 at /checkout/src/libstd/rt.rs:58 18: std::rt::lang_start at /checkout/src/libstd/rt.rs:74 19: main 20: __libc_start_main 21: _start__

debug.bam.txt debug.sam.txt

jnotwell commented 5 years ago

I encountered the same problem.

I'm working with bamtofastq v1.1.2 and this BAM file (SRA link). Ubuntu 18.04.2 LTS

export RUST_BACKTRACE=1

./bamtofastq temp.bam temp
bamtofastq v1.1.2
Args { arg_bam: "temp.bam", arg_output_path: "temp", flag_locus: None, flag_bx_list: None, flag_reads_per_fastq: 50000000, flag_gemcode: false, flag_lr20: false, flag_cr11: false }
thread 'main' panicked at 'not a string', /mnt/home/pat/.cargo/registry/src/github.com-1ecc6299db9ec823/rust-htslib-0.12.1/src/bam/record.rs:367:18
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at /checkout/src/libstd/sys_common/backtrace.rs:68
             at /checkout/src/libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: rust_htslib::bam::record::Aux::string
             at /mnt/home/pat/.cargo/registry/src/github.com-1ecc6299db9ec823/rust-htslib-0.12.1/src/bam/record.rs:367
   7: bamtofastq::FormatBamRecords::bam_rec_to_fq
             at src/main.rs:511
   8: bamtofastq::FormatBamRecords::format_read
             at src/main.rs:585
   9: bamtofastq::inner
             at src/main.rs:1050
             at src/main.rs:935
  10: bamtofastq::main
             at src/main.rs:850
             at src/main.rs:831
             at src/main.rs:800
  11: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  12: std::panicking::try::do_call
             at /checkout/src/libstd/rt.rs:59
             at /checkout/src/libstd/panicking.rs:480
  13: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:101
  14: std::rt::lang_start_internal
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/panic.rs:365
             at /checkout/src/libstd/rt.rs:58
  15: main
  16: __libc_start_main
  17: <unknown>
             at ../sysdeps/x86_64/elf/start.S:103
guilhermesena1 commented 5 years ago

Hi Jim,

This was a compatibility issue with how bam files were generated in older versions of cellranger. The TR and TQ tags are treated as single characters (should be 'A') but should be strings ('Z')

You can "fix" the bam by running

samtools view -h broken.bam | sed -e 's/TR:A:/TR:Z:/; s/TQ:A:/TQ:Z:/' | samtools view -Sb - > fixed.bam

And then fixed.bam should be accepted by bamtofastq.

Hope this helps!

pmarks commented 5 years ago

@guilhermesena1 thanks for the tip, I wasn't aware of this workaround. I'm going to add a fix to bamtofastq that will handle the single-char tags as well as the string tags.

pmarks commented 5 years ago

@guilhermesena1 @jnotwell fixed on master - thanks for the report.