D14376: kdev-clang : avoid crash in tests/test_assistants.cpp

[René J.V. Bertin]

rjvbb added a comment.


  >   What is your own answer to this? ;)
  
  Would I ask the question if I had the answer?
  Given that this issue doesn't occur in KDevelop itself (nor in the test on Linux) I'd say one would either handle the error situation gracefully, or bail out from the test as soon as it's detected.
  
  >   Please try to investigate why the document is not returned from the controller as one would expect by the code.
  
  On Linux, `Core::self()->documentController()->openDocument(url)` returns the same pointer as `Core::self()->documentController()->documentForUrl(url)` does later. On Mac the former returns a valid pointer, the latter returns NULL. It looks like this may well mean that the document isn't actually opened (or not registered in `DocumentCOntrollerPrivate::documents` but that seems extremely unlikely).
  
  Edit: this may be it:
  
  `DocumentControllerPrivate::openDocumentInternal` is one of those functions that uses asserts instead of proper runtime checks that don't disappear in release builds:
  
    // The url in the document must equal the current url, else the housekeeping will get broken
    Q_ASSERT(!doc || doc->url() == url);
  
  adding that comparison and trace output to test_assistants.cpp gives this on the terminal:
  
    QWARN  : TestAssistants::testRenameAssistant(Prepend Text) openDocument QUrl("file:///var/folders/j1/1439ppj08xj8h6006s6drbq00000gs/T/test_assistants-OT8CTF/0.h") doc= 0x7fe1532bd6a0
    QSYSTEM: TestAssistants::testRenameAssistant(Prepend Text) doc->url= QUrl("file:///private/var/folders/j1/1439ppj08xj8h6006s6drbq00000gs/T/test_assistants-OT8CTF/0.h") != QUrl("file:///var/folders/j1/1439ppj08xj8h6006s6drbq00000gs/T/test_assistants-OT8CTF/0.h")
    QWARN  : TestAssistants::testRenameAssistant(Prepend Text) docForUrl QUrl("file:///var/folders/j1/1439ppj08xj8h6006s6drbq00000gs/T/test_assistants-OT8CTF/0.h") (adjusted= QUrl("file:///var/folders/j1/1439ppj08xj8h6006s6drbq00000gs/T/test_assistants-OT8CTF/0.h") )= 0x0
  
  This is indeed a Mac-specific issue: /var is a symlink to /private/var and file name normalisation is almost unavoidable on Mac (and hardcoded here, I think).
  
  That means the situation is to be expected and my fix isn't wrong in itself, but maybe we can avoid the cause by doing the normalisation step after generating the url and before using it(?).

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D14376

To: rjvbb, kossebau
Cc: kossebau, kdevelop-devel, antismap, iodelay, vbspam, njensen, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180725/e0bc1e1b/attachment.html>