Floating point exception caused by `patternLen=0` triggering division by zero error.

[dgruano]

tldr; check the backtrace of the exception

I have been fighting for a couple of days trying to use snap v2.0.5 to align my reads to a Trinity transcriptome assembly, getting a "Floating Point Exception" during alignment. The triggering command is:

snap-aligner paired \ 
Trinity-GG R1.fq R2.fq \ 
-o Trinity-GG.bam -s 0 1000 -H 300000 -h 2000 \
-d 30 -t 16 -b -M -D 5 -om 5 -omax 10 -hdp

Note that the arguments used here are copied from the last version of Transrate, a quality control tool for de-novo transcriptome assembly using snap 1.0dev.96. The command with the same dataset worked with snap 1.0dev.96. If any of these arguments is not a good choice now for v2.0.5, that may be the culprit.

This happened with several of my FASTQ file pairs, so I took one and ran the same command with a subsample. After running the command three times and checking the outputs of the -hdp flag (many lines saying reporter:counter:SNAP,readsAligned,10000), I noticed the error came always at the same number of lines: maybe a particular read was the cause.

Quick inspection of the fastq files did not suggest any particular problem: all reads have the same length, all quality strings have the same length too.

I recompiled snap with -g -O0 flags and used gdb to debug the problem. Here is my log:

Thread 7 "snap-aligner" received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x2aab4595b700 (LWP 45069)]
0x00005555555c4c54 in AffineGapVectorizedWithCigar::computeGlobalScore (
    this=this@entry=0x555556b11ce0, 
    text=text@entry=0x2aaab957b4dd 'T' <repeats 19 times>, "ATTTTTTA", 'T' <repeats 12 times>, "A", 'T' <repeats 24 times>, "CCTTTTGTATTAACTTTTATTTACCTGTTAATGAAATCATCAAAATACAATGAGTAGGCACCTTCTATGTACATCTGTCCTAGTGCTTTTGAGTGTTAATCTAAACTCATACATCAACAAACATTCTAGCCGGACA"..., 
    textLen=textLen@entry=127, pattern=0x2aab4594858e "", quality=0x2aab45948d5e "", 
    patternLen=patternLen@entry=0, w=3, cigarBuf=0x2aab45946bf0 "t}\224E\253*", 
    cigarBufLen=3996, useM=true, format=BAM_CIGAR_OPS, o_cigarBufUsed=0x2aab45947bdc, 
    o_netDel=0x2aab45947cbc, o_tailIns=0x2aab45947d74) at SNAPLib/AffineGapVectorized.cpp:351
351             __m128i v_globalAlignmentScore = _mm_load_si128(Hminus1ptr + ((patternLen - 1) % numVec));
(gdb) Quit
(gdb) set logging on
Warning: 'set logging on', an alias for the command 'set logging enabled', is deprecated.
Use 'set logging enabled on'.

