[Scummvm-tracker] [ScummVM] #10173: GUI: Game executed did not match window title or selection

[Colin Snover]

#10173: GUI: Game executed did not match window title or selection
---------------------+-------------------
  Reporter:  g5ppc   |      Owner:  g5ppc
      Type:  defect  |     Status:  new
  Priority:  low     |  Component:  GUI
Resolution:          |   Keywords:
      Game:          |
---------------------+-------------------
Changes (by csnover):

 * status:  pending => new
 * resolution:  worksforme =>


Comment:

 Another user on Windows was able to reproduce this bug privately to me.
 The French versions of EcoQuest did what is described above, following the
 repro steps with English versions did this instead:

 [[Image(https://bugs.scummvm.org/raw-
 attachment/ticket/10173/Screen%20Shot%202017-09-07%20at%2023.29.19.png)]]

 After a restart of ScummVM the games would load fine. 54514 is an invalid
 offset for script 0 no matter what which EcoQuest game you are playing.

 So, this is pretty scary, but at least it seems whatever is going on is
 reproducible across different Windows computers so hopefully a Windows dev
 with a debugger can look at this and figure out what is going on.

 Statically, I was unable to see anything that looked like a logic error in
 the detector code, nor in the game execution code. SciEngine doesn’t seem
 to be doing anything terrible to cause this, and SearchMan looks like it
 should never end up in some partially populated state (it should actually
 not end up in any populated state at all until the first game starts). The
 LauncherDialog seems to have a bit more responsibility than perhaps it
 should (it sets the path for the game entry) but it doesn’t seem like it
 could be screwing things up since it is just sending that stuff to
 ConfMan, so it would seem difficult for anything there to be wrong since
 it seems like the wrongness would then be persisted to the next restart
 (though I suppose it is possible that it is some issue with in-memory
 representation that gets corrected when it re-reads everything from config
 after a restart, though I would expect this bug to be cross-platform
 then).

 My best guess right now is that there is some caching problem in
 FSNode/FSDir, or, seemingly most likely since this is currently only
 reproduced on Windows, a similar sort of problem somewhere in the
 `backends/fs/windows` code.

--
Ticket URL: <https://bugs.scummvm.org/ticket/10173#comment:5>
ScummVM <https://bugs.scummvm.org>
ScummVM