minia seg fault (core dump) after inability to unlink mphf temp files?
Entering edit mode
5.3 years ago
mmelendrez ▴ 10

hey! So I'm unsure of what the following means:

ubuntu@ubuntu-xenial:/vagrant/denovo$ ./minia-v2.0.7-bin-Linux/bin/minia -in minia-v2.0.7-bin-Linux/test_data/P4-P1S_12.fastq -kmer-size 31 -abundance-min 3 -out P4-P1S
[DSK: Collecting stats on P4-P1S_12     ]  100  %   elapsed:   0 min 9  sec    estimated remaining:   0 min 0  sec   cpu:   88.2 %   mem: [  11,   11,   11] MB
[DSK: nb solid kmers found : 1467480    ]  108  %   elapsed:   0 min 47 sec    estimated remaining:   0 min 0  sec   cpu:   86.7 %   mem: [  36,  114,  114] MB
WARNING: Error unlinking temporary file mphf.temp.Xi3OR8
WARNING: Error unlinking temporary file mphf.temp.XQvJoL
Segmentation fault (core dumped)

The output when I ls the dir:

ubuntu@ubuntu-xenial:/vagrant/denovo$ ls

So lots of trashme files, mphf.temp.Xi30R8, mphf.temp.XQvJoL and P4-P1S.h5

UPDATE: I have fiddled with kmer size and converted from fastq to fasta and I get the same error each time.

I'm running on an Ubuntu VM. I'm sure I'm missing something obvious and I searched biostars and didn't find something similar.


minia assembly • 1.5k views
Entering edit mode
5.1 years ago
malaya77 • 0

Did you get it solved yet ? One work around that worked for me earlier was : Copy the fastq file into your virtual box (Desktop or elsewhere, instead of keeping in the shared folder in windows host side). And then run minia command.

It seems like the problem in the unlinking error is because windows does not allow to rename the file. "... the problem is in the way glib saves a file by writing to a temporary file and renaming to the final name. This is don't without closing the file, which is ok on most linux file systems but not on windows." Source


Login before adding your answer.

Traffic: 1063 users visited in the last hour
Help About
Access RSS

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6