Fixes for memory leaks and QObject* ownership bugs

[412b]

Due to returning QObject* in calls to C++ objects from QML (e.g.
getItem(i)), those objects were changing ownership to QML and were
subject to gc. That could've been noticed during switching between
journey results and journey details results (instantly switch back and
forth to create enough garbage).
var item = result.getItem(i);
item would be null after some time. So it was ending up in page
showing loader and not doing anything or in a bit more rare cases with
segfault.

[smurfy]

Ah, my guess is, this also auto installs the position lib in emulator.
Only worry is, that this also get catched by harbour store validator :) (as far as i know using gps is still against the harbour rules)

If you have any insights on this, or should we wait and see? :D

[leppa]

How is this change relevant to QObject ownership change at all?

[smurfy]

Nope

[412b]

that change got there by mistake mostly, but w/o it you can not run it in emu w/o manually installing packages. it can also affect users, which have no positioning dependant apps installed (if that is possible at all :))
that said, that change can be undone.

[412b]

btw, QtPositioning is now allowed in Harbour (since 6th of May)
https://together.jolla.com/question/11446/support-for-qtpositioning-qtlocation-apis/?answer=87430#post-id-87430

[leppa]

It looks like we were leaking memory after each search before, and will be leaking even more with this change. At the end everything gets parented to lastJourneyResultList, however, we never delete it - we just assign NULL. I think that adding delete lastJourneyResultList before calling lastJourneyResultList = NULL should be enough, but it might make sense to do some memory profiling.

[412b]

This changes wasn't intented to fix memory leaks in c++ part of the app.
calling delete will help only with a proper destructor in place and that one is missing at the moment.
i can push the needed changes from my other branch.

[leppa]

Not completely true. QObject deletes all its children when it's deleted, and you do parent all JourneyResultItem instances to lastJourneyResultList and all JourneyDetailResultItem instances to corresponding JourneyResultItem instances. So, deleting lastJourneyResultList would delete all of them.

[412b]

I was talking about a generic way.
As long as setting parent is properly done it is ok in this particular case.
As far as I remember, when you're building classes' hierarchy (like QObject -> Class A -> Class B), then for the children of type B to be deleted you need to have a virtual destructor in A.

[leppa]

Not sure. All of the classes in the created object tree inherit from QObject. As they don't have a destructor, QObject's destructor (which is virtual) will be called for all of them, and it will delete all it's children.

A more proper solution would, of course, be destructors that call qDeleteAll() on JourneyResultList::m_items and JourneyDetailResultList::m_items.

I was referring to this particular case and your change. The one-liner I suggest would already prevent quite a big leak. I'm pretty sure that there are other places where we leak memory and they need to be investigated, too.

[412b]

@smurfy seems like at this point I better stop :) I've done more or less basic checks, no segfaults during that period. though there is plenty of things to improve, for this pr there are too many commmits already.

[412b]

there is a regression in hafas parser, which I will adress in next commit.

[412b]

seems to be it for this PR :)

[balcy]

this is PR is definately needed for Ubuntu touch, without it the app crashes if you switch between the connections overview and the connections details for a few times.