「view this page in B3 βῆτα server」

Revisions №424

branch: interactive/develop 「№424」
Commited by: Rocco Moretti
GitHub commit link: 「a6ff30f6d850aa3d」 「№5861」
Difference from previous tested commit:  code diff
Commit date: 2022-02-22 17:46:39
foldit.build.debug foldit.build.release foldit.defines foldit.levels foldit.unit.debug foldit.unit.release

Merge pull request #5861 from RosettaCommons/roccomoretti/interactive_bind_soft_crash [Foldit] Don't (immediately) crash if callback objects are past their lifetime. Continuing on from my examination of the crash reports from the intro tutorials, I noticed there's a fair amount of crashes related to callbacks, specifically failing the indirection_shim object lifetime check from the checked_fxn_wrapper. It looks like this mostly coming from the EventHandler::on_lose_highlight() callback, and from what I can tell that's pretty much all from the Panel and StaticImage callbacks set in src/game/application/PuzzleDialog.cc. Unfortunately, I don't see anything obviously wrong with the lifetime handling which we can fix. With a fair amount of history with the checked_fxn_wrapper, I think it's now okay-ish to make failing the object check to simply be a no-op. (That is, if the object we're running the member function on has ended its lifetime and no longer exists, don't crash, but simply skip running the function.) -- For many things, such as the display updates, this is fine: we don't need to update the display of an object which no longer exists. For other things, this may be slightly dangerous, as it may result in inconsistent state or a return value which is nonsense. But if it is an issue, chances are that it would crash later, and if it doesn't, then we're doing better by the user. But to help with debugging, I've added a soft-crash report when it happens, such that we can get informed if that's a major source of issues. But to be useful, we need to have a backtrace with the soft crash. I already had a branch with this enabled, which also includes some use cases with the ligand entries. So from an end user perspective, what should happen is things which were resulting in a hard crash aren't (necessarily) a crash anymore. That may result in a more obtuse error result later, but hopefully combined with the soft crash info, it should be interpretable. RELEASE NOTES: Address some crashes related to switching puzzles.

...