GNOME Bugzilla – Bug 423478
Sudoku fails to realize a puzzle being solved
Last modified: 2010-04-06 18:57:08 UTC
Please describe the problem: Sometimes Sudoku doesn't realize a puzzle has been solved. Steps to reproduce: For instance this happend for me with puzzle 44 - as attached. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 85403 [details] Puzzle 44
Created attachment 85406 [details] Again :-(
Created attachment 85407 [details] Puzzle 48 Could this be for using reminders (small numbers above and below the real number)?
I can confirm that this has happens, as seen in a bug I filed at my distribution bugtracker: https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/103466 The expected result when you fill in all the squares in a puzzle is that the high-score window is shown with a new entry for the game you just played added. I think Mathias' hunch may be right. After playing one simple game without using any of the notes, it did recognise when I completed the game. (By the way, Mathias, puzzle numbers are not the same on all computers - I believe they just represent the order in which a puzzle was generated on your computer.)
Now I have been hit by this problem when solving an ambiguous puzzle. So maybe the real problem is generating ambiguous puzzles and using hints just a result of solving such puzzles?
I've been playing a lot lately and Sudoku fails to detect the game has ended when I use reminders. When I use reminders and complete the game (undetected), pressing the "New" button just gives me a cleared version of the same old game unless I change the difficulty. I get the same game again even if I press the New button multiple times. If I exit Sudoku and start the app again, pressing New behaves as expected. This is a rather annoying bug since I can't beat the hard games without reminders. I hope this helps to track it down. Jon GNOME Sudoku 2.18.1 on Ubuntu Feisty (7.04)
I was completely convinced that "reminders" always cause this problem but I just had the game end properly after using them. For perspective, 1 in 20+ games I've played ended properly. Jon
I just started using Suduko and I'm seeing the same problem. It seems to me that the high score window isn't displayed unless the game scores in the top 5. Bob
I have yet to have a single game be detected as done. When the last square is filled, the game "hangs" (paints continue, but no buttons, menu items, or squares will accept mouse or keyboard input). If I hard-kill sudoku (destroy in the windowmanager; kill doesn't work), and restart, the board is full, but the game is not "complete". I can start a new game at that point. If, instead, I select Fill All, then the game hangs again just like before. I'm on gnome-games 2.18.1
Just as an update to this: It appears that the dialog is just not showing. If I change hs.run_dialog() in you_win_callback() to hs.run_swallowed_dialog(self.swallower) the dialog is swallowed properly, and I can continue. So I guess my bug is not related to this one afterall...
I was able to make a game complete. After filling the last square, I deleted one entry, and exited the game. When I restarted the game, I went to menu -> resume old game and selected the one I was just playing. I put in the number I had just erased and the game came up with the completion window with the score for the game. This was a hard game, I used the tracker but didn't have to back up with it. I didn't use any hints, but made notes. Another thing that seems to happen that I don't like is the game number sometimes changes after I play the game. I might play game 15, finish it, then run Suduko again. The same game is displayed but it will have a different number. Bob
(In reply to comment #11) > I was able to make a game complete. After filling the last square, I deleted > one entry, and exited the game. When I restarted the game, I went to menu -> > resume old game and selected the one I was just playing. I put in the number I > had just erased and the game came up with the completion window with the score > for the game. This was a hard game, I used the tracker but didn't have to back > up with it. I didn't use any hints, but made notes. > > Another thing that seems to happen that I don't like is the game number > sometimes changes after I play the game. I might play game 15, finish it, then > run Suduko again. The same game is displayed but it will have a different > number. > > Bob > This works pretty consistently. If I complete a game and don't get the summary window, I can delete on square, close Suduko, open it again and complete the square. I get the summary with the score. I don't have to go thru the step of resuming the old game. The score may have to be higher than the lowest score recorded so far. With my improving skill at Suduko, I haven' had a lower score yet. Bob
*** Bug 455397 has been marked as a duplicate of this bug. ***
Happens to me too (ubuntu Feisty) on unique (i.e. logically deduced, no trial and error, no possibility of an alternative solution) problems. I also get the occasional single RED number - not paired with another red number. As a workaround to improve the motivation to play the game, could we have a command to report status and force the finalisation of the game if there are no duplicates and no squares to fill in? I suspect it would be a waste of everybody's time for me to try to fix it, but for somebody who already knows a bit about the code it might be a viable workaround.
413948 is another duplicate - is it policy to confirm bugs when duplicates are posted?
*** Bug 413948 has been marked as a duplicate of this bug. ***
I have a Gutsy Gibbon with this problem nicely repeatable. I have played this particular game several times, it never completes when I do. If I start a new one I get the same game again, so I am getting to know it quite well!. I have yet to make no errors at all. I usually hit one wrong key at some stage when my concentration flags. I never use hints, and I never make notes. This game requires no trial and error, so my solution sequence is fairly consistent. How can I best help you to find the bug? I'm not a programmer or debugger by trade, but I can copy console commands, and sometimes understand what they are doing. Given how good the game is, and how it is messing me about at present, I would give this a higher priority. ;)
Created attachment 97951 [details] Screenshot showing same game after completion Note the creation times...
(In reply to comment #17) > I have a Gutsy Gibbon with this problem nicely repeatable. I have played this > particular game several times, it never completes when I do. If I start a new > one I get the same game again, so I am getting to know it quite well!. > > I have yet to make no errors at all. I usually hit one wrong key at some stage > when my concentration flags. I never use hints, and I never make notes. This > game requires no trial and error, so my solution sequence is fairly consistent. > > How can I best help you to find the bug? I'm not a programmer or debugger by > trade, but I can copy console commands, and sometimes understand what they are > doing. > > Given how good the game is, and how it is messing me about at present, I would > give this a higher priority. ;) > First, go to New, click on Details and pick a different game. It will give you a little more of a challenge. Second, try my workaround. When you finish the game, delete one of the squares and using the Game menu, close the game. Then start the game again, fill in the square you deleted, and the game will complete with the total time you took to do it. It doesn't always work if I just close the window without going thru the menu. Bob
Thanks for the workaround tip to close the game and move on. At present I'm interested in keeping this repeatable problem alive in case it helps sort the bug, so I'll use your tip on another computer.
I have a steps-to-reproduce and a workaround: Reproduce: 1. Complete a game except for one square. 2. Use Fill to enter that square. 3. "High Scores" dialog box does not appear. Workaround: 1. Delete any square. 2. Manually enter the square. 3. "High Scores" dialog box appears.
This bug is likely a number of separate bugs, most (all?) of which have been fixed. I recently experienced it with a tracker -- I've made some clean-ups of code around that, and seem to have resolved that issue for the time being. If people are still getting dups of this with the latest code, please let me know. Otherwise, I think we should be able to close this bug soon. Things that could conceivably trigger this bug are: 1. Trackers 2. Undo/Redo 3. Conflicts (answers highlighted in red) being erased and re-typed. The bug does not have anything to do with high scores as posited above (high scores are now gone anyway, but even when they were there the puzzle being or not being in the top scores wouldn't have triggered this).
I think I have solved this - it is caused when you click the "Clear" button on the little number-picker. This adds the digit 0 to the row object, so it's length when completed is greater than 9, and the game counts this as an uncompleted game. A work-around is to use the delete key instead of the number-picker to remove numbers. Or you can edit (you'll need to be root) /usr/lib/python2.5/site-packages/gnome_sudoku/gsudoku.py and at about line 292 change the function number_changed_cb() like this: def number_changed_cb (self, ns, w): w.destroy() self.set_text_interactive('') newval=ns.get_value() if newval: self.set_text_interactive(str(newval))
Greg -- sweet! I just tested and confirmed I can reproduce the bug as you describe (and fixed it with your patch). I went ahead and implemented your fix -- thanks!
Thomas, please take a look here: http://live.gnome.org/TwoPointTwentyone There is currently a code-freeze for the 2.22.0 release. Altough I don't think anything should be reverted right now, we should always try to follow the various freezes before GNOME releases...
Andreas, Apologies -- the schedule wasn't on my radar. fwiw, this is a simple enough fix it shouldn't cause any new problems, and it fixes a bug that's been a headache for a while.
Great! Nice to see this bug finally fixed. Since this kind of thing needs a freeze break request from the release team I went ahead and got one. This should fix 419904 too right?
this patch has received three of two approvals by the release team. andreas & thomas, i guess you can close this as fixed.
closing as fixed
*** Bug 419904 has been marked as a duplicate of this bug. ***
*** Bug 525180 has been marked as a duplicate of this bug. ***
*** Bug 544357 has been marked as a duplicate of this bug. ***
REOPEN? I still get this bug, but much more rarely than before the last fix. Since at least one new report has been marked as a duplicate, I am not alone. Being a much more rare occurrence has advantages and disadvantages. The advantage is that I am very sure it is not now associated with the use of hints. I suspect it is associated with the use of tracker and (possibly) encountering dead ends. The disadvantage is it might be a long time before I can identify whether it is associated with the flagging of unfillable squares, which occasionally happens without the use of tracker. The severity of the bug is much reduced, since there is a fix which seems to always work. Shutting Sudoku, reopening, deleting one of the cell contents and undoing the delete always seems to clear it. Cheers Chris
Created attachment 115154 [details] A recent screenshot This example came along (on 17 July) after a long session involving multiple trackers.
Bug 544357, which appears to be very similiar to this one, was reported on version 2.22.2.1 of gnome-sudoku.
(In reply to comment #34) > This example came along (on 17 July) after a long session involving multiple > trackers. This does not help. Please tell us the exact version you are running.
Andre - courtesy of another (new?) bug, when I try to load Sudoku today I am running: Distribution: Ubuntu 8.04 (hardy) Gnome Release: 2.22.2 2008-06-03 (Ubuntu) BugBuddy Version: 2.22.0 System: Linux 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 X Vendor: The X.Org Foundation X Vendor Release: 10400090 Selinux: No Accessibility: Disabled GTK+ Theme: Human Icon Theme: Human Sadly, the screenshot is something like ten days old, and I cannot say whether any of the Ubuntu releases in the meantime have left me with any current details that may now be irrelevant to the screen shot. Chris
A 'fresh' occurrence today - dumps of .sudoku and screen shots follow, including Help-About version information.
Created attachment 115591 [details] dumps of .sudoku completed, saved, and eventually finished by reloading. .sudoku saved after each of these steps: Finished - finish not recognised. Closed. Restarted, deleted 6 from top row and reinput it, game finished. plus screenshots of unrecognised finish and Help-About
Another example. No hints used, two impossible-to-fill shown to me, and a couple of unintended entries cleared - one of which was a possible entry (but not proven correct, so cleared) and one which was a duplicate indicated in red, and cleared. GNOME Sudoku 2.22.3 on ubuntu Hardy. .sudoku dumps: A after unrecognised completion but unsaved. B closed C after reload, deleting one cell and closing D after reload, filling the cell (completion recognised) and close
Created attachment 116266 [details] dumps A-B-C-D referred to above
Yet another. Possibility? The 'impossible to fill' warning sometimes comes just after I type a number in the cell. Is there a possibility that this confuses the completion testing algorithm? I'll freeze the A and B dumps with today's date in case they are of use. The .dbg dump is never triggered - because there is no crash? Am I right in assuming the screen dumps are no help? Chris
Reopening as per last comments.
OK - it's not the 'impossible to fill' message. I've just got the problem again with the warning switched off. It does seem to be associated with my use of the tracker, possibly only after clearing a dead end track? Another set of .sudoku dumps saved. Chris
Confirmed here. Ubuntu Hardy 64 GNOME Sudoku 2.22.3 The workaround worked for me, i.e.; Clear one square, close program, reopen and fill square. I had notes in many of the squares. I've noticed that if I delete the notes as I fill in the boxes the program will recognize the puzzle as finished. You have to delete the note in the current box, enter the number for that square and move to the next one and repeat, always deleting the note before you enter the answer in the square.
Created attachment 116766 [details] sequence of dumps ending one game 3 trackers used
Clearing notes could be a possibility. I only leave notes around when I am using a tracker - I freeze my notes when I start the first track. Or it might be clearing a tracker - I will see whether it happens when I clear trackers by hand. Has anybody seen the problem when a tracker has definitely NOT been used?
OK - a bit of luck here. When I cleared trackers by hand, game 002400800090003004000000106409028001005106900200950308907000000100800070003001400 finished OK. BUT - when I asked for another game I got the same game again in spite of just having finished it. So now it gets complicated..... I have had repeat games in the past - perhaps there is only a limited number of games, perhaps they are selected at random, perhaps there is another bug somewhere - only the author/programmer would know. Getting this game again immediately might be a coincidence, (a bit of very good luck) or there may be more to it. But here was a fantastic opportunity to try the same game again, using the same strategy (because I could remember it!) and this time not clearing the tracker by hand, but using the clear track button. Repeating it as nearly as possible (absolutely no guarantee, except that I knew where my tracks started) but using the clear tracker button instead of clearing by hand, it failed to complete. So I think something may be going wrong when the clear track button is being used. There are three different circumstances I can think of, and possibly only one of them gives the problem - they are: Player sees an impossible situation and clears the track. Game indicates an unfillable cell and player clears the track. Game indicates an invalid cell value, highlighting duplicate(s) in red, and player clears the track. Cheers Chris
Created attachment 117134 [details] Game(s) referred to abov dump A only - after using the Clear Track button
Since my last post I have never used the clear track button. I have always cleared failed tracks by hand, one cell at a time. Every game has completed. Not logically conclusive, but strongly suggests that there is a way of using clear track, or a context in which it is used, that causes the game record to be corrupted so that it does not complete.
In my experience, I have only had the problem after using the "Clear Tracker" feature, but as far as I can remember, only after using it more than once. The workaround of quiting the game, loading the saved game and re-entering one of the numbers works for me. The problem is still present in 2.24.1.
Created attachment 121679 [details] Undetected completed game in Sudoku 2.24.1 Game completed but completion not detected in Sudoku 2.24.1. I had to use Clear Tracker 3 times during this game.
Still an issue with Package: gnome-games 1:2.26.1-0ubuntu2, see attached screenshot.
Created attachment 134901 [details] undetected solution
I think this bug is already fixed in version 2.27.2. Let me explain. First, I present steps to reproduce in version 2.26.2: 1) Start a new game 2) Add a tracker 3) Fill a square, without causing any conflicts. 4) Fill another square, conflicting with that first square, but not any other squares 5) Clear the tracker 6) Solve the puzzle 7) Watch gnome-sudoku fail to notice that you just solved the puzzle What happens here is that a number of circumstances fall into place just so that SudokuGameDisplay.remove() will add the value None while clearing the tracker. When None will in turn be added to grid that will cause InteractiveSudoku.check_for_completeness() to always retorn False. Prior to 2.27.2 SudokuGameDisplay.remove() has been rewritten to something a bit more sane, which accidentally fixed this bug. A little curiousity is that SudokuGrid.add() starts with the following: if not val: pass If the if-clause's body would do more than just pass and actually act on omebody trying to add None or 0, it would have also catched that bug. But that shouldn't happen in the first place anyway. Cheers, David
Hi David, The above reproduce steps are awesome! I think the related code is way from reasonable and it's hard to know what it's doing :/. For example, this seems to also make a workaround, In gsudoku.SudokuGameDispaly.delete_by_tracker, around line #1231, -self.remove(x,y) +self.remove(x,y, do_removal=True) I don't quite understand actually...
This error is reproducible with version 2.28.0 Screenshots exists in ubuntu's launchpad: https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/380828
I never use the tracker but it happens to me too. Here's how to duplicate... 1) Fill a square, without causing any conflicts. 2) Fill another square in another row, conflicting with that first square, but not any other squares 3) Change the first square so that the 2nd square that you filled in won't conflict anymore. 4) Now SudokuGrid.rows will have an incorrect length because the the 2nd square was never re-checked to see if it's correct. check_for_completeness uses SudokuGrid.rows to check whether the puzzle has been solved. The bad numbers may not be put SudokuGrid, bad numbers don't get saved when you exit and load the game back. 2nd related problem(numbers marked good but they're really bad numbers)... 1) Fill a square, without causing any conflicts. 2) Fill another square in another row, conflicting with that first square, but not any other squares 3) Change the first square to another number 4) Change the first square back to the conflicting number. 5) The 2nd number is now marked as a good number when it's really a bad number. The grid really needs to be recalculated everytime you change a number and maybe the bad numbers need to be stored somewhere for recalculation.
I recently made a patch to fix this. Thomas committed it to the repository. Essentially the conflict resolution code needed some attention, kind of like what hankin has pointed out. Please take a look at Bug 608907 if you are interested in taking a look at the patch, and it is committed on version 2.30 in the repository.
*** This bug has been marked as a duplicate of bug 608907 ***