Copying output to gdb.txt.
Copying debug output to gdb.txt.
(gdb) bt
#0  0x00005555555c4c54 in AffineGapVectorizedWithCigar::computeGlobalScore (this=this@entry=0x555556b11ce0, text=text@entry=0x2aaab957b4dd 'T' <repeats 19 times>, "ATTTTTTA", 'T' <repeats 12 times>, "A", 'T' <repeats 24 times>, "CCTTTTGTATTAACTTTTATTTACCTGTTAATGAAATCATCAAAATACAATGAGTAGGCACCTTCTATGTACATCTGTCCTAGTGCTTTTGAGTGTTAATCTAAACTCATACATCAACAAACATTCTAGCCGGACA"..., textLen=textLen@entry=127, pattern=0x2aab4594858e "", quality=0x2aab45948d5e "", patternLen=patternLen@entry=0, w=3, cigarBuf=0x2aab45946bf0 "t}\224E\253*", cigarBufLen=3996, useM=true, format=BAM_CIGAR_OPS, o_cigarBufUsed=0x2aab45947bdc, o_netDel=0x2aab45947cbc, o_tailIns=0x2aab45947d74) at SNAPLib/AffineGapVectorized.cpp:351
#1  0x00005555555c63a7 in AffineGapVectorizedWithCigar::computeGlobalScoreNormalized (this=this@entry=0x555556b11ce0, text=text@entry=0x2aaab957b4dd 'T' <repeats 19 times>, "ATTTTTTA", 'T' <repeats 12 times>, "A", 'T' <repeats 24 times>, "CCTTTTGTATTAACTTTTATTTACCTGTTAATGAAATCATCAAAATACAATGAGTAGGCACCTTCTATGTACATCTGTCCTAGTGCTTTTGAGTGTTAATCTAAACTCATACATCAACAAACATTCTAGCCGGACA"..., textLen=127, pattern=pattern@entry=0x2aab4594858e "", quality=quality@entry=0x2aab45948d5e "", patternLen=0, k=<optimized out>, cigarBuf=<optimized out>, cigarBufLen=<optimized out>, useM=true, format=<optimized out>, o_cigarBufUsed=<optimized out>, o_addFrontClipping=<optimized out>, o_netDel=<optimized out>, o_tailIns=<optimized out>) at SNAPLib/AffineGapVectorized.cpp:1078
#2  0x00005555555baa82 in SAMFormat::computeCigar (cigarFormat=cigarFormat@entry=BAM_CIGAR_OPS, genome=0x555555618c90, ag=ag@entry=0x555556b11ce0, cigarBuf=cigarBuf@entry=0x2aab4594a054 "`\005", cigarBufLen=cigarBufLen@entry=3996, data=data@entry=0x2aab4594858e "", quality=0x2aab45948d5e "", dataLength=0, score=3, basesClippedBefore=150, extraBasesClippedBefore=0, basesClippedAfter=0, o_extraBasesClippedAfter=0x2aab45947d78, genomeLocation=203077013, useM=true, o_editDistance=0x2aab4594803c, o_cigarBufUsed=0x2aab45947d70, o_addFrontClipping=0x2aab45948050, o_backClippingMissedByLV=0x2aab45947d74) at SNAPLib/SAM.cpp:2529
#3  0x00005555555a20d3 in BAMFormat::computeCigarOps (genome=<optimized out>, ag=ag@entry=0x555556b11ce0, cigarBuf=cigarBuf@entry=0x2aab4594a050 "\004\004", cigarBufLen=cigarBufLen@entry=4000, data=0x2aab4594858e "", quality=<optimized out>, dataLength=0, score=3, basesClippedBefore=150, extraBasesClippedBefore=0, basesClippedAfter=0, frontHardClipping=0, backHardClipping=0, genomeLocation=203077013, isRC=true, useM=true, o_editDistance=0x2aab4594803c, o_addFrontClipping=0x2aab45948050, o_refSpan=0x2aab45948044) at SNAPLib/Bam.cpp:2151
#4  0x00005555555a2938 in BAMFormat::writePairs (this=0x5555556021a0, context=..., lv=0x555556ac9ce0, ag=0x555556b11ce0, useAffineGap=true, buffer=<optimized out>, bufferSpace=16777216, spaceUsed=0x2aab4594b1d0, qnameLen=0x2aab4594b1b0, reads=0x2aab4595aed0, locations=0x2aab4594b1c0, result=0x2aaaaac4f008, isSecondary=false, emitInternalScore=false, internalScoreTag=0x555556d3dfe9 "", attachAlignmen--Type <RET> for more, q to quit, c to continue without paging--
tTime=false, writeOrder=0x2aab4594b178, cumulativePositiveAddFrontClipping=0x2aab4594b170, secondReadLocationChanged=0x2aab4594b15e, outOfSpace=0x2aab4594b15f) at SNAPLib/Read.h:527
#5  0x0000555555567c8e in SimpleReadWriter::writePairs (this=0x555556ac9cc0, context=..., reads=0x2aab4595aed0, result=0x2aaaaac4f008, nResults=<optimized out>, singleResults=0x2aab4595adb0, nSingleResults=<optimized out>, firstIsPrimary=true, useAffineGap=true) at SNAPLib/ReadWriter.cpp:468
#6  0x00005555555ae912 in PairedAlignerContext::runIterationThreadImpl (this=<optimized out>, reads=reads@entry=0x2aab4595aed0) at SNAPLib/PairedAligner.cpp:875
#7  0x00005555555af154 in PairedAlignerContext::runIterationThread (this=<optimized out>) at SNAPLib/PairedAligner.cpp:471
#8  0x000055555555e7a7 in AlignerContext::runThread (this=this@entry=0x2aab434e4018) at SNAPLib/AlignerContext.cpp:233
#9  0x00005555555af182 in ParallelTask<PairedAlignerContext>::threadWorker (threadArg=0x2aab434e4018) at SNAPLib/ParallelTask.h:192
#10 0x00005555555c241a in (anonymous namespace)::runThread (infoVoidPtr=0x555556aaddb0) at SNAPLib/Compat.cpp:1565
#11 0x00002aaaab3cde25 in start_thread () from /usr/lib64/libpthread.so.0
#12 0x00002aaaab6da34d in clone () from /usr/lib64/libc.so.6

It seems that patternLen==0 is making numVec==0

snap/SNAPLib/AffineGapVectorized.cpp

Line 186 in 3f2017f

int numVec = (patternLen + VEC_SIZE - 1) / VEC_SIZE; // Number of vector segments

causing later a division by zero error in:

snap/SNAPLib/AffineGapVectorized.cpp

Line 351 in 3f2017f

