Review Request 118238: Get the top-level context associated with a QML module

[Denis Steckelmacher]

> On May 22, 2014, 11:34 a.m., Sven Brauch wrote:
> > I don't have an immediate idea, but can you try to set a breakpoint to where this message is printed? The backtrace from there should tell you what deletes the context. It feels like a bug in the JSON tests.
> > 
> > Also, can you put the whole (although non-working) patch here? ;)
> > 
> > Greetings!

Here is the backtrace of where KDevelop prints the message (sorry for the long filenames, I develop on an external HDD and its UUID is quite long) :

#0  KDevelop::DUChainPrivate::removeDocumentChainFromMemory (this=this at entry=0x1042c30, context=0x7fffd0005110)
    at /run/media/steckdenis/22bf9818-cf8f-40f9-948d-9ab473a158c2/kdevplatform/language/duchain/duchain.cpp:391
#1  0x00007ffff72e7b43 in KDevelop::DUChainPrivate::clear (this=0x1042c30)
    at /run/media/steckdenis/22bf9818-cf8f-40f9-948d-9ab473a158c2/kdevplatform/language/duchain/duchain.cpp:372
#2  0x00007ffff72d1fda in KDevelop::DUChain::shutdown (this=0x1045720)
    at /run/media/steckdenis/22bf9818-cf8f-40f9-948d-9ab473a158c2/kdevplatform/language/duchain/duchain.cpp:1586
#3  0x00007ffff714179b in KDevelop::Core::cleanup (this=0x579140) at /run/media/steckdenis/22bf9818-cf8f-40f9-948d-9ab473a158c2/kdevplatform/shell/core.cpp:416
#4  0x00007ffff71417c6 in KDevelop::Core::shutdown (this=0x579140) at /run/media/steckdenis/22bf9818-cf8f-40f9-948d-9ab473a158c2/kdevplatform/shell/core.cpp:377
#5  0x00007ffff7856ed8 in QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) const () from /usr/lib64/libQtCore.so.4
#6  0x00007ffff7bc00ae in ?? () from /usr/lib64/libQtTest.so.4
#7  0x00007ffff7bc3c4e in QTest::qExec(QObject*, int, char**) () from /usr/lib64/libQtTest.so.4
#8  0x0000000000409b64 in main (argc=1, argv=0x7fffffffd928) at /run/media/steckdenis/22bf9818-cf8f-40f9-948d-9ab473a158c2/kdev-qmljs/tests/test_files.cpp:44

By looking at KDevelop::Core, I guess that the signal that is launched by QMetaMethod is QApplication::aboutToQuit. Note that TestFiles::cleanupTestCase (containing a call to TestCore::shutdown) has not yet been called when the message is printed, and is not called either before the crash.


- Denis


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118238/#review58290
-----------------------------------------------------------


On May 21, 2014, 2:40 p.m., Denis Steckelmacher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118238/
> -----------------------------------------------------------
> 
> (Updated May 21, 2014, 2:40 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-qmljs
> 
> 
> Description
> -------
> 
> This patch adds a method that returns the top-level DUContext associated with a QML plugin. It uses KStandardDirs to get the plugin.qmltypes file associated with the module (these files are installed by the plugin in KDE_DATA/kdevqmljssupport/qmlplugins/Module.qml), and then schedules a parse job for the file. If the file has already been parsed, then its top level context is returned. This method will be used to implement import statements. The module files and the complete support for import statements can be found in the "import_statements" of kde:scratch/dsteckelmacher.
> 
> 
> Diffs
> -----
> 
>   duchain/parsesession.h 0facef4 
>   duchain/parsesession.cpp 998e5b0 
> 
> Diff: https://git.reviewboard.kde.org/r/118238/diff/
> 
> 
> Testing
> -------
> 
> This patch cannot be tested as the method is not yet called, but the support for import statements is already implemented in my kde:scratch/dsteckelmacher repository. Import statements work right in KDevelop, but the unit tests segfault when they have to parse a file containing an import. The crash always happens in an openDeclaration() or currentDeclaration() call, and if I comment the faulting call, another one will crash. The crash does not happen anymore if I remove the calls to "bgparser->addDocument" added in this patch, and does not happen in a complete KDevelop instance.
> 
> I'm therefore wondering how the background parser can interact with openDeclaration(). I've checked and a DUChainReadLock or a DUChainWriteLock is always held when openDeclaration() is called, but maybe there are other locks that may be needed. I turn to more advanced KDevelop developers on this matter.
> 
> 
> Thanks,
> 
> Denis Steckelmacher
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140522/679804f1/attachment.html>