During robustness tests, I obtained a crash when randomly killing the local indiserver while the Scheduler is running jobs. In that situation, a SIGPIPE fires while writing commands through the server pipe. Thread 1 "kstars" received signal SIGPIPE, Broken pipe. 0x00007ffff14f2cc0 in __libc_write (fd=52, buf=buf@entry=0x7fffffffc9f0, nbytes=31) at ../sysdeps/unix/sysv/linux/write.c:26 26 ../sysdeps/unix/sysv/linux/write.c: No such file or directory. (gdb) bt #0 0x00007ffff14f2cc0 in __libc_write (fd=52, buf=buf@entry=0x7fffffffc9f0, nbytes=31) at ../sysdeps/unix/sysv/linux/write.c:26 #1 0x0000555555f758c3 in INDI::BaseClient::sendString (this=this@entry=0x55555b526290, fmt=fmt@entry=0x5555560fb0dc " device='%s'\n") at /home/tallfurryman/dev/indi/libindi/libs/indibase/baseclient.cpp:1035 #2 0x0000555555f75b14 in INDI::BaseClient::sendNewNumber (this=0x55555b526290, nvp=0x7fffb00488d0) at /home/tallfurryman/dev/indi/libindi/libs/indibase/baseclient.cpp:772 #3 0x0000555555b26c0d in Ekos::Mount::save (this=0x555559b2b150) at /home/tallfurryman/dev/kstars/kstars/ekos/mount/mount.cpp:626 #4 0x0000555555b2826f in Ekos::Mount::setTelescopeInfo (this=0x555559b2b150, primaryFocalLength=0, primaryAperture=0, guideFocalLength=0, guideAperture=0) at /home/tallfurryman/dev/kstars/kstars/ekos/mount/mount.cpp:867 #5 0x00005555559cb2f1 in EkosManager::setTelescope (this=0x555558ec5b30, scopeDevice=0x55555afb51f0) at /home/tallfurryman/dev/kstars/kstars/ekos/ekosmanager.cpp:1130 #6 0x00005555558e36b8 in EkosManager::qt_static_metacall (_o=0x555558ec5b30, _c=QMetaObject::InvokeMetaMethod, _id=22, _a=0x7fffffffd5f0) at /home/tallfurryman/dev/kstars_build/kstars/KStarsLib_autogen/CI6HWGPKSW/moc_ekosmanager.cpp:345 #7 0x00007ffff24268e5 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x00005555558f37ba in INDIListener::newTelescope (this=0x55555938aa70, _t1=0x55555afb51f0) at /home/tallfurryman/dev/kstars_build/kstars/KStarsLib_autogen/FRI4DANIHA/moc_indilistener.cpp:399 #9 0x00005555559698ad in INDIListener::registerProperty (this=0x55555938aa70, prop=0x7fffb0085420) at /home/tallfurryman/dev/kstars/kstars/indi/indilistener.cpp:255 #10 0x00005555558f2dd2 in INDIListener::qt_static_metacall (_o=0x55555938aa70, _c=QMetaObject::InvokeMetaMethod, _id=11, _a=0x7fff50be6320) at /home/tallfurryman/dev/kstars_build/kstars/KStarsLib_autogen/FRI4DANIHA/moc_indilistener.cpp:182 #11 0x00007ffff2427452 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x00007ffff387946c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #13 0x00007ffff3880d34 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #14 0x00007ffff23f7de8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x00007ffff23fa55d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x00007ffff2450e53 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #17 0x00007fffec221fb7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #18 0x00007fffec2221f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #19 0x00007fffec22227c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #20 0x00007ffff245047f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #21 0x00007ffff23f5e3a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #22 0x00007ffff23feda4 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #23 0x000055555563c8df in main (argc=1, argv=0x7fffffffe038) at /home/tallfurryman/dev/kstars/kstars/main.cpp:331
Systematic if killing indiserver while Ekos' indi interface is initializing drivers. Technically, it's not systematic as SIGPIPE may happen while we are not writing or reading, but in practice the interface is doing I/Os most of the time.
Looks like baseclient didn't detect server down fast enough
is this fixed for 3.5.0?