And compile it with (changing the -I flag as needed):
g++ -fsanitize=address -Wall -std=c++11 -ggdb3 -I/usr/local/src/SeqLib/SeqLib/htslib -I/usr/local/src/SeqLib/SeqLib -L/usr/local/src/SeqLib/SeqLib/src -L/usr/local/src/SeqLib/SeqLib/bwa -Wall -o test test.c -lhts -lseqlib -lhts -lbwa -lz -lpthread
==35523==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6160000005b8 at pc 0x7f001426a77a bp 0x7fff8eee46b0 sp 0x7fff8eee3e58
WRITE of size 2 at 0x6160000005b8 thread T0
#1 0x7f0013f7d06a in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#2 0x7f0013f7d06a in bam_aux_append /usr/local/src/SeqLib/SeqLib/htslib/sam.c:1704
#3 0x5640aed0aa3b in main /home/augustw/src/RemoveThoseNumts/test.c:44
#4 0x7f00133adb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#5 0x5640aed0a1f9 in _start (/home/augustw/src/RemoveThoseNumts/test+0x51f9)
0x6160000005b8 is located 3 bytes to the right of 565-byte region [0x616000000380,0x6160000005b5)
allocated by thread T0 here:
0 0x7f00142cfd38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38)
#1 0x5640aed194af in SeqLib::BamRecord::SetCigar(SeqLib::Cigar const&) /usr/local/src/SeqLib/SeqLib/src/BamRecord.cpp:123
#2 0x60200000019b (<unknown module>)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79779)
Shadow bytes around the buggy address:
0x0c2c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2c7fff8070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2c7fff8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2c7fff8090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2c7fff80a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c2c7fff80b0: 00 00 00 00 00 00 05[fa]fa fa fa fa fa fa fa fa
0x0c2c7fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2c7fff80d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2c7fff80e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2c7fff80f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2c7fff8100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==35523==ABORTING
The curious part is that you appear to need to both set the tag and change the cigar to induce this behavior. After reading through the error log it seems to suggest that the error is with setting the tags (either setting int tags or string z tags both trip the error), but I'm sure you could tell me better. And in case your curious, doing this with some (near) production code is causing a segfault that points to the same line of code (line 123 of BamRecord.cpp)
Any and all help is greatly appreciated!
Thanks
-August
I'm getting a heap overflow associated with memory set in the SetCigar function. The simplest way to reproduce the problem is:
include
include
include
include
include
include
include "SeqLib/RefGenome.h"
include "SeqLib/BWAWrapper.h"
include "SeqLib/FastqReader.h"
include "SeqLib/BamHeader.h"
include "SeqLib/BamWriter.h"
include "SeqLib/BamReader.h"
include "SeqLib/BamRecord.h"
using namespace SeqLib; using namespace std;
int main(int argc, char **argv) {
BamRecord r; r.init(); SeqLib::BamReader br; br.Open( "foo.bam" ); while (br.GetNextRecord(r) ) { Cigar orig = r.GetCigar();
}
}
I gave this code the catchy name "test.c"
And compile it with (changing the -I flag as needed): g++ -fsanitize=address -Wall -std=c++11 -ggdb3 -I/usr/local/src/SeqLib/SeqLib/htslib -I/usr/local/src/SeqLib/SeqLib -L/usr/local/src/SeqLib/SeqLib/src -L/usr/local/src/SeqLib/SeqLib/bwa -Wall -o test test.c -lhts -lseqlib -lhts -lbwa -lz -lpthread
And the one-read bam foo is available here:
https://www.dropbox.com/s/z0zro4pzvq9gx7r/foo.bam?dl=1
When you run ./test you get:
augustw@odin:~/src/RemoveThoseNumts$ ./test
==35523==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6160000005b8 at pc 0x7f001426a77a bp 0x7fff8eee46b0 sp 0x7fff8eee3e58 WRITE of size 2 at 0x6160000005b8 thread T0
0 0x7f001426a779 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79779)
0x6160000005b8 is located 3 bytes to the right of 565-byte region [0x616000000380,0x6160000005b5) allocated by thread T0 here:
0 0x7f00142cfd38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79779) Shadow bytes around the buggy address: 0x0c2c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c7fff8070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c7fff8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c7fff8090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c7fff80a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c2c7fff80b0: 00 00 00 00 00 00 05[fa]fa fa fa fa fa fa fa fa 0x0c2c7fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c7fff80d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c7fff80e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c7fff80f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c7fff8100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==35523==ABORTING
The curious part is that you appear to need to both set the tag and change the cigar to induce this behavior. After reading through the error log it seems to suggest that the error is with setting the tags (either setting int tags or string z tags both trip the error), but I'm sure you could tell me better. And in case your curious, doing this with some (near) production code is causing a segfault that points to the same line of code (line 123 of BamRecord.cpp)
Any and all help is greatly appreciated! Thanks -August