[Debian-med-packaging] Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails)

[Nilesh Patra]

Hi,

On 07/12/24 4:25 pm, Étienne Mollier wrote:
> Hi Nilesh,
> 
> Nilesh Patra, on 2024-12-07:
>> Thanks for debugging this. The error to me appears to be here:
>>
>> https://salsa.debian.org/med-team/pbseqlib/-/blob/master/alignment/algorithms/anchoring/FindMaxIntervalImpl.hpp?ref_type=heads#L140
>>
>> and consequently at https://salsa.debian.org/med-team/pbseqlib/-/blob/master/alignment/algorithms/anchoring/FindMaxIntervalImpl.hpp?ref_type=heads#L144
>>
>> It is then trying to access matchList[m] and m is matchList.size() in the
>> first iteration which is undefined behavior.
>>
>> It should start from  matchList.size() - 1. I've pushed a fix -- do blasr
>> autopkgtest pass now?
> 
> Thanks for taking the time to diagnose the error, I have pulled
> your changes for pbseqlib, rebuilt it, then built blasr against
> the fresh pbseqlib.  I still hit a core dump though.  The back
> trace looks like:
> 
> 	#0  __pthread_kill_implementation (threadid=<optimized out>,
> 	    signo=signo at entry=6, no_tid=no_tid at entry=0) at ./nptl/pthread_kill.c:44
> 	#1  0x00007ffff71e4cef in __pthread_kill_internal (threadid=<optimized out>,
> 	    signo=6) at ./nptl/pthread_kill.c:78
> 	#2  0x00007ffff7190c42 in __GI_raise (sig=sig at entry=6)
> 	    at ../sysdeps/posix/raise.c:26
> 	#3  0x00007ffff71794f0 in __GI_abort () at ./stdlib/abort.c:79
> 	#4  0x00007ffff7530f9e in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) () from /lib/x86_64-linux-gnu/libstdc++.so.6
> 	#5  0x00005555555bacd0 in std::vector<ChainedMatchPos, std::allocator<ChainedMatchPos> >::operator[] (this=<optimized out>, __n=<optimized out>)
> 	    at /usr/include/c++/14/bits/stl_vector.h:1128
> 	#6  std::vector<ChainedMatchPos, std::allocator<ChainedMatchPos> >::operator[]
> 	    (this=<optimized out>, __n=<optimized out>)
> 	    at /usr/include/c++/14/bits/stl_vector.h:1128
> 	#7  RemoveOverlappingAnchors<std::vector<ChainedMatchPos, std::allocator<ChainedMatchPos> > > (matchList=std::vector of length 34, capacity 64 = {...})
> 	    at /usr/include/pbseq/alignment/algorithms/anchoring/FindMaxIntervalImpl.hpp:144
> 	#8  0x00005555555cd01f in MapRead<SMRTSequence, FASTASequence, SuffixArray<unsigned char, std::vector<int, std::allocator<int> >, DefaultCompareStrings<unsigned char>, DNATuple>, TupleCountTable<FASTASequence, DNATuple> > (read=...,
> 	    readRC=..., genome=..., sarray=..., bwt=..., seqBoundary=..., ct=...,
> 	    seqdb=..., params=..., metrics=..., alignmentPtrs=..., mappingBuffers=...,
> 	    mapData=<optimized out>, semaphores=...)
> 	    at ../iblasr/BlasrAlignImpl.hpp:149
> 	#9  0x0000555555591364 in MapReadsNonCCS (
> 	    mapData=mapData at entry=0x555555691f38, mappingBuffers=..., smrtRead=...,
> 	    smrtReadRC=..., subreads=std::vector of length 0, capacity 0, params=...,
> 	    associatedRandInt=@0x7fffffffa73c: 813429720, allReadAlignments=...,
> 	    threadOut=...) at ../Blasr.cpp:347
> 	#10 0x0000555555595119 in MapReads (mapData=mapData at entry=0x555555691f38)
> 	    at ../Blasr.cpp:763
> 	#11 0x000055555556c77f in main (argc=<optimized out>, argv=<optimized out>)
> 	    at ../Blasr.cpp:1376

Hmmm. Weird, it does pass on my environment :S

I will maybe try this in a fresh chroot.

> There does not seem to have been much changes.  Maybe the error
> is somewhere else?  I hope I ran the test properly, it was a bit
> intricate.

Your earlier reply to the bug report had this trace:

/usr/include/c++/14/bits/stl_vector.h:1130:
		std::vector<_Tp, _Alloc>::reference
		std::vector<_Tp, _Alloc>::operator[](size_type)
		[
			with _Tp = ChainedMatchPos;
			_Alloc = std::allocator<ChainedMatchPos>;
			reference = ChainedMatchPos&;
			size_type = long unsigned int
		]: Assertion '__n < this->size()' failed.
	/tmp/autopkgtest.WdOt0L/build.sPS/src/debian/tests/run-unit-

The Assertion failure "'__n < this->size()' failed." indicates that the 
index is going out of bounds in the vector. (upper bound)

Do you still see this trace? If so, maybe the versions are not tested 
correctly?

-n