Created attachment 131757 [details] Kmahjongg Game in binary format as described in the report SUMMARY STEPS TO REPRODUCE 1. Load the game from the attached file 2088946915-saved-on-0.8-crashing-on-0.9.kmgame (this file has been produced with a kmahjongg version 0.8 on Ubuntu 16.04) 2. Press Undo 14 times 3. OBSERVED RESULT The first 13 Undo clicks restore pairs of not matching tiles, the fourteenth Undo crashes KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kmahjongg path = /usr/games pid = 1291178 KCrash: Arguments: /usr/games/kmahjongg KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi QSystemTrayIcon::setVisible: No Icon set EXPECTED RESULT Any Undo click should restore the (matching) pairs as they have been played and stored in the file. SOFTWARE/OS VERSIONS KDE Frameworks Version: Package: kde-runtime Version: 4:17.08.3-2.1 Qt Version: Package: libqtcore4 Version: 4:4.8.7+dfsg-20 ADDITIONAL INFORMATION The attached file was produced by kmahjongg 0.8 and has not been tampered. The game number was 2088946915 in the set of solvable games.
I had a look and sincerely can't see why it doesn't work, that saving/loading code hasn't changed since then :/
Created attachment 131956 [details] Same game stored by kmahjongg 0.9 in current binary format As a reference, I attach the same game played on 0.9 and then stored from there. Maybe you know of a good converter from binary to something human readable, that might reveal something interesting?
Hello @all, while working on that bug, I found another which might explain that wrong matching tiles will be added. It is due to wrong countering which has been changed in the past. Therefore it will work with current versions an saving and loading (wrong save and wrong read). This needs to be fixed. And I will have a look, where it might be fixed best. The segfault is a little bit harder. It seem to be because of QByteArray and its detach function. This doesn't seem to be an out of bounds and I cannot find the reason for it. Maybe someone else has an idea. Function calling stack while debugging: ----- std::__atomic_base<int>::load(std::memory_order __m, const std::__atomic_base<int> * const this) (/usr/include/c++/12/bits/atomic_base.h:488) QAtomicOps<int>::loadRelaxed<int>( _q_value) (/usr/include/qt5/QtCore/qatomic_cxx11.h:239) QBasicAtomicInteger<int>::loadRelaxed(const QBasicAtomicInteger<int> * const this) (/usr/include/qt5/QtCore/qbasicatomic.h:107) QtPrivate::RefCount::isShared(const QtPrivate::RefCount * const this) (/usr/include/qt5/QtCore/qrefcount.h:101) QByteArray::detach(QByteArray * const this) (/usr/include/qt5/QtCore/qbytearray.h:521) QByteArray::operator[](QByteArray * const this, int i) (/usr/include/qt5/QtCore/qbytearray.h:627) GameData::setBoardData(GameData * const this, short z, short y, short x, UCHAR value) (/home/christian/Programmierung/kde/src/kmahjongg/src/gamedata.cpp:103) GameData::putTile(GameData * const this, short z, short y, short x, UCHAR f) (/home/christian/Programmierung/kde/src/kmahjongg/src/gamedata.cpp:52) GameView::addItem(GameView * const this, POSITION & stItemPos, bool updateImage, bool updateOrder, bool updatePosition) (/home/christian/Programmierung/kde/src/kmahjongg/src/gameview.cpp:625) GameView::addItemAndUpdate(GameView * const this, POSITION & stItemPos) (/home/christian/Programmierung/kde/src/kmahjongg/src/gameview.cpp:631) GameView::undo(GameView * const this) (/home/christian/Programmierung/kde/src/kmahjongg/src/gameview.cpp:147) KMahjongg::undo(KMahjongg * const this) (/home/christian/Programmierung/kde/src/kmahjongg/src/kmahjongg.cpp:246) QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (KMahjongg::*)()>::call(void (KMahjongg::*)(), KMahjongg*, void**)(void (KMahjongg::*)(KMahjongg * const) f, KMahjongg * o, void ** arg) (/usr/include/qt5/QtCore/qobjectdefs_impl.h:152) QtPrivate::FunctionPointer<void (KMahjongg::*)()>::call<QtPrivate::List<>, void>(void (KMahjongg::*)(), KMahjongg*, void**)(QtPrivate::FunctionPointer<void (KMahjongg::*)()>::Function f, KMahjongg * o, void ** arg) (/usr/include/qt5/QtCore/qobjectdefs_impl.h:185) QtPrivate::QSlotObject<void (KMahjongg::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*)(int which, QtPrivate::QSlotObjectBase * this_, QObject * r, void ** a, bool * ret) (/usr/include/qt5/QtCore/qobjectdefs_impl.h:418) libQt5Core.so.5![Unknown/Just-In-Time compiled code] (Unbekannte Quelle:0) libQt5Widgets.so.5!QAction::triggered(bool) (Unbekannte Quelle:0) libQt5Widgets.so.5!QAction::activate(QAction::ActionEvent) (Unbekannte Quelle:0) libQt5Widgets.so.5![Unknown/Just-In-Time compiled code] (Unbekannte Quelle:0) libQt5Widgets.so.5!QAbstractButton::mouseReleaseEvent(QMouseEvent*) (Unbekannte Quelle:0) Thank you all in advance for investing your time and for your help in making KDE applications even better. Greetings from Christian
does running it in valgrind saysomething useful?
(In reply to Albert Astals Cid from comment #4) > does running it in valgrind saysomething useful? No, I still can't get any useful information on that - well nothing I can handle. Based on an relatively old bug, that is not confirmed for saving and loading on current version files. I would suggest to ask whether the benefit is big enough here to justify the amount of resources in time I am investing. The oldest commit I found with version 0.9 is from 2016. I would estimate, that most users are now on 0.9. Therefore I would like to set this bug on "RESOLVED" with the information, that saving and loading files at version 0.9 is not a problem here. Feel free to reopen it on any concerns. Thank you very much for reporting this bug @Andreas König Greetings Christian
Christian what do you mean UNMAINTAINED?
Meaning: It is resolved by not being maintained anymore, because it is actually not solved, but not relevant anymore. Is there a different common state for this situation? Cause to me it doesn't seem to be fixed by definition. Greetings Christian(In reply to Albert Astals Cid from comment #6) > Christian what do you mean UNMAINTAINED? Meaning: It is resolved by not being maintained anymore, because it is actually not solved, but not relevant anymore. Is there a different common state for this situation? Cause to me it doesn't seem to be fixed by definition. Greetings Christian
unmaintained means the app is not maintained, which isn't the case. It'd go for untentional of not a bug if it's something that we do on purpose.