[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    Re: Catastrophic failure in KSudoku
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2019-03-20 0:33:13
Message-ID: 95DBD8EB-020B-42FA-B7B3-4C462EED28EC () gmail ! com
[Download RAW message or body]

Hi Jeremy.

Thank you very much for looking into this, Jeremy, and proposing a fix.

> On 20 Mar 2019, at 3:43 am, Jeremy Whiting <jpwhiting@kde.org> wrote:
> 
> I'm not sure if this is the best fix for the problem. But here's a patch that makes \
> ksudoku not copy the xml file before loading it into QDomDocument, just loads it \
> where it is instead. This fixes the issue here, but you probably have a reason for \
> having the copyjob in there. Let me know if I can test anything else etc.

Following on from my reply to the email you sent earlier, and for the reasons given \
in my reply, I am very happy for you to remove the use of a temp file, as in your \
proposed patch. One less thing to go wrong… :-)

Thanks again.

All the best,
Ian W.

> BR,
> Jeremy
> 
> On Tue, Mar 19, 2019 at 10:36 AM Jeremy Whiting <jpwhiting@kde.org> wrote:
> I'm not sure why gmail's reply to all isn't putting you in Ian... Anyway, the cause \
> is the QDomDocument::setContent from the QTemporaryFile after it copies the file \
> out of the installation path (why is that needed by the way?) Adding some debugging \
> to the call it seems the error is "Unexpected end of file" on line 1 column 1. I \
> checked the file does exist and such, I wonder if the download copy job is leaving \
> the QTemporaryFile object's seek point at the end of the file as it writes it or \
> something. No, adding a tmpFile.reset() before setting the content does not help. \
> It's as if the copy job finishes before the file is written to disk. I don't have \
> any weird mount options (or any, since /tmp/ is just part of my / partition here). \
> Not sure what's going on to cause QDomDocument::setContent to think the file is \
> empty... 
> On Mon, Mar 18, 2019 at 9:53 PM Ian Wadham <iandw.au@gmail.com> wrote:
> 
> 
> > On 19 Mar 2019, at 2:24 pm, Jeremy Whiting <jpwhiting@kde.org> wrote:
> > 
> > I'll see what I can figure out. no problem. Albert are you building with \
> > kdesrc-build ? or manually? I'm using kdesrc-build buliding into /usr/local. \
> > Until this morning libkdegames didn't build because I was missing libsndfile, \
> > after adding that I'm seeing the same failure described by Duncan in the bug. \
> > I'll debug it tomorrow and see what's causing it.
> 
> The variants that fail are all those whose rules are defined by XML files in \
> ksudoku/src/shapes — and only those variants. The failure point in KSudoku \
> appears to be exactly where it calls the loadCustomShape method in the \
> sudoku::Serializer code. See details in \
> https://bugs.kde.org/show_bug.cgi?id=405422#c3 
> My guess is that some newer version of XML parsing libraries dislikes KSudoku's XML \
> files or possibly that some changed XML version or DOCTYPE has got into the act.
> 
> Ian W.
> 
> > BR,
> > Jeremy
> > 
> > On Mon, Mar 18, 2019 at 4:52 PM Albert Astals Cid <aacid@kde.org> wrote:
> > El dilluns, 18 de març de 2019, a les 20:44:06 CET, Jeremy Whiting va escriure:
> > > Yep, same thing happens here. Aztec -> Generate A Puzzle shows a dialog box
> > > that says "
> > > 
> > > Unable to generate a puzzle of the chosen variant; please try another."
> > > with a build I just did.
> > 
> > Weird, works just fine for me.
> > 
> > Jeremy guess it's on you to debug it :/
> > 
> > Cheers,
> > Albert
> > 
> > > 
> > > 
> > > BR,
> > > 
> > > Jeremy
> > > 
> > > On Thu, Mar 14, 2019 at 9:24 PM Ian Wadham <iandw.au@gmail.com> wrote:
> > > 
> > > > It appears that KSudoku is failing catastrophically. Only the most vanilla
> > > > puzzle types can be selected
> > > > (i.e.  Classic Sudoku nxn and Roxdoku nxnxn). All others fail to create
> > > > their data-structures from XML
> > > > files and so fail to generate a puzzle and display it (e.g. XSudoku,
> > > > Killer Sudoku, Aztec, Samurai
> > > > and many more).
> > > > 
> > > > For more details, please see https://bugs.kde.org/show_bug.cgi?id=405422,
> > > > especially comment #3.
> > > > 
> > > > This was reported by Duncan, who builds KF5 and apps from live-git and has
> > > > just noticed the problem
> > > > appearing in the last week or two --- more recently than any changes in
> > > > the KSudoku source.
> > > > 
> > > > Please can someone who has access to builds and executables of the latest
> > > > development (HEAD)
> > > > KSudoku code check if they can reproduce this error? You just need to run
> > > > KSudoku, select Aztec
> > > > puzzle-type (for example) and click on "Generate A Puzzle".
> > > > 
> > > > Thanks in advance,
> > > > Ian Wadham.
> > > > 
> > > > 
> > > 
> > 
> > 
> > 
> > 
> 
> <ksudoku.patch>


[prev in list] [next in list] [prev in thread] [next in thread]