vspaero crash in OpenVSP 3.42.3

[richard]

I can compile 3.42.3 in Arch and launch vsp. 

vspaero crashes with the following error:

/usr/include/c++/14.2.1/bits/stl_vector.h:1130: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = double; _Alloc = std::allocator<double>; reference = double&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

Aborted (core dumped)

[Rob McDonald]

Unfortunately, that message is not helpful in diagnosing your problem.

Does this happen for every VSPAERO case -- i.e. have you started with a simple case, or is this a non-trivial case?  Did this case work on prior versions of OpenVSP / VSPAERO?

You might try compiling with -DCMAKE_BUILD_TYPE=RelWithDebugInfo.

This will provide more information in the crash report -- but without making the build intolerably slow.  Building a true Debug OpenVSP results in an executable that is far too slow for anything.

Rob

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openvsp/8c35d1c4-e1f3-47ed-a542-2a675f5a3fecn%40googlegroups.com.

[richard]

Thanks Rob.

I will try a build with that flag tomorrow.

Yes, this crash happens by running VSPAERO on what I assume is the simplest possible case - a simple wing. It did work before.

 

Richard

[Rob McDonald]

It will be interesting to chase down.  Nothing has changed VSPAERO in a long time.

Many changes are coming, but not yet...

Rob

To view this discussion visit https://groups.google.com/d/msgid/openvsp/5b603ea3-e9c2-403d-8f57-f2b61d54adb6n%40googlegroups.com.

[richard]

I did the build with -DCMAKE_BUILD_TYPE=RelWithDebugInfo.

No new information is printed to terminal before vsp crashes. 

I can see that the VSPAERO solver completes, with:

Total setup and solve time: 0.405771 seconds
Done

The next stage gets to here, before crashing:

...

Number of edges is: 522
Note... mesh may not be closed!
CutType: y ... Value: 0.000000

[Rob McDonald]

That next stage is running a second tool to generate the Cp slices.  I suggest you delete all the Cp slices in the GUI and try running again.

Rob

[richard]

I tried deleting all slices, but it is still crashing.

I went back through the versions and the problem begins with version 3.42.1. Version 3.41.1 does not crash.

I actually get one of the two error messages to terminal, below:

error : Unknown IO error: getaddrinfo failed

/usr/include/c++/14.2.1/bits/stl_vector.h:1130: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = double; _Alloc = std::allocator<double>; reference = double&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

 

error : Unknown IO error: getaddrinfo failed

/usr/include/c++/14.2.1/bits/stl_vector.h:1149: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](size_type) const [with _Tp = VspSurf; _Alloc = std::allocator<VspSurf>; const_reference = const VspSurf&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

Aborted (core dumped)

[richard]

Dusan Stan discoverd that Arch-compiled OpenVSP 3.41.1 is also crashing, but only in Panel mode, and with the same error message:

/usr/include/c++/14.2.1/bits/stl_vector.h:1149: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator const [with _Tp = VspSurf; _Alloc = std::allocator; const_reference = const VspSurf&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

The official Debian install of the same version (OpenVSP 3.41.1 Ubuntu 22.04) is apparently not crashing like this. Dusan discovered discrepencies between the file sizes of the Debian and Arch versions. I know that they have been compiled respectively with gcc 10 and gcc 14, but assume this is not problem. Do you have any ideas, Rob...?

 

[Rob McDonald]

No idea.

This error message is not useful at all.  This is reporting a message in the system libraries (stl_vector.h:1149).  Instead, I would need to know something higher up the call stack -- where in OpenVSP's own code does the problem originate.

Even then, the best thing to provide is an actual test case.

Rob

[dusan...@gmail.com]

I suspect this is due to compilation on the arch system. Using the pre-compiled binaries from the .deb official release does not manifest the problem.

Dusan

[richard]

OK, thanks Rob. Do you have any idea what might have caused the disparities in file sizes? Could that have been caused just by the difference in gcc versions, or is there some different in the switches at compilation?

[Rob McDonald]

Those file size differences are pretty modest -- they can easily be caused by changes in gcc (either the compiler or linker), or any of the libraries that are statically linked in.  Most of those are bundled with VSP and would be the same, but they too are being compiled with the different toolchain.

The size difference might be explained by including debug information.  I would have expected a larger difference, but that depends on the platform.

CMake defaults to a debug build.  Unfortunately, debug builds of OpenVSP are far too slow to be useful.  We're talking minutes for a single update of a Wing.

When developing, I usually use a 'Release with Debug Info' build.  This gives the ability to run with a debugger (somewhat imperfectly) while giving nearly release speed.  The official downloads are compiled in Release mode.

If this build defaulted to a true debug build, then it would have additional checks for things like vector limits -- and the bug you're seeing might be a real bug.  However, I would still need a more complete stack trace and a test case to chase it down.

Rob