oasis-velvet crashing with glibc error

[nickschurch]

I'm running oasis-velvet on a dataset of single-end 50bp data and its crashing for me with a glibc error. I could really use some help figuring out how fix/get round this issue and persuade it to assemble. Any help, greatly appreciated...

The details are below. Interestingly, I've successfully run this on a bunch of other similar datasets in the experiment so its either something specific about this data or an edge case. Anyway, details:

python: 2.7.3
oases: 0.2.09
velvet: 1.2.10
OS: CentOS release 6.8 (Final)
glibc: 2.12

command-line:
oases_pipeline.py -m 19 -M 29 -s 2 -o oasisvelvet -c -p ' -cov_cutoff 5 -ins_length 200 ' -d ' -short -fastq.gz SEreads.fastq.gz'

Error:
*** glibc detected *** oases: double free or corruption (!prev): 0x000000003323b480 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3fc3675366]
/lib64/libc.so.6[0x3fc3677e93]
oases[0x4163fd]
oases[0x42663e]
oases[0x42687e]
oases[0x40d536]
oases[0x4023fd]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3fc361ecdd]
oases[0x401839]
======= Memory map: ========
00400000-0043b000 r-xp 00000000 00:14 131796078 /cluster/gjb_lab/software/centos6.3/opt/oases-0.2.09/oases
0063b000-0063c000 rw-p 0003b000 00:14 131796078 /cluster/gjb_lab/software/centos6.3/opt/oases-0.2.09/oases
00d45000-33308000 rw-p 00000000 00:00 0 [heap]
30dc400000-30dc415000 r-xp 00000000 fd:01 172801 /lib64/libz.so.1.2.3
30dc415000-30dc614000 ---p 00015000 fd:01 172801 /lib64/libz.so.1.2.3
30dc614000-30dc615000 r--p 00014000 fd:01 172801 /lib64/libz.so.1.2.3
30dc615000-30dc616000 rw-p 00015000 fd:01 172801 /lib64/libz.so.1.2.3
3fc2e00000-3fc2e20000 r-xp 00000000 fd:01 143774 /lib64/ld-2.12.so
3fc301f000-3fc3020000 r--p 0001f000 fd:01 143774 /lib64/ld-2.12.so
3fc3020000-3fc3021000 rw-p 00020000 fd:01 143774 /lib64/ld-2.12.so
3fc3021000-3fc3022000 rw-p 00000000 00:00 0
3fc3600000-3fc3789000 r-xp 00000000 fd:01 160780 /lib64/libc-2.12.so
3fc3789000-3fc3988000 ---p 00189000 fd:01 160780 /lib64/libc-2.12.so
3fc3988000-3fc398c000 r--p 00188000 fd:01 160780 /lib64/libc-2.12.so
3fc398c000-3fc398d000 rw-p 0018c000 fd:01 160780 /lib64/libc-2.12.so
3fc398d000-3fc3992000 rw-p 00000000 00:00 0
3fc3e00000-3fc3e83000 r-xp 00000000 fd:01 144274 /lib64/libm-2.12.so
3fc3e83000-3fc4082000 ---p 00083000 fd:01 144274 /lib64/libm-2.12.so
3fc4082000-3fc4083000 r--p 00082000 fd:01 144274 /lib64/libm-2.12.so
3fc4083000-3fc4084000 rw-p 00083000 fd:01 144274 /lib64/libm-2.12.so
3ffbe00000-3ffbe16000 r-xp 00000000 fd:01 131080 /lib64/libgcc_s-4.4.7-20120601.so.1
3ffbe16000-3ffc015000 ---p 00016000 fd:01 131080 /lib64/libgcc_s-4.4.7-20120601.so.1
3ffc015000-3ffc016000 rw-p 00015000 fd:01 131080 /lib64/libgcc_s-4.4.7-20120601.so.1
2b9346dc3000-2b9346dc4000 rw-p 00000000 00:00 0
2b9346ddb000-2b9346dde000 rw-p 00000000 00:00 0
2b9346e5e000-2b9346e7e000 rw-p 00000000 00:00 0
2b9346f25000-2b9346f62000 rw-p 00000000 00:00 0
2b93470b2000-2b93470d1000 rw-p 00000000 00:00 0
2b934744f000-2b93474f3000 rw-p 00000000 00:00 0
2b934756f000-2b9347663000 rw-p 00000000 00:00 0
2b93476de000-2b934772a000 rw-p 00000000 00:00 0
2b9347776000-2b93478a7000 rw-p 00000000 00:00 0
2b934792b000-2b934794c000 rw-p 00000000 00:00 0
2b93488dc000-2b934891c000 rw-p 00000000 00:00 0
2b9348998000-2b9348a1e000 rw-p 00000000 00:00 0
2b9348cf0000-2b9348d4e000 rw-p 00000000 00:00 0
2b9348d8d000-2b9348dcb000 rw-p 00000000 00:00 0
2b934edb7000-2b9361c3f000 rw-p 00000000 00:00 0
7fffa42ec000-7fffa4302000 rw-p 00000000 00:00 0 [stack]
7fffa43c0000-7fffa43c1000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Traceback (most recent call last):
File "/gridware/sge/default/spool/pe-004/job_scripts/3730890", line 130, in
main()
File "/gridware/sge/default/spool/pe-004/job_scripts/3730890", line 124, in main
singleKAssemblies(options)
File "/gridware/sge/default/spool/pe-004/job_scripts/3730890", line 55, in singleKAssemblies
assert p.returncode == 0, "Oases failed at k = %i\n%s" % (k, output[0])
AssertionError: Oases failed at k = 23
[0.000000] Reading graph file oasisvelvet_23/Graph2
[0.000711] Graph has 101546 nodes and 12142408 sequences
[50.977521] Reading read set file oasisvelvet_23/Sequences;
[66.599784] 12142408 sequences found
[98.252318] Done
[103.725838] Removing contigs with coverage < 5.000000...
[103.783422] Concatenation...
[106.090102] Renumbering nodes
[106.090110] Initial node count 101546
[106.093876] Removed 84388 null nodes
[106.093891] Concatenation over!
[106.095519] Concatenation...
[106.098730] Renumbering nodes
[106.098733] Initial node count 17158
[106.098793] Removed 0 null nodes
[106.098794] Concatenation over!
[106.098803] Clipping short tips off graph, drastic
[106.108176] Concatenation...
[106.219506] Renumbering nodes
[106.219513] Initial node count 17158
[106.220663] Removed 1788 null nodes
[106.220666] Concatenation over!
[106.220668] 15370 nodes left
[106.220683] Correcting graph with cutoff 0.200000
[106.220692] Removing low coverage edges from the graph
[106.384640] Concatenation...

[nickschurch]

These are the ENA accession codes for the data that is is failing on, if it help:

ERR459046
ERR459047
ERR459048
ERR459049
ERR459050
ERR459051
ERR459052

These data are combined (they are the same sample run on 7 different lanes on a flow-cell).

Anyone any idea/comments?

[SchulzLab]

Hi,
sorry for my delayed response, but I was traveling the last weeks.

If I understand correctly Oases is able to assemble the dataset with kmer value 19 and 21 and crashes at 23?
Using the -insert_length parameter is redundant because you have single end data.

Also why are you increasing the coverage cutoff to 5 (default 3). Have you benchmarked this and think that you need to remove nodes caused by erroneous reads? In that case I would recommend to error correct the reads first that gives you better results than using a stringent error removal in the assembler. In general that gives you better results than using the original data itself. You can use our SEECER software for RNA-seq error correction. That will be fast for such a small transcriptome.

Hope that helps,
Marcel