[Nepomuk] Review Request: ResourceManager: Cleanup out all the existing Resources before exit

[Vishesh Handa]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107575/
-----------------------------------------------------------

Review request for Nepomuk, Sebastian Trueg and Simeon Bird.


Description
-------

    ResourceManager: Cleanup out all the existing Resources before exit
    
    Ideally, there should be no ResourceData* in the cache when the
    ResourceManager is being destroyed. However, they can be cases when a
    Resource has been allocated statically and it is destroyed after the
    ResourceManager. In that case, when the Resource is eventually
    destroyed, it will crash as it will try to access the deleted
    ResourceManager.
    
    In order to fix this, we connect to QCoreApplication::aboutToQuit signal
    and set all the Resource::m_data = 0. This results in the Resource class
    not doing anything during its destruction and therefore not crashing. We
    also delete all the ResourceData pointers.
    
    This cleanUpResource() cannot be done in the ResourceManager destructor
    cause ResourceData::resetAll accesses NIE::url() and NAO::identifier(),
    both of which are also static variables and could have been destroyed
    before.
    
    BUG: 292996
    FIXED-IN: 4.10


This addresses bug 292996.
    http://bugs.kde.org/show_bug.cgi?id=292996


Diffs
-----

  libnepomukcore/resource/resource.h de8fee8 
  libnepomukcore/resource/resourcemanager.h 3c26733 
  libnepomukcore/resource/resourcemanager.cpp 457c042 

Diff: http://git.reviewboard.kde.org/r/107575/diff/


Testing
-------

Managed to reproduce the exact crash -


void TestObject::main()
{
    static Nepomuk2::Resource res(QUrl("nepomuk:/res/49c25a0b-17fe-43f2-be67-9d6f6d268cac"));
    res.properties();

    QCoreApplication::instance()->quit();
}

This resource now gets cleared in ResourceManager::cleanupResources


Thanks,

Vishesh Handa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121205/dac477b5/attachment.html>