I just wanted to try the latest kstars on my mount computer, but it got a segfault during startup
Weird thing is, on the laptop it runs fine. This is identical software installations (Tumbleweed 20201203), self compiled binaries from git. The major difference is, the mount computer is a Celeron with only 4GB RAM. So I wonder whether this can be the issue?
Some background: kstars-3.5.0-1707_g8f1d90fdf does start fine. With two newer ones (3.5.1-1765_gd15e198bd and 3.5.1-1767_g2b859c1b7) it crashes on start.
I ran it in gdb (though the mount computer doesn't have sources/devel setup).
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Thread 1 "kstars" received signal SIGABRT, Aborted.
0x00007ffff43c4a65 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff43c4a65 in raise () from /lib64/libc.so.6
#1 0x00007ffff43ad864 in abort () from /lib64/libc.so.6
#2 0x00007ffff47598b6 in ?? () from /usr/lib64/libstdc++.so.6
#3 0x00007ffff47651bc in ?? () from /usr/lib64/libstdc++.so.6
#4 0x00007ffff4765227 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5 0x00007ffff476552d in __cxa_rethrow () from /usr/lib64/libstdc++.so.6
#6 0x00007ffff6a39513 in QVector<float>::realloc (
this=this@entry=0x7fffffffd4c0, aalloc=<optimized out>, options=...,
options@entry=...) at /usr/include/qt5/QtCore/qvector.h:744
#7 0x00007ffff6a5a89f in QVector<float>::detach (this=0x7fffffffd4c0)
at /usr/include/qt5/QtCore/qvector.h:411
#8 QVector<float>::detach (this=0x7fffffffd4c0)
at /usr/include/qt5/QtCore/qvector.h:403
#9 QVector<float>::end (this=0x7fffffffd4c0)
at /usr/include/qt5/QtCore/qvector.h:214
#10 QVector<float>::clear (this=0x7fffffffd4c0)
at /usr/include/qt5/QtCore/qvector.h:450
#11 QVector<float>::clear (this=0x7fffffffd4c0)
at /usr/include/qt5/QtCore/qvector.h:446
#12 StellarSolver::createConvFilterFromFWHM (params=0x7fffffffd450, fwhm=2)
at /home/pit/Sources/stellarsolver/stellarsolver/stellarsolver.cpp:541
#13 0x00005555559b894c in Ekos::getDefaultHFROptionsProfiles ()
at /usr/src/packages/BUILD/kstars/kstars/ekos/auxiliary/stellarsolverprofile.cpp:208
#14 0x00005555559324d0 in OpsFITS::loadStellarSolverProfiles (
this=0x555558c304e0)
at /usr/src/packages/BUILD/kstars/kstars/fitsviewer/opsfits.cpp:68
#15 0x00005555559326eb in OpsFITS::setupHFROptions (this=0x555558c304e0)
at /usr/src/packages/BUILD/kstars/kstars/fitsviewer/opsfits.cpp:98
#16 0x00005555559329bd in OpsFITS::OpsFITS (this=0x555558c304e0)
at /usr/src/packages/BUILD/kstars/kstars/fitsviewer/opsfits.cpp:52
#17 0x000055555570d57d in KStars::prepareOps (this=this@entry=0x555556497950)
at /usr/src/packages/BUILD/kstars/kstars/kstarsactions.cpp:1065
#18 0x000055555571ca08 in KStars::initActions (this=0x555556497950)
at /usr/src/packages/BUILD/kstars/kstars/kstarsinit.cpp:391
#19 0x0000555555721dd7 in KStars::buildGUI (this=0x555556497950)
at /usr/src/packages/BUILD/kstars/kstars/kstarsinit.cpp:948
#20 0x0000555555721f9b in KStars::datainitFinished (
this=this@entry=0x555556497950)
at /usr/src/packages/BUILD/kstars/kstars/kstarsinit.cpp:783
#21 0x0000555555724dff in KStars::KStars (this=0x555556497950,
doSplash=<optimized out>, clockrun=<optimized out>, startdate=...,
__in_chrg=<optimized out>, __vtt_parm=<optimized out>)
at /usr/src/packages/BUILD/kstars/kstars/kstars.cpp:249
#22 0x0000555555725680 in KStars::createInstance (
doSplash=doSplash@entry=true, clockrun=<optimized out>, startdate=...)
at /usr/src/packages/BUILD/kstars/kstars/kstars.cpp:262
#23 0x00005555556abce0 in main (argc=<optimized out>, argv=<optimized out>)
at /usr/src/packages/BUILD/kstars/kstars/main.cpp:332
Looks like #12 is the last kstars related routine. Is that one trying to get larger amounts of memory, like for index files?
But stellarsolver is the same library for all three versions, so it would rather be the profiles (#13).
Or any other suggestions what to look for?