__m128i v_globalAlignmentScore = _mm_load_si128(Hminus1ptr + ((patternLen - 1) % numVec));

I don't know the codebase enough, so I'm not sure how to trace back where the culprit comes from. The parameters I chose for my index or alignmen? Any default values that changed from version 1.0dev.96?

I'm happy to provide any additional info that might be helpful to troubleshoot this.

Cheers,

Dani

[bolosky]

Somehow, the read is getting totally soft-clipped to zero bases, which causes the divide by zero error in scoring. I'll see if I can come up with a repro (or if you've got an easy one, please send it to me; it'll just be one read and the contig it was trying to align to) and I'll fix it. It might be few weeks. I have to go to a wedding and then have surgery scheduled after that will make typing difficult.

[dgruano]

Hi @bolosky , thanks for getting back to me. It's not urgent, take care!

My datasets to reproduce are a human assembled transcriptome and a subset of reads, not an "easy" one, but it runs in half an hour. If I narrow down the problematic reads I will send it to you.

[bolosky]

When it crashes, if you look at the "reads" parameter to SimpleReadWriter::writePairs (0x2aab4595aed0 in your trace), it will be an array of two Read objects, which are the two reads it's trying to write. The first parameter in each of them is a char * to the read ID (this is NOT a null terminated string, so when you print it the debugger may add spew at the end). Of course, both reads will have the same ID since they're paired-end reads, so you only need to look at one.

[dgruano]

Great, thanks!

When I identify the problematic read pair, isolate it in a file and run snap again only with that read, it aligns without a problem. Even if I align the first 2M reads of my fastq (containing the problematic read pair), it also aligns without a problem. So it seems like it's dependent on the specific input file, not necessarily only the reads.

Also, I ran it on another machine with the same parameters and gave the same error, same read. I'm trying to run with less threads, in case that could be an issue but I'm getting short on ideas. Any thoughts? Happy to continue troubleshooting.

[dgruano]

Small update:

Running the same command with -t 8 gives the same error but with another read way later in the fastq.

[bolosky]

Thanks. That's a big hint, because nearly everything about snap is deterministic. I'll look at the parts that aren't Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Daniel García Ruano ***@***.***> Sent: Friday, June 13, 2025 8:43:28 AM To: amplab/snap ***@***.***> Cc: Bill Bolosky ***@***.***>; Mention ***@***.***> Subject: Re: [amplab/snap] Floating point exception caused by `patternLen=0` triggering division by zero error. (Issue #171) [https://avatars.githubusercontent.com/u/10668217?s=20&v=4]dgruano left a comment (amplab/snap#171)<#171 (comment)> Small update: Running the same command with -t 8 gives the same error but with another read way later in the fastq. — Reply to this email directly, view it on GitHub<#171 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHPTWORFCCBJVYMLH4X7533DLWSBAVCNFSM6AAAAAB6YMW6YKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNZQG44DQOJTGA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[bolosky]

Just out of curiosity, when you align one of the reads that caused a crash by itself and it doesn't crash, what does the alignment look like? In particular, does it wind up with the read being totally soft clipped? Or does at least one of the alignments look like that (you're using -om, so there may be several; I can't be sure because the relevant parameter is optimized out of the stack trace).

The stack trace looks like that's happening. But I'm having trouble figuring out how that could be nondeterministic. Really the only nondeterminism in the whole program is just assignment of reads to threads. There are a handful of resizable buffers whose size might depend on which reads were previously aligned on a given thread (they just grow to the biggest needed so far) so maybe it's related to that.

Or, I suppose, if you can regularly repro it with 2M reads, if they're not confidential you can send them to me, and I can go from there. That's not that much data.

[dgruano]

I checked the alignments and reads are not fully soft clipped, which is weird. I'll get the data ready and send it.

[bolosky]

This was a tricky one to repro because it was nondeterministic. Turns out that it only happened when we ran out of output buffer partway through writing out certain reads. I had to run it many times over many days before I managed to get it stopped in the debugger for me to work on it (and I had to do it twice because the first time Windows Update forced a reboot).

The read in question had to have multiple alignments, one of the secondary alignments had to clip the read from the back to exactly half of its length, and then the writer had to run out of output buffer space. That causes it to flush the buffer to the output pipeline, get a new buffer, and retry the write. On the retry, the back clipping was retained and would result in the original alignment being clipped to 0, resulting in the divide by zero error. Different lengths would result in incorrect alignments but no crash.

Anyway, I fixed it not to incorrectly retain the back clipping between multiple alignments of the same read.

The fix is in 2.0.6.dev.2 (in the dev branch). Try it and if it works for you, I'll push it to the main branch.

[dgruano]

Wow, that was a tricki one! I'll find some time to test it and get back to you. Thanks for all your effort into fixing this!