segv in indi gui
Jasem Mutlaq
mutlaqja at ikarustech.com
Fri Sep 17 07:08:20 BST 2021
That would add quite a bit of overhead in KStars plus it would take a
total rewrite since KStars access BaseDevice and INDI::Property for
many functions.
--
Best Regards,
Jasem Mutlaq
On Fri, Sep 17, 2021 at 12:09 AM Wolfgang Reissenberger
<sterne-jaeger at openfuture.de> wrote:
>
> Let me throw in another idea: what if we leave the device representation under control of the listenINDI() thread and chnange the access from KStars to this model through a facade that accesses devices and properties only by name and not by a reference to the object?
>
> This would have the advantage that we could leave the INDI stuff untouched.
>
> Wolfgang
> —
> Wolfgang Reissenberger
>
> www.sterne-jaeger.de
> TSA-120 + FSQ-85 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro
>
> Am 16.09.2021 um 22:55 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com>:
>
> Hello,
>
> Thank you for writing about this issue. I am actually aware of what is
> happening and discussed this with Hy. One potential solution is to use
> shared_ptr so that if BaseClient deletes a property, it is only freed
> from memory after KStars frees it as well. Another method is strict
> synchronization between the two threads, and one method we used before
> was QueuedBlockingConnection that would block the calling thread until
> the receiving thread finishes processing. This led to deadlocks on
> some occasions so it is now only used sparingly in the code where it
> is absolutely necessary.
>
> --
> Best Regards,
> Jasem Mutlaq
>
>
> On Thu, Sep 16, 2021 at 11:42 PM Wolfgang Reissenberger
> <sterne-jaeger at openfuture.de> wrote:
>
>
> Hi all,
> I have developed a theory meanwhile why we have these crashes on disconnecting that I would like to discuss with you.
>
> I think the problem is, that the representation of devices (INDI::Telescope, …) and properties (INDI::Properties) are used in a multithreaded manner in KStars, but do not provide thread safety on their own.
>
> For each device, there are two threads that might come into conflict:
> 1. The KStars main thread accessing and modifying device properties (in fact I think it could even be more of them)
> 2. BaseClientPrivate::listenINDI() that has a socket connection to the INDI server and communicates with the device driver inside the INDI server.
>
> Both can modify the same data object in parallel. It could for example happen, that listenINDI() receives „removeProperty“ commands and removes properties in parallel to the KStars main thread that retrieves a Property object that is just in progress to be deleted.
>
> As long as deleting the property comes before or after the KStars access, everything is fine. The problem is that the sequence is the following:
> 1. KStars main thread obtains a property object
> 2. listenINDI() receives a removeProperty command and deletes it
> 3. KStars wants to read data from the property object and experiences a SEGV exception, since the object does not exist any more.
>
> To resolve this, I think two or three of us should stick their heads together and discuss how this can be resolved.
>
> Does that make sense?
>
> Cheers
> Wolfgang
>
> —
> Wolfgang Reissenberger
>
> www.sterne-jaeger.de
> TSA-120 + FSQ-85 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro
>
> Am 10.09.2021 um 13:22 schrieb Wolfgang Reissenberger <sterne-jaeger at openfuture.de>:
>
> Just one thought, but I have to admit I do not really understand the INDI client manager.
>
> Since there are several threads requesting things from the client manager - could it be that not all threads are aware of a disconnect and consequently try to access elements or properties, that have already been destroyed? I have for example the thread in mind of EKOS that regularly requests the current mount position, but it may be others as well...
>
> Am 10.09.2021 um 03:44 schrieb Hy Murveit <murveit at gmail.com>:
>
> Jasem,
> FWIW, I was able to get it to crash several times by connecting/disconnecting.
> Ping me if you want to video
> Hy
>
> On Thu, Sep 9, 2021 at 6:32 PM Hy Murveit <murveit at gmail.com> wrote:
>
>
> Using the latest HEAD, 2e36eb8322d8f8490c0419f64f86e1152127fb94 including "check for nullptr..." I got this segv
> by starting ekos, and disconnecting right away (repeated 3 times), on my RPi4 running ubuntu 21.04.
>
> Hy
>
> (gdb) bt
> #0 0x0000aaaaab4a1508 in INDI::BaseDevice::getDeviceName() const ()
> #1 0x0000aaaaaae795fc in operator() (__closure=0xffffb40bef30)
> at /home/hy/Projects/kstars/kstars/indi/clientmanager.cpp:111
> #2 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, ClientManager::newProperty(INDI::Property*)::<lambda()> >::call (arg=<optimized out>, f=...)
> at /usr/include/aarch64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:146
> #3 QtPrivate::Functor<ClientManager::newProperty(INDI::Property*)::<lambda()>, 0>::call<QtPrivate::List<>, void> (arg=<optimized out>, f=...)
> at /usr/include/aarch64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:256
> #4 QtPrivate::QFunctorSlotObject<ClientManager::newProperty(INDI::Property*)::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *)
> (which=1, this_=0xffffb40bef20, r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/aarch64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:443
> #5 0x0000fffff52ef6d4 in QObject::event(QEvent*) ()
> at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #6 0x0000fffff5d369b0 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
> at /lib/aarch64-linux-gnu/libQt5Widgets.so.5
> #7 0x0000fffff52bdb60 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
> at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #8 0x0000fffff52c0f48 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #9 0x0000fffff531e9e8 in () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #10 0x0000fffff4257578 in g_main_context_dispatch ()
> at /lib/aarch64-linux-gnu/libglib-2.0.so.0
> #11 0x0000fffff42ad188 in () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
> #12 0x0000fffff4254ac4 in g_main_context_iteration ()
> at /lib/aarch64-linux-gnu/libglib-2.0.so.0
> #13 0x0000fffff531de94 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #14 0x0000fffff52bc04c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
> at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #15 0x0000fffff52c514c in QCoreApplication::exec() ()
> at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #16 0x0000aaaaaab927cc in main(int, char**) (argc=<optimized out>, argv=<optimized out>)
> at /home/hy/Projects/kstars/kstars/main.cpp:393
> (gdb)
>
>
>
> On Thu, Sep 9, 2021 at 10:48 AM Hy Murveit <murveit at gmail.com> wrote:
>
>
> I just got another segv, and it happened when I clicked "Disconnect" trying to disconnect indi.
> Here's the backtrace:
>
> (gdb) bt
> #0 0x0000aaaaaae8af88 in INDI_E::syncSwitch() (this=0xaaaab3f2ebc0) at /home/hy/Projects/kstars/kstars/indi/indielement.cpp:209
> #1 0x0000aaaaaae84968 in INDI_D::updateSwitchGUI(_ISwitchVectorProperty*) (this=<optimized out>, svp=<optimized out>)
> at /home/hy/Projects/kstars/kstars/indi/indidevice.cpp:188
> #2 0x0000fffff52ef6d4 in QObject::event(QEvent*) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #3 0x0000fffff5d369b0 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib/aarch64-linux-gnu/libQt5Widgets.so.5
> #4 0x0000fffff52bdb60 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #5 0x0000fffff52c0f48 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
> at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #6 0x0000fffff531e9e8 in () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #7 0x0000fffff4257578 in g_main_context_dispatch () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
> #8 0x0000fffff42ad188 in () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
> #9 0x0000fffff4254ac4 in g_main_context_iteration () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
> #10 0x0000fffff531de94 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
> at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #11 0x0000fffff52bc04c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #12 0x0000fffff52c514c in QCoreApplication::exec() () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #13 0x0000aaaaaab927cc in main(int, char**) (argc=<optimized out>, argv=<optimized out>)
> at /home/hy/Projects/kstars/kstars/main.cpp:393
> (gdb)
>
> I was running from HEAD through and including "use modern connect" a100fa1664e028460a348303365caf983e06eda3
>
> Hy
>
>
> On Mon, Sep 6, 2021 at 10:45 PM Jasem Mutlaq <mutlaqja at ikarustech.com> wrote:
>
>
> Hello Hy,
>
> I think I submitted a refactor of the INDI Control Panel in KStars
> that should fix such crash-on-disconnection issues. This commit has
> the fix: 678c5e360c7651060c65133ed97b074c0b24bc40
>
> However, we must thoroughly test KStars now for stability issues.
> Robert reported crashes on the MacOS client with INDI, so this needs
> to be investigated. The due date for 3.5.5 was planned for September
> 6th (Yesterday) but I really think we should delay perhaps for a few
> days until we ensure stability issues are addressed. Hopefully more
> users would try the beta to report back. Keep using KStars with *real*
> equipment under real conditions to catch some of these elusive bugs.
>
> --
> Best Regards,
> Jasem Mutlaq
>
> On Tue, Sep 7, 2021 at 1:19 AM Hy Murveit <murveit at gmail.com> wrote:
>
>
> Thread 1 "kstars" received signal SIGSEGV, Segmentation fault.
>
> 0x0000aaaaaae88bb8 in INDI_E::syncSwitch (this=0xaaaab0179940)
> at /home/hy/Projects/kstars/kstars/indi/indielement.cpp:225
> 225 if (sp->svp->p == IP_RO)
> (gdb)
> (gdb) bt
> #0 0x0000aaaaaae88bb8 in INDI_E::syncSwitch() (this=0xaaaab0179940)
> at /home/hy/Projects/kstars/kstars/indi/indielement.cpp:225
> #1 0x0000aaaaaae82448 in INDI_D::updateSwitchGUI(_ISwitchVectorProperty*)
> (this=<optimized out>, svp=<optimized out>)
> at /home/hy/Projects/kstars/kstars/indi/indidevice.cpp:186
> #2 0x0000fffff52ef6d4 in QObject::event(QEvent*) ()
> at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #3 0x0000fffff5d369b0 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
> () at /lib/aarch64-linux-gnu/libQt5Widgets.so.5
> #4 0x0000fffff52bdb60 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
> () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #5 0x0000fffff52c0f48 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #6 0x0000fffff531e9e8 in () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #7 0x0000fffff4257578 in g_main_context_dispatch ()
> at /lib/aarch64-linux-gnu/libglib-2.0.so.0
> #8 0x0000fffff42ad188 in () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
> #9 0x0000fffff4254ac4 in g_main_context_iteration ()
> at /lib/aarch64-linux-gnu/libglib-2.0.so.0
> #10 0x0000fffff531de94 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #11 0x0000fffff52bc04c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #12 0x0000fffff52c514c in QCoreApplication::exec() ()
> at /lib/aarch64-linux-gnu/libQt5Core.so.5
> #13 0x0000aaaaaab917cc in main(int, char**)
> (argc=<optimized out>, argv=<optimized out>)
> at /home/hy/Projects/kstars/kstars/main.cpp:39
>
>
>
>
>
>
More information about the Kstars-devel
mailing list