Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.rc > #376707 > unrolled thread

Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails)

Started byÉtienne Mollier <emollier@debian.org>
First post2024-11-20 22:00 +0100
Last post2024-12-08 10:00 +0100
Articles 6 — 3 participants

Back to article view | Back to linux.debian.bugs.rc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails) Étienne Mollier <emollier@debian.org> - 2024-11-20 22:00 +0100
    Processed: Re: Bug#1067374: blasr: FTBFS fixed by itself (but  autopkgtest fails) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-11-20 22:00 +0100
    Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails) Nilesh Patra <nilesh@riseup.net> - 2024-12-07 10:40 +0100
      Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails) Étienne Mollier <emollier@debian.org> - 2024-12-07 12:00 +0100
        Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails) Nilesh Patra <nilesh@riseup.net> - 2024-12-07 14:50 +0100
          Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails) Nilesh Patra <nilesh@riseup.net> - 2024-12-08 10:00 +0100

#376707 — Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails)

FromÉtienne Mollier <emollier@debian.org>
Date2024-11-20 22:00 +0100
SubjectBug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails)
Message-ID<JKZXP-ajXv-3@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Control: retitle -1 blasr: autopkgtest failure: core dump
Control: tags -1 + help

Hi,

Lucas Nussbaum, on 2024-03-20:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > /usr/bin/ld: libblasr_impl.a.p/extrautils_StoreQualityByContextFromCmpH5.cpp.o: in function `main':
> > ./obj-x86_64-linux-gnu/../extrautils/StoreQualityByContextFromCmpH5.cpp:40:
> > 	multiple definition of `main';
> > 	toAfg.p/utils_ToAfg.cpp.o:./obj-x86_64-linux-gnu/../utils/ToAfg.cpp:30:
> > 	first defined here
> > collect2: error: ld returned 1 exit status

This is interesting, I unravelled this bug out of the blue and
tried to reproduce it, but the build went through.  I suspect
that whatever was broken in blasr build-dependency went fixed,
such that the build now goes through.

That being said, I am not closing this bug, because blasr
autopkgtest reveals an issue in the program.  The autopkgtest
run looks like:

	autopkgtest [21:19:17]: test run-unit-test: [-----------------------
	[INFO] 2024-11-20T20:19:18 [blasr] started.
	/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-test:
		line 16: 216319 Aborted                 (core dumped)
		blasr query.fasta ref.fa --sam --out alignment.sam
	autopkgtest [21:19:18]: test run-unit-test: -----------------------]

The backtrace obtained out of the debugger looks like:

	#0  __pthread_kill_implementation (threadid=<optimized out>, 
	    signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
	#1  0x00007ffff71e4ebf in __pthread_kill_internal (threadid=<optimized out>, 
	    signo=6) at ./nptl/pthread_kill.c:78
	#2  0x00007ffff7190c82 in __GI_raise (sig=sig@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@entry=0x555555691f38, mappingBuffers=..., smrtRead=..., 
	    smrtReadRC=..., subreads=warning: Type size unknown, assuming 1. Try casting to a known type, or void *.
	warning: Type size unknown, assuming 1. Try casting to a known type, or void *.
	std::vector of length 0, capacity 0, params=..., 
	    associatedRandInt=@0x7fffffffa74c: 1658411691, allReadAlignments=..., 
	    threadOut=...) at ../Blasr.cpp:347
	#10 0x0000555555595119 in MapReads (mapData=mapData@entry=0x555555691f38)
	    at ../Blasr.cpp:763
	#11 0x000055555556c77f in main (argc=<optimized out>, argv=<optimized out>)
	    at ../Blasr.cpp:1376

This file:
/usr/include/pbseq/alignment/algorithms/anchoring/FindMaxIntervalImpl.hpp
happens to be part of the libblasr-dev, so it seems the issue
might be self contained in the package.  Trying to liaise
upstream for help with resolving this issue, I realized that the
declared Homepage returns http not found error, and the url
referenced in the watch file shows an archive repository that
has not seen any changes for the past 11 years.  I'm afraid
blasr is becoming a lost cause.

Anyway, in hope this inspires someone,
-- 
  .''`.  Étienne Mollier <emollier@debian.org>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/4, please excuse my verbosity
   `-    on air: Peter Gabriel - Here Comes The Flood

[toc] | [next] | [standalone]


#376709 — Processed: Re: Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails)

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2024-11-20 22:00 +0100
SubjectProcessed: Re: Bug#1067374: blasr: FTBFS fixed by itself (but autopkgtest fails)
Message-ID<JKZXP-ajXv-13@gated-at.bofh.it>
In reply to#376707
Processing control commands:

> retitle -1 blasr: autopkgtest failure: core dump
Bug #1067374 [src:blasr] blasr: FTBFS: ./obj-x86_64-linux-gnu/../extrautils/StoreQualityByContextFromCmpH5.cpp:40: multiple definition of `main'; toAfg.p/utils_ToAfg.cpp.o:./obj-x86_64-linux-gnu/../utils/ToAfg.cpp:30: first defined here
Changed Bug title to 'blasr: autopkgtest failure: core dump' from 'blasr: FTBFS: ./obj-x86_64-linux-gnu/../extrautils/StoreQualityByContextFromCmpH5.cpp:40: multiple definition of `main'; toAfg.p/utils_ToAfg.cpp.o:./obj-x86_64-linux-gnu/../utils/ToAfg.cpp:30: first defined here'.
> tags -1 + help
Bug #1067374 [src:blasr] blasr: autopkgtest failure: core dump
Added tag(s) help.

