vg crashes on centos 8

[gwylym]

When we run the pre-compiled binary on centos 8 the program crashes. As this is not a desktop system and no xvg-utils is readily available, I am reporting here. The following is the stack trace:

Crash report for vg v1.27.0 "Deliceto"
Stack trace (most recent call last):
#10 Object "/scratch/wew/test/vg/vg", at 0x4e11f9, in _start
#9 Object "/scratch/wew/test/vg/vg", at 0x1ca37c8, in __libc_start_main
#8 Object "/scratch/wew/test/vg/vg", at 0x40b167, in main
#7 Object "/scratch/wew/test/vg/vg", at 0xa27d67, in vg::subcommand::Subcommand::operator()(int, char**) const
#6 Object "/scratch/wew/test/vg/vg", at 0xa03040, in main_msga(int, char**)
#5 Object "/scratch/wew/test/vg/vg", at 0xc17371, in vg::VG::path_string[abi:cxx11](vg::Path const&)
#4 Object "/scratch/wew/test/vg/vg", at 0xeda5c5, in vg::mapping_sequence[abi:cxx11](vg::Mapping const&, vg::Node const&)
#3 Object "/scratch/wew/test/vg/vg", at 0x1ca76f1, in __assert_fail
#2 Object "/scratch/wew/test/vg/vg", at 0x1ca767b, in __assert_fail_base
#1 Object "/scratch/wew/test/vg/vg", at 0x1cb40b0, in abort
#0 Object "/scratch/wew/test/vg/vg", at 0x125ee87, in raise

[gwylym]

In a singularity container running ubuntu 18 vg also crashes. Here is the stack trace:
Crash report for vg v1.27.0 "Deliceto"
Stack trace (most recent call last):
#10 Object "/scratch/wew/test/vg/vg", at 0x4e11f9, in _start
#9 Object "/scratch/wew/test/vg/vg", at 0x1ca37c8, in __libc_start_main
#8 Object "/scratch/wew/test/vg/vg", at 0x40b167, in main
#7 Object "/scratch/wew/test/vg/vg", at 0xa27d67, in vg::subcommand::Subcommand::operator()(int, char**) const
#6 Object "/scratch/wew/test/vg/vg", at 0xa03040, in main_msga(int, char**)
#5 Object "/scratch/wew/test/vg/vg", at 0xc17371, in vg::VG::path_string[abi:cxx11](vg::Path const&)
#4 Object "/scratch/wew/test/vg/vg", at 0xeda5c5, in vg::mapping_sequence[abi:cxx11](vg::Mapping const&, vg::Node const&)
#3 Object "/scratch/wew/test/vg/vg", at 0x1ca76f1, in __assert_fail
#2 Object "/scratch/wew/test/vg/vg", at 0x1ca767b, in __assert_fail_base
#1 Object "/scratch/wew/test/vg/vg", at 0x1cb40b0, in abort
#0 Object "/scratch/wew/test/vg/vg", at 0x125ee87, in raise

[adamnovak]

Can you post the message it prints, before referring to the stack trace, about the particular assertion that fails?

And can you post the data and command you are using so we can reproduce the issue?

[gwylym]

The command we used on our centos 8 system was with the output-
export TMPDIR=tmp && /common/contrib/bin/vg msga -f sorted_contigs.fasta -b 207 -t 8 -a -w 128 > contig_graph.vg
vg: src/path.cpp:1695: const string vg::mapping_sequence(const vg::Mapping&, const vg::Node&): Assertion `mp.edit_size()==1' failed.
ERROR: Signal 6 occurred. VG has crashed. Run 'vg bugs --new' to report a bug.
Stack trace path: /tmp/vg_crash_j0LcCb/stacktrace.txt
Please include the stack trace file in your bug report!

The contig_graph.vg file is empty.

Our system is a node on our cluster and does not have a display attached.

[gwylym]

The file we are using is a fasta file and is attached as a zip file.
sorted_contigs.fasta.zip

[adamnovak]

You can ignore vg bugs --new. All it does is link you here.

I suspect we might not be tolerating sufficiently terrible mappings. We're getting hung up here:

vg/src/path.cpp

Lines 1695 to 1696 in b086d01

	assert(mp.edit_size()==1);
	return mp.edit(0).sequence();

We might need to replace that code with code that can handle multiple edits in a Mapping with no real graph position. I'm not sure how we're coming up with those; maybe they happen when the independent chunks are mapped and inserts abut inserts?

I'll see if I can work around the error, but it might not really be producing a good alignment.

Have you thought of using Erik's newer seqwish tool for turning these sequences into a graph? It's a lot smarter than msga.

[gwylym]

I'm a system administrator trying to get software set up for a researcher to use. I will pass on what you had to say. ******************* William Wilson - ITS

…

________________________________ From: Adam Novak <notifications@github.com> Sent: Monday, October 12, 2020 4:20:44 PM To: vgteam/vg Cc: William Edward Wilson; Author Subject: Re: [vgteam/vg] vg crashes on centos 8 (#3012) You can ignore vg bugs --new. All it does is link you here. I suspect we might not be tolerating sufficiently terrible mappings. We're getting hung up here: https://github.com/vgteam/vg/blob/b086d0115250a928a54ebea484cb83ff3d32f42f/src/path.cpp#L1695-L1696<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvgteam%2Fvg%2Fblob%2Fb086d0115250a928a54ebea484cb83ff3d32f42f%2Fsrc%2Fpath.cpp%23L1695-L1696&data=02%7C01%7Cwilliam.wilson%40nau.edu%7Cb3ac1d79919e427af6d008d86f0571a7%7C27d49e9f89e14aa099a3d35b57b2ba03%7C0%7C0%7C637381416455537795&sdata=wgyz0KfkmSkI92V54Vp4a057wdh96DeIyPbIgv9HvsA%3D&reserved=0> We might need to replace that code with code that can handle multiple edits in a Mapping with no real graph position. I'm not sure how we're coming up with those; maybe they happen when the independent chunks are mapped and inserts abut inserts? I'll see if I can work around the error, but it might not really be producing a good alignment. Have you thought of using Erik's newer seqwish tool for turning these sequences into a graph? It's a lot smarter than msga. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvgteam%2Fvg%2Fissues%2F3012%23issuecomment-707392886&data=02%7C01%7Cwilliam.wilson%40nau.edu%7Cb3ac1d79919e427af6d008d86f0571a7%7C27d49e9f89e14aa099a3d35b57b2ba03%7C0%7C0%7C637381416455547790&sdata=D%2Bc5bgxef80GmSEcMqcfjgEdneTbgBngTqL4AMClzkQ%3D&reserved=0>, or unsubscribe<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAG52WC3NQ46QXVC6A26VQADSKOFMZANCNFSM4R547I7A&data=02%7C01%7Cwilliam.wilson%40nau.edu%7Cb3ac1d79919e427af6d008d86f0571a7%7C27d49e9f89e14aa099a3d35b57b2ba03%7C0%7C0%7C637381416455547790&sdata=7YoQfxK0I5EABwqNJmFXDYW2%2FlJrBUnkvMZgsB5aap8%3D&reserved=0>.