[Kstars-devel] Observations Regarding Bug 345348: Crash upon adding objects to the observing list after adding a new custom catalog

[Akarsh Simha]

Hello

This is a post with a two-fold purpose: one is to document some
observations regarding bug 345348
(https://bugs.kde.org/show_bug.cgi?id=345348), and second to ask for
opinions on what might be the best way to fix it -- because the
solution is not straightforward.

This is the bug that I hate the most. It fractures my astronomy
sessions every time it crops up. I have to "start over". Well, it's
not too bad because I keep backups of my wishlist and observing lists.
But it still bothers me. So I really want to fix it.

### Correct way to reproduce the bug (I think...)

I think the instructions I provided to reproduce the bug were
incorrect, and applied to the specific configuration of my observing
wish list at that time. I could not reproduce it as described in the
report today. However, I could reproduce it as follows:
1. Enable a custom catalog in KStars
2. Add an object from that custom catalog into your wish list.
3. Enable another custom catalog in KStars
4. Add an object from the new catalog (or any other custom catalog) to
the wish list
5. KStars Crashes.

### Posssible reason for the crash:

Some investigation showed that the reason for this bug might be this:
1. ObservingList stores _pointers_ to SkyObjects in the wishlist in
memory. The wishlist file on the disk contains names of objects
(obviously). However, the program loads this and maps it into a list
of SkyObject *. So the wish list is held in memory as a list of
SkyObject *, and is written back to the disk by calling objectName()
on each of these SkyObject pointers ( see
ObservingList::slotSaveList(); the line that says, for example,
ostream << o->name() << endl; )
2. Upon changing the configuration of custom catalogs, the
OpsCatalog::slotApply() calls SkyMapComposite::reloadDeepSky(), which
deletes the old m_CustomCatalogs and creates a new one. This causes
_all_ custom catalog data to be reloaded, resulting in the pointers
that were present in the observing wishlist
(ObservingList::m_WishList) to be dangling.

This, IMO, is the (most likely) reason for the crash.

### Proposed Solution:

The solution I propose is that the observing wish list / observing
session plan etc should really hold names of the objects. Even better,
it should hold objects of a new class called ObservingListTarget. Each
ObservingListTarget must primarily be identified by an (untranslated /
official) identifier / name of the object. When available, additional
information about the object must be obtained by finding the
appropriate SkyObject through findByName(). Should we choose to
associate a pointer to a SkyObject * with these, it should be a
QSharedPointer or something nice of that sort, so we know whether it
is valid or not. The other, possibly simpler option, is that we store
simple pointers to SkyObject *, and "purge" them every time
reloadDeepSky() is called. This is not elegant and "safe", but it
might be more efficient memory-wise and time-wise. This way, a valid
observing list entry need not have a valid SkyObject associated with
it -- which is good, because we can import OAL-format lists that have
objects that KStars knows nothing about. A future tool can then query
the "Sesame" resolver of the CDS / U. Strasbourg to find out
information about the object and create an interim SkyObject for it /
add it to the DB.

Regards
Akarsh