| Summary: | Crash when kstars window is not in front when starting | ||
|---|---|---|---|
| Product: | [Applications] kstars | Reporter: | TallFurryMan <eric.dejouhanet> |
| Component: | general | Assignee: | Jasem Mutlaq <mutlaqja> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 2.9.7 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
I've seen this issue occasionally but I don't think it's related to alt-tabbing per se. We're using (or abusing) QtConcurrent in order to speed the start up time. Not sure if you recall earlier version of KStars where it would take anywhere from 10-15 seconds for startup. I think what's happening is that occasionally, some threads finish earlier and start looking for data that does not _yet_ exist. So better control of the concurrency is required at this stage. Agreed. I think alt-tabbing, at least in my dev VM, has an impact on the preparation of the UI frame. I note I enabled HIPS rendering (because it's awesome), so maybe that's a hint. |
Issue is difficult to reproduce, and I don't immediately see the relation with the z-order of the kstars window. But I can reproduce the issue using the following scenario: 1. Start kstars, let the splash screen appear 2. While splash screen is there, alt-tab to another window 3. When objects are being loaded, kstars crash with the following backtrace: Thread 9 "Thread (pooled)" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffc7431700 (LWP 31088)] 0x0000555555c73b6c in QHashNode<QString, SkyObject*>::same_key (this=0x0, h0=2105734952, key0=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qhash.h:158 158 inline bool same_key(uint h0, const Key &key0) const { return h0 == h && key0 == key; } (gdb) bt #0 0x0000555555c73b6c in QHashNode<QString, SkyObject*>::same_key (this=0x0, h0=2105734952, key0=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qhash.h:158 #1 0x0000555555c73875 in QHash<QString, SkyObject*>::findNode (this=0x555558aa9a28, akey=..., h=2105734952) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qhash.h:908 #2 0x0000555555c737d4 in QHash<QString, SkyObject*>::findNode (this=0x555558aa9a28, akey=..., ahp=0x7fffc7430a04) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qhash.h:927 #3 0x0000555555c734c2 in QHash<QString, SkyObject*>::insert (this=0x555558aa9a28, akey=..., avalue=@0x7fffc7430a30: 0x7fffbc03def0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qhash.h:763 #4 0x0000555555c72f43 in ListComponent::appendListObject (this=0x555558aa9a10, object=0x7fffbc03def0) at /home/tallfurryman/dev/kstars/kstars/skycomponents/listcomponent.cpp:55 #5 0x0000555555ca9dc8 in SupernovaeComponent::loadData (this=0x555558aa9a00) at /home/tallfurryman/dev/kstars/kstars/skycomponents/supernovaecomponent.cpp:135 #6 0x0000555555cab159 in QtConcurrent::VoidStoredMemberFunctionPointerCall0<void, SupernovaeComponent>::runFunctor (this=0x555558a8e680) at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:205 #7 0x0000555555834809 in QtConcurrent::RunFunctionTask<void>::run (this=0x555558a8e680) at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentrunbase.h:136 #8 0x00007ffff2216581 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x00007ffff221a29d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x00007ffff14e87fc in start_thread (arg=0x7fffc7431700) at pthread_create.c:465 #11 0x00007ffff0922b0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95