D5544: Port usage of KUrl and friends to equivalent constructs with QUrl.

[Ian Wadham]

I'm replying on the list because I no longer have KDE developer access.

On 24/04/2017, at 4:32 AM, Johan Ouwerkerk wrote:

> View Revision
> ouwerkerk added a comment. 
> 
> Thanks for the pointer. I'm still now sure why ksudoku would crash because at worst the puzzle should be in some 'invalid' state with bogus contents ... but then the QVector should still return a proper size() without crashing.

A Custom KSudoku game requires two files to be correctly installed, located and loaded --- the *.desktop file and the *.xml  file (containing the "graph" or puzzle-layout data).  The *.desktop files form the contents of the Welcome screen, so those must be loading OK.  The *.xml file is opened only if the user requests a puzzle of the corresponding type.  If that fails, you should get a default constructor for the game, in which all data is undefined except m_private (= 0).  In that case "game.puzzle()" should return a zero pointer, which could be causing the crash in "game.puzzle().hasSolution()".  Note that the code does not check for that zero, I guess because the custom games and their entries on the Welcome screen are closed sets which are usually fully populated, but perhaps not during porting to Frameworks… :-)  If I am right, check where the shapes/*.xml data-files for KSudoku get installed and where CustomGame::createSKGraphObject() and ksudoku::Serializer::loadCustomShape are looking for those files.

> Alternatively, possibly more likely, the memory management of the containing Puzzle object itself was already messed up and the change in code merely tickles the bug.
> 
> 
> REPOSITORY
> R417 KSudoku
> 
> REVISION DETAIL
> https://phabricator.kde.org/D5544
> 
> To: ouwerkerk, KDE Games, ltoscano
> Cc: ltoscano, KDE Games