-- 
1067374: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067374
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#377796

FromNilesh Patra <nilesh@riseup.net>
Date2024-12-07 10:40 +0100
Message-ID<JQZs5-eot2-3@gated-at.bofh.it>
In reply to#376707
On Wed, 20 Nov 2024 21:48:23 +0100 =?utf-8?Q?=C3=89tienne?= Mollier 
<emollier@debian.org> wrote:
> Control: retitle -1 blasr: autopkgtest failure: core dump
> Control: tags -1 + help
> ...
> 	#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=..., 

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?

If it looks fine, could you sponsor me an upload?

Thanks
Nilesh

[toc] | [prev] | [next] | [standalone]


#377798

FromÉtienne Mollier <emollier@debian.org>
Date2024-12-07 12:00 +0100
Message-ID<JR0Hw-ep89-5@gated-at.bofh.it>
In reply to#377796

[Multipart message — attachments visible in raw view] — view raw

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@entry=6, no_tid=no_tid@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@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@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@entry=0x555555691f38)
	    at ../Blasr.cpp:763
	#11 0x000055555556c77f in main (argc=<optimized out>, argv=<optimized out>)
	    at ../Blasr.cpp:1376

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.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <emollier@debian.org>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-

[toc] | [prev] | [next] | [standalone]


#377807

FromNilesh Patra <nilesh@riseup.net>
Date2024-12-07 14:50 +0100
Message-ID<JR3m1-eqN4-3@gated-at.bofh.it>
In reply to#377798
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@entry=6, no_tid=no_tid@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@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@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@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

[toc] | [prev] | [next] | [standalone]


#377869

FromNilesh Patra <nilesh@riseup.net>
Date2024-12-08 10:00 +0100
Message-ID<JRliV-eEqG-1@gated-at.bofh.it>
In reply to#377807

On 07/12/24 18:53, Nilesh Patra wrote:
> On 07/12/24 4:25 pm, Étienne Mollier wrote:
>> 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?ensuring blasr is built against patches pbseqlib?

I tried this on a debian:unstable docker container and it does seem to pass for me

On plain build of blasr:

root@306d2e75fdf4:~/blasr-5.3.5+dfsg# bash ./debian/tests/run-unit-test
[INFO] 2024-12-08T08:46:54 [blasr] started.
/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.
Aborted (core dumped)


With pbseqlib patched and installed on the container, and building blasr against it:

root@306d2e75fdf4:~/blasr-5.3.5+dfsg# bash ./debian/tests/run-unit-test
[INFO] 2024-12-08T08:48:39 [blasr] started.
[INFO] 2024-12-08T08:48:39 [blasr] ended.
[INFO] 2024-12-08T08:48:39 [blasr] started.
[INFO] 2024-12-08T08:48:39 [blasr] ended.
alignment.sam
@HD	VN:1.5	SO:UNKNOWN	pb:3.0.1
@SQ	SN:test/0/0_68	LN:59	M5:157f8fd9cd009034b02081c9fa7a1084
@RG	ID:e70794ea	PL:PACBIO	DS:READTYPE=SUBREAD;DeletionQV=dq;DeletionTag=dt;InsertionQV=iq;MergeQV=mq;SubstitutionQV=sq	PU:query.fasta	PM:SEQUEL
@PG	ID:1	PN:BLASR	VN:5.3.5-5.3.5	CL:blasr query.fasta ref.fa --sam --out alignment.sam
movie/0/0_51	0	test/0/0_68	1	254	50=1S	*	0	0	ATGTCAGTGACGATGACAGTAGACAGATAGAGAGGAGAGATAGACAGATAG	*	RG:Z:e70794ea	np:i:1	qe:i:51	qs:i:0	zm:i:0	AS:i:-250	NM:i:0
alignment.sam.check:
@HD	VN:1.5	SO:UNKNOWN	pb:3.0.1
@SQ	SN:test/0/0_68	LN:59	M5:157f8fd9cd009034b02081c9fa7a1084
@RG	ID:e70794ea	PL:PACBIO	DS:READTYPE=SUBREAD;DeletionQV=dq;DeletionTag=dt;InsertionQV=iq;MergeQV=mq;SubstitutionQV=sq	PU:query.fasta	PM:SEQUEL
@PG	ID:1	PN:BLASR	VN:VERSION	CL:blasr query.fasta ref.fa --sam --out alignment.sam
movie/0/0_51	0	test/0/0_68	1	254	50=1S	*	0	0	ATGTCAGTGACGATGACAGTAGACAGATAGAGAGGAGAGATAGACAGATAG	*	RG:Z:e70794ea	np:i:1	qe:i:51	qs:i:0	zm:i:0	AS:i:-250	NM:i:0
output: OK
alignment.sam.check: OK
Expected output and generated output are same: PASS Test

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.bugs.rc


csiph-web