Avogadro crashes when deleting a molecule & infinite loading on ORCA output file

Marco · February 18, 2025, 6:13pm

Hi,
With the latest version of Avogadro I encountered two issues:

The application crashes when I try to delete an atom/molecule. Below is the user log:

--Feb 18 18:49:16 T480 org.openchemistry.Avogadro2.desktop[4297]: Avogadroapp version:  1.100.0
Feb 18 18:49:16 T480 org.openchemistry.Avogadro2.desktop[4297]: Avogadrolibs version:  1.100.0
Feb 18 18:49:16 T480 org.openchemistry.Avogadro2.desktop[4297]: Qt version:  6.8.2
Feb 18 18:49:16 T480 org.openchemistry.Avogadro2.desktop[4297]: qt.core.qobject.connect: QObject::connect(QObject, Unknown): invalid nullptr parameter
Feb 18 18:49:16 T480 org.openchemistry.Avogadro2.desktop[4297]: SSL version:  "OpenSSL 3.3.2 3 Sep 2024"
Feb 18 18:49:16 T480 org.openchemistry.Avogadro2.desktop[4297]: Using locale:  "en_GB"
Feb 18 18:49:16 T480 org.openchemistry.Avogadro2.desktop[4297]: AvogadroApp Translation  "en_GB"  loaded  "/app/bin/../share/avogadro2/i18n/"
Feb 18 18:49:16 T480 org.openchemistry.Avogadro2.desktop[4297]: AvogadroLibs Translation  "en_GB"  loaded  "/app/bin/../share/avogadro2/i18n/"
Feb 18 18:49:17 T480 org.openchemistry.Avogadro2.desktop[4297]:  registering obmm plugins
Feb 18 18:49:17 T480 org.openchemistry.Avogadro2.desktop[4297]: "/app/bin/obabel"  found:  "/app/bin/obabel: Open Babel 3.1.1 -- Feb  9 2025 -- 20:02:29"
Feb 18 18:49:23 T480 org.openchemistry.Avogadro2.desktop[4297]: Open Babel formats ready:  144
Feb 18 18:49:23 T480 org.openchemistry.Avogadro2.desktop[4297]: Setting default format to cjson.
Feb 18 18:49:29 T480 org.openchemistry.Avogadro2.desktop[4297]: /usr/include/c++/14.2.0/bits/stl_vector.h:1130: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = std::pair<long unsigned int, long unsigned int>; _Alloc = std::allocator<std::pair<long unsigned int, long unsigned int> >; reference = std::pair<long unsigned int, long unsigned int>&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
--

When loading an ORCA output file, the application gets stuck and keeps loading indefinitely while trying to read the molecular orbitals.

Environment Information

Avogadro version: 1.100 beta flatpak
Operating system and version: Fedora 41

Please let me know if you need additional details, and thank you for your time and support.

matterhorn103 · February 18, 2025, 8:21pm

Hi!

For (2) the most useful thing would be to upload the file in question.

I can confirm (1), it also happens for me with the Flatpak.

From a bit of googling, it seems like a few projects have suffered from similar with their Flatpaks (example) and that it has to do with the Flathub builds turning on some extra compiler checks.

This seems to be the configuration that Flathub use when building (this was all on one line, I’ve broken it into one argument per line to make it easier to read):

flatpak
build
--die-with-parent
--env=FLATPAK_BUILDER_BUILDDIR=/run/build/avogadro2
--nofilesystem=host:reset
--filesystem=/srv/buildbot/worker/build-x86_64-2/build/.flatpak-builder/build/avogadro2-1
--bind-mount=/run/build/avogadro2=/srv/buildbot/worker/build-x86_64-2/build/.flatpak-builder/build/avogadro2-1
--build-dir=/run/build/avogadro2/_flatpak_build
--bind-mount=/run/ccache=/srv/buildbot/worker/build-x86_64-2/build/.flatpak-builder/ccache
--unshare=network
--env=SOURCE_DATE_EPOCH=1739123112
'--env=CFLAGS=-O2 -pipe -g -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer'
'--env=CXXFLAGS=-O2 -pipe -g -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer'
'--env=LDFLAGS=-L/app/lib -Wl,-z,relro,-z,now -Wl,--as-needed'
--env=CCACHE_DIR=/run/ccache/disabled
--env=PATH=/app/bin:/usr/bin
--env=LD_LIBRARY_PATH=/app/lib
--env=PKG_CONFIG_PATH=/app/lib/pkgconfig:/app/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
--env=FLATPAK_BUILDER_N_JOBS=64 /srv/buildbot/worker/build-x86_64-2/build/.flatpak-builder/rofiles/rofiles-DGmymU ninja -j64 -l128

From what I’ve read it sounds like it’s -D_GLIBCXX_ASSERTIONS being turned on that causes the extra strictness.

ghutchis · February 18, 2025, 8:22pm

For both, it would help to have more details. In particular, if you can share the Orca output file (or post a link) that helps with debugging.

As for the crash when delete, it would greatly help to know what sequence you did. We test pretty thoroughly, and I don’t know where that crash would occur.

ghutchis · February 18, 2025, 8:22pm

Well, we can certainly turn that on for the Ubuntu unit test runs.

matterhorn103 · February 18, 2025, 8:32pm

For me at least it’s literally a case of launch Avogadro, click to draw methane, right-click the carbon atom to delete, immediate crash.

Marco · February 18, 2025, 9:07pm

For the crash when deleting, it’s the same case that @matterhorn103 has described, sorry if I wasn’t precise in describing the problem.
For the orca output, it’s too big for direct upload, I have to find a way to safely share it

ghutchis · February 18, 2025, 9:40pm

Can you get that in gdb for a backtrace? I’ll certainly switch some things to enable assertions on Linux for testing, but I probably can’t get to it for a day or two.

Marco · February 18, 2025, 11:20pm

@ghutchis @matterhorn103 I wasn’t able to upload the original file, but I was able to replicate the problem on another system. Here is the output:
cyclobutadiene_triplet.out (465.6 KB)
I have tested this file on the beta Flatpak version and the latest Windows nightly build via Wine, and both versions have the same infinite loading problem.

matterhorn103 · February 19, 2025, 12:39am

Don’t seem to be able to get a backtrace from it, I’m afraid, and when run under gdb there’s very little extra info other than

/usr/include/c++/14.2.0/bits/stl_vector.h:1130: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = std::pair<long unsigned int, long unsigned int>; _Alloc = std::allocator<std::pair<long unsigned int, long unsigned int> >; reference = std::pair<long unsigned int, long unsigned int>&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
[Inferior 1 (process 82850) exited with code 0206]

I’ll try following the Flatpak debugging guide and see if that gets us anywhere.

matterhorn103 · February 19, 2025, 3:25am

Ok here we go. For a start the error is more verbose, though I don’t know to what extent it’s useful:

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

Thread 1 "avogadro2" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
    at pthread_kill.c:44
44            return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;

And here’s the backtrace:
bt.txt (59.8 KB)