memory allocation error in 0.1.5b

[mjhubisz]

I've been trying to figure out why a cactus run has been crashing, and have found it happens during a gfaffix step. It turns out that this step fails when using gfaffix v0.1.5b, but not v0.1.5. A reproducible example is below, though I apologize that the input file is quite large (5.5Gb uncompressed). I don't know enough about this program to make a smaller example. However, it only takes a few minutes to crash. Although the message says "memory allocation error", there is plenty of memory remaining, and I get the same behavior on both a 512Gb and 1Tb RAM server. The actual RAM usage seems to stay well under 100Gb.

wget ftp://cbsuftp.biohpc.cornell.edu/melissa/test.vg.gfa.gz
gunzip test.vg.gfa.gz
gfaffix test.vg.gfa --output_refined out.gfa

with gfaffix v0.1.5b, this outputs:

memory allocation of 560 bytes failed
Aborted (core dumped)

But with v0.1.5, it appears to run smoothly.

[danydoerr]

Thanks Melissa, I'll have a look at the issue.

[danydoerr]

@mjhubisz The issue is not a programming bug in gfaffix, but probably caused by the rust compiler or libraries that it uses. Specifically, it is located in the target for compiling static binaries and therefore the memory leak only occurs in the linux binary that is provided with the release (@glennhickey!), but if you compile gfaffix yourself, or use conda (mamba install gfaffix=0.1.5b), things should run smoothly.

The issue is also independent of the code changes in 0.1.5b w.r.t. 0.1.5. So, I'm wondering whether someone else can reproduce this bug.

@mjhubisz, you you happen to have rust installed and are you able to generate a static binary that I may test? The commands are as follows:

rustup target add x86_64-unknown-linux-musl
cargo build --target=x86_64-unknown-linux-musl --release

[glennhickey]

@danydoerr Can you please build the GFAffix release binary with

cargo build --target=x86_64-unknown-linux-gnu --release

instead? I'm not a Rust expert but this is what I always use for static builds and have never had issues. It also seems to solve the present problem. See

wget http://public.gi.ucsc.edu/~hickey/debug/gfaffix

which works on the given data (where I reproduce the error when building on the same system with musl).

[glennhickey]

(I also had RUSTFLAGS='-C target-feature=+crt-static' to get the static binary in my link)

[danydoerr]

Thanks, @glennhickey, that's fantastic! I just downloaded your binary and confirm it's working. I'll upload it to replace the currently released binary.

[danydoerr]

updated binary is now available at https://github.com/marschall-lab/GFAffix/releases/tag/0.1.5b