Catastrophic failure in KSudoku

[Ian Wadham]

> On 20 Mar 2019, at 1:28 pm, Jeremy Whiting <jpwhiting at kde.org> wrote:
> 
> Hi Ian,
> 
> Awesome. I've pushed the patch to git here: https://cgit.kde.org/ksudoku.git/commit/?id=40e80d73866634c954dce212f2da43cd0fdce8d6 feel free to merge to master if you're good with it. I think the applications freeze is coming up in a couple of days though from looking at https://community.kde.org/Schedules/Applications/19.04_Release_Schedule I'm happy to push to master if you're not set up to do it also, let me know.

Yes please. Please do all the necessary commits, merges, pushes or whatever. I am not set up for that and my knowledge of git is extremely rusty.

Thanks,
Ian W.

> BR,
> Jeremy
> 
> On Tue, Mar 19, 2019 at 6:33 PM Ian Wadham <iandw.au at gmail.com> wrote:
> 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 at 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 at 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 at gmail.com> wrote:
> > 
> > 
> > > On 19 Mar 2019, at 2:24 pm, Jeremy Whiting <jpwhiting at 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 at 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 at 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>
>