Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--fastx_uniques: still reachable memory under certain conditions (minor issue) #567

Open
frederic-mahe opened this issue Jul 8, 2024 · 1 comment
Assignees

Comments

@frederic-mahe
Copy link
Collaborator

When using vsearch with either fastq-output (--fastqout) or tabulated-output (--tabbedout), valgrind reports that there are 47,088 bytes in 17 blocks still in use at exit. Other dereplication command are not affected.

Code to reproduce the issue:

TMP=$(mktemp)
valgrind \
    --log-file="${TMP}" \
    --leak-check=full \
    --show-leak-kinds=all \
    vsearch \
    --fastx_uniques <(printf ">s1\nA\n>s2\nA\n") \
    --uc /dev/null \
    --tabbedout /dev/null \
    --fastqout /dev/null \
    --fastaout /dev/null 2> /dev/null
cat "${TMP}"
rm -f "${TMP}"
unset TMP
@torognes torognes self-assigned this Aug 6, 2024
@torognes
Copy link
Owner

torognes commented Aug 6, 2024

FASTQ and tabulated output is only available with fastq_uniques when the input is in FASTQ format (not FASTA). VSEARCH therefore terminates with a fatal error message in these cases (written to stderr). I do not think it is necessary to clean up memory in these cases.

With FASTQ input (e.g. "@s1\nA\n+\nI\n@s2\nA\n+\nI\n") all memory is freed as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants