Assertions in rod_structure.cpp can cause simulations to abort

[Jarvellis Rogers]

NOTE: This bug was originally reported as “Assertions in rod_structure.cpp can cause clashes with external software”. This is a byproduct of a bigger issue around pathing, but I have put the original description for this below under “Original Description” as it is still relevant and affected by different assertions.

---

The use of assert() in src/rod_structure.cpp can cause some issues when running FFEA rod simulations. For example, a valid FFEA script for a rod simulation run from the containing directory like so will run fine:

$ ffea rod_sim.ffea

However, running a rod simulation by calling a partial or full path like so will cause assertions to fail:

$ ffea /path/to/same/rod_sim.ffea

The error produced will appear such as the following one for the assertion on line 518:

ffea: /home/sccdrADM/softw/ffea/master/ffea/src/rod_structure.cpp:518: rod::Rod rod::Rod::load_header(std::__cxx11::string): Assertion `line == "format,ffea_rod"' failed.
Aborted (core dumped)

The assertions that cause this issue are on the lines 518, 537, and 610. However, commenting out these lines is not viable as FFEA rod simulations will now terminate with the following error:

Serious warning: The rod input was generated by a different version of the software to the one you are using.
Rod file version: 999.999, software version: 0.3.
Rod file at ndc_rod.rodtrajwas not found.
Rod version: 999.999. Length = 0
[rod] Last frame: line 166
terminate called after throwing an instance of 'std::invalid_argument'
what(): stof
Aborted (core dumped)

Another issue caused by running FFEA rod simulations through a path is that the .rod and .rodtraj files can sometimes be copied to whatever directory the FFEA command was called from. It may possibly be related to this issue.

---

Original Description

This bug was discovered when trying to use Valgrind (https://www.valgrind.org/) on FFEA as it was simulating rods. FFEA scripts that contained rods, which would run normally, would not run when attempting to profile with any Valgrind tool, such as with the example command:

$ valgrind --leak-check=full --track-origins=yes --verbose --tool=memcheck --log-file="memcheck.log" ffea "/path/to/rod-based/ffea/script/"

This is due to the use of assert() in src/rod_structure.cpp on lines 537, 610, and 627. Respectively, they cause the following errors:

ffea: /home/sccdrADM/softw/ffea/master_edit/ffea/src/rod_structure.cpp:537: rod::Rod rod::Rod::load_header(std::__cxx11::string): Assertion `length_set == true && "Length of the rod has not been set."' failed.
Aborted (core dumped)

ffea: /home/sccdrADM/softw/ffea/master_edit/ffea/src/rod_structure.cpp:610: rod::Rod rod::Rod::load_contents(std::__cxx11::string): Assertion `line_start != 0 && "Rod header\rod file not found."' failed.
Aborted (core dumped)

ffea: /home/sccdrADM/softw/ffea/master_edit/ffea/src/rod_structure.cpp:627: rod::Rod rod::Rod::load_contents(std::__cxx11::string): Assertion `line_of_last_frame != 0' failed.
Aborted (core dumped)

Commenting out these lines stops this bug from occurring and allows the simulation to run with Valgrind, but this may have follow-on effects and may invalidate profiling.

It has been suggested that a more suitable form of check would be to do so with if statements instead of assert(), and that they should produce a more detailed error message.

[Jarvellis Rogers]

I have tried changing the asserts to if statements; for example:

//assert(line_of_last_frame != 0); //commented out due to bug
if (line_of_last_frame == 0) {
    printf("ERROR: Last frame not found. Shutting down.");
    exit(EXIT_FAILURE);
}

This does not solve the problem, and they still trip the same way, so the format of the assertion does not seem to be what is causing the problem.

Going to try and take a look at the code that deals with the filepath to see if I can spot a problem there next week.

Edit: Turns out there was a mistake in the new if statements. Asserts contained some strings that I thought were part of the condition but were in fact the error message because C++ macros forgot to be readable. Will fix on tuesday.

[Jarvellis Rogers]

I have fixed the if statements so they are equivalent to the assert() functions now, and the problem is not resolved. I think the use of assert is actually fine. There are error messages for some of them in actuality, that is the intention of the && "some string" part of it, such as in line 537:

assert(length_set == true && "Length of the rod has not been set.");

I would suggest leaving them mostly alone, but maybe add a few more error messages.

This does mean there is something else wrong which is causing file path problems. Having looked at the code, I’m failing to see what the problem is. I do know it is definitely nothing to do with spaces in filepaths, because I have tried ensuring the files are on a path with no spaces or non-alphanumeric characters and it still fails.

So, unfortunately for now, I don’t know how to fix this issue.