GNOME Bugzilla – Bug 779149
Variants "Westhaven" and "Diamond-Mine" interfere: crash with wrong-number-of-args
Last modified: 2019-10-13 16:22:11 UTC
Created attachment 346600 [details] Stacktrace generated by aisleriot Hello, first of all: I'm unable to run the program with LC_ALL=C, so I'm sorry that I can only provide the German name. The German names are "Westhafen" and "Diamantenmine", which translates to "Westhaven" and "Diamonmine". The error is an "unexpected scheme error", which appears to be a wrong-number-of-args exception. If I read the stack trace correctly, then this is due to some remnant code from Diamondmine calling into code from Westhaven. Steps to reproduce: - Start aisleriot - Select "Diamondmine" - Quit aisleriot (apparently it's necessary that the *starting* game is Diamondmine) - Start aisleriot - Play a full game (not sure in how far this is necessary, but if you play through a whole game then it *always* happens.) - Select "Westhaven" Expected behavior: Westhaven starts. Actual behavior, on my i386 system: The canvas goes blank (well, background-green), a dialog opens up saying "Ein Schema-Ausnahmefehler ist aufgetreten Bitte melden Sie diesen Fehler an die Entwickler. [Nicht melden] [Melden]" which translates to something like: "An unexpected scheme exception occurred Please report this issue to the developers. [Don't report] [Report]" Those brackets are supposed to indicate buttons. Actual behavior 2, on my amd64 system (used to generate this report) : Westhaven appears to start normally, but within a few actions (1 or 2, typically), the above-mentioned dialog pops up. Clicking "Report" doesn't do anything, and on the console reports that "bug-buddy" couldn't be launched. There doesn't seem to be a package called "bug-buddy", or any package containing a relevant file [1]. See #676972. So please find the stack-trace attached. After dealing with this error, Westhaven loads successfully, but may intermittently crash and restart (the variant, not aisleriot as a whole) during operation. Manual workaround: Restart aisleriot so that Westhaven is selected from the very beginning. Please find attached a generated crash report by aisleriot, on my amd64 system. I assume that aisleriot attempted to forward these data to "bug-buddy". It includes stacktraces which indicate that Diamondmine somehow calls into Westhaven, up to impedance mismatch. I also reported this downstream as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855955 Cheers, Ben Wiederhake
Confirmed; I can reproduce this.
Created attachment 374240 [details] [review] Remove shadowing of functions in api.scm Hi, I looked into this. Westhaven uses function 'find-card' from api.scm. Diamond Mine defines its own version of 'find-card' which shadows the one in api.scm. Thus, if Diamond Mine is played at some point before Westhaven, Westhaven tries to call the function defined in diamond-mine.scm and crashes because the function signatures are different. When a game of Westhaven starts, 'find-card' is called only if no aces are visible. That is why the game doesn't always crash at the beginning. The same issue causes other games to crash too. For example Freecell crashes always if you ask a hint (if Diamond Mine has been played). A solution would be to rename 'find-card' in diamond-mine.scm. I searched for other cases where functions defined in api.scm are shadowed by game modules. I think there are only two: 'give-status-message' and 'check-straight-descending-list'. The first one is re-defined in many game modules. That causes problems with Eliminator, which crashes on start if played directly after certain games, for example Accordion. The reason is that Eliminator calls 'give-status-message', using the function defined in accordion.scm, and tries to get cards from a slot that doesn't exist. A solution for this would be to remove the call to 'give-status-message' (it is a no-op in Eliminator). The second function 'check-straight-descending-list' is re-defined in agnes.scm and causes similar problems. For example dragging piles does not always work as expected in Odessa if Odessa is played at some point after playing Agnes (the behavior depends on what was the value of the first dealt card in last game of Agnes that was played). This function could be renamed as well in agnes.scm to avoid shadowing. I'll attach a patch with the proposed fixes.
The patches look right; committed to master. Thank you!