Catastrophic failure in KSudoku

[Jeremy Whiting]

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.

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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20190319/e0f28db1/attachment.html>