Bug 64991

Summary:	Solver and Magic reveal conflict (failed assertions)
Product:	[Applications] kmines	Reporter:	Danilo Piazzalunga <dpaina>
Component:	general	Assignee:	Hadacek Nicolas <hadacek>
Status:	RESOLVED FIXED
Severity:	crash
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Calls Solver with completeReveal disabled

Description Danilo Piazzalunga 2003-09-26 13:31:03 UTC

Version:           CVS (using KDE KDE 3.1.3)
Installed from:    Debian testing/unstable Packages
Compiler:          gcc 3.3.2 
OS:          Linux

Note on versions: I'm using KMines with libkdegames compiled from CVS. All the rest is installed from Debian sid.

It looks like Solver and Magic-reveal simply don't mix up.
When I try to run Solver while that option is on, Solver often gets lost, until I
1. take control of the game again
2. start a new game
3. run Solver again.

Moreover, doing steps 2 or 3 make some assertions fail:

kmines: advFastRules.cpp:74: void AdviseFast::RuleSet::solve(): Assertion `reveal(p)' failed.
kmines: adviseFull.cpp:480: void AdviseFull::getProbabilities([...]): Assertion `!l.empty()' failed.
kmines: solver.cpp:158: bool Solver::solveStep(): Assertion `b' failed.
kmines: solver.cpp:166: bool Solver::solveStep(): Assertion `!probabilities.empty()' failed.

I think Adviser->Solve function should be disabled when Magic reveal is on, or maybe Magic reveal should act only on user inputm, and be made inactive while Solver is running.

Best regards,
	Danilo

Comment 1 Danilo Piazzalunga 2003-09-29 14:41:28 UTC

Created attachment 2619 [details]
Calls Solver with completeReveal disabled

This patch solves the problem by disabling completeReveal before starting the
Solver, and then restoring it to its previous status after the Solver has
finished its job.

[ The program can still crash if, while the Solver is running, a (nasty) user
interferes (by revealing cells, starting a new game, etc.). But that's user's
fault :-P ]

Comment 2 Helge Deller 2003-11-02 21:59:19 UTC

I have no clue about kmines and the patch above, but at least I can confirm, that
starting kmines and the clicking on Move->Solving rate...->start crashes kmines:
(KDE 3.2 beta1, CVS version from 2003-11-02)

0x413d0a86 in waitpid () from /lib/i686/libpthread.so.0
#0  0x413d0a86 in waitpid () from /lib/i686/libpthread.so.0
#1  0x408c9673 in KCrash::defaultCrashHandler(int) (sig=11)
    at /home/cvs/kde20/kdelibs/kdecore/kcrash.cpp:246
#2  0x413cf96c in __pthread_sighandler () from /lib/i686/libpthread.so.0
#3  <signal handler called>
#4  0x08077b27 in AdviseFast::FactSet::reveal(QPair<int, int>, std::set<QPair<int, int>, std::less<QPair<int, int> >, std::allocator<QPair<int, int> > >*) ()
#5  0x08070a24 in AdviseFast::RuleSet::reveal(QPair<int, int>) ()
#6  0x0806df4a in Solver::solveStep() ()
#7  0x0806d298 in Solver::qt_invoke(int, QUObject*) ()
#8  0x40cfc730 in QObject::activate_signal(QConnectionList*, QUObject*) ()
   from /mnt/hdc6/home/cvs/kde20/qt-copy/lib/libqt-mt.so.3
#9  0x40fec506 in QSignal::signal(QVariant const&) ()

Comment 3 Hadacek Nicolas 2004-01-29 04:50:39 UTC

I just commited a fix to CVS HEAD. Please test ... will backport soon.

thanks for the report.