As reported by @jmunoz94 in bioconda/bioconda-recipes#47137, the following crashes on some platforms, e.g., Linux:

$ samtools tview -dT   -p 17:99999999999999999999 test/mpileup/mpileup.1.bam test/mpileup/mpileup.ref.fa
malloc(): invalid next size (unsorted)
Aborted

$ samtools tview -dT -p chr1:99999999999999999999 wgEncodeUwRepliSeqBg02esG1bAlnRep1.bam GRCh38.fa
malloc(): corrupted top size
Aborted

(I happened to test this with wgEncodeUwRepliSeqBg02esG1bAlnRep1.bam lying around from previously looking into #1884. This particular BAM file demonstrates some additional problems as described below.)

Using AddressSanitizer this can be quickly tracked down to a buffer overflow within bam_tview.c due to the very large position. This buffer's size was not revised when the 64-bit hts_pos_t was introduced in #1117. This PR rewrites it using faidx_fetch_seq64() instead to avoid needing to build region strings at all.

Testing this further with fewer 9s I noticed some additional problems:

$ samtools tview -d T -p chr1:999999 wgEncodeUwRepliSeqBg02esG1bAlnRep1.bam GRCh38-chr1.fa
  1000001   1000011   1000021   1000031   1000041   1000051   1000061           
GGGTGGAGCGCGCCGCCACGGACCACGGGCGNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
.....C.CA..CT.A..CA...AAG.ACCT.                                                 
.T.G.C.CA..CT.A..CA...AAG.ACCT.     

Notice that the reference line reverts to NNNNNN at positions past the reads. This turns out to be a buglet that has existed since 67392b8 in 2009! I've also fixed this in this commit: Fix tv->ref guard (compare the similar code in tv_pl_func()) so that areas with no reads show the reference rather than ...NNNNNN...

Additionally with this data file samtools goes into an infinite(?) loop when given two fewer 9s than in the original report:

$ samtools tview -d T -p chr1:999999999999999999 wgEncodeUwRepliSeqBg02esG1bAlnRep1.bam GRCh38-chr1.fa
[runs for a long time]

This can be traced to the do … while loop in hts_itr_query(), which loops perhaps forever through negative bin numbers. Possibly this code should check for a beg value massively beyond the maximum position covered by the index's bins and sidestep most of its processing. (I haven't addressed that in this PR and can raise it as an HTSlib issue if you wish.)

Finally these positions specified on the command line are well beyond 2⁶³ so are ingested as unrelated values within the range of hts_pos_t (or even negative) because hts_parse_decimal() does no overflow checking.

Looking back at PR samtools/htslib#171 there's surprisingly little discussion and no mention of overflow handling. It didn't occur to me that people would specify positions unrelated to any reality-based meaningful chromosome positions, so it didn't occur to me that people might specify numbers of such magnitude, beyond 2⁶³. This could be left as is (garbage in, garbage out! Or alternatively: Doctor, it hurts when I do this…) on the basis that such input deserves what it gets, or overflow detection could be added to hts_parse_decimal() and reported in some way.