samtools 1.20
htslib 1.20
Linux 3.10.0-1160.71.1.el7.x86_64

Hi,
when extracting reads overlapping particular sets of intervals with -M, on some CRAMs but not all (despite the fact that all were generated by the same pipeline), samtools throws the following error before [not] producing a single read:

Segmentation fault (core dumped)

The command:

samtools view -T ${REFERENCE} -F 3840 -M -L ${BED} ${CRAM}

Initially, I thought it could be something wrong with the CRAM indices but after regenerating them, the problem persisted. Removing some intervals from the BED file results, for the most part, in successful executions but it's unclear why. Splitting the interval file can also result in successful executions. It's quite puzzling why some combinations of intervals don't go well with particular CRAMs.

I manage to replicate the behavior on a few of the high-coverage 1000 Genomes Project CRAMs that can be pulled via FTP:

Successful CRAM path:
ftp://ftp-trace.ncbi.nlm.nih.gov/1000genomes/ftp/1000G_2504_high_coverage/data/ERR3240128/HG00112.final.cram
ftp://ftp-trace.ncbi.nlm.nih.gov/1000genomes/ftp/1000G_2504_high_coverage/data/ERR3240128/HG00112.final.cram.crai

Unsuccessful CRAM path:
ftp://ftp-trace.ncbi.nlm.nih.gov/1000genomes/ftp/1000G_2504_high_coverage/data/ERR3240129/HG00113.final.cram
ftp://ftp-trace.ncbi.nlm.nih.gov/1000genomes/ftp/1000G_2504_high_coverage/data/ERR3240129/HG00113.final.cram.crai

BED file:
test.bed.gz

I tried earlier versions, down to 1.12, and had the same error. Version 1.10 appears to be working fine, even though it is very slow on this type of operation, compared to more recent versions (when they work).

Please let me know if you didn't manage to replicate the behavior and/or if there's any additional information I should provide.

Thanks!