Opened 2 years ago
Closed 2 years ago
#13601 closed defect (fixed)
AGS: Time Gentlemen, Please - random crashes to desktop in the first scene of the game
Reported by: | antoniou79 | Owned by: | criezy |
---|---|---|---|
Priority: | normal | Component: | Engine: AGS |
Version: | Keywords: | ||
Cc: | Game: |
Description (last modified by )
This is on Windows 10 x64. Tested the GOG version with the current daily stable for upcoming 2.6.0 and with a local build of 2.7.0git from master HEAD.
Steps to reproduce:
- Start a new game
- Skip intro cutscenes
- Once you resume control in the first scene, start interacting with objects and the protagonists. Usually (but not always) this happens if you grab Dan and use him on Ben and then try to do something else.
I always got a crash (even after loading into the game to the first scene, but it seems that in that case more actions are needed to cause the crash), but not always after specific interaction so I don't have a deterministic sequence of actions. There's no error message on the console window. The game just exits.
ScummVM log does not offer any help either on this.
Edit:
Trying to quickly debug this with Visual Studio, I got two different unhandled thrown exceptions.
- One was in graphics\surface.cpp, Surface::free() at the first line:
::free(pixels);
- The other (in a separate play session) was in the destructor of VorbisStream (in audio\decoders\vorbis.cpp):
VorbisStream::~VorbisStream() { ov_clear(&_ovFile); }
Change History (5)
comment:1 by , 2 years ago
Description: | modified (diff) |
---|
comment:2 by , 2 years ago
comment:3 by , 2 years ago
This seems to be a regression. If I go back to the code from March 14 (before Dreammaster started to backport a bunch of changes from upstream) , I cannot reproduce the crash after 5 minutes trying.
It would be interesting to try with the current code from upstream AGS to see if the crash is present there as well. However that can only be done on Windows because of the Nickenstien plugin (and I am not even sure the plugin works with current AGS upstream code, so it may not be possible on Windows either).
comment:4 by , 2 years ago
Bisection gives the following result:
7132742e04805b31a5226edacfac45ac92ce011b is the first bad commit commit 7132742e04805b31a5226edacfac45ac92ce011b Author: Paul Gilbert <dreammaster@scummvm.org> Date: Thu Mar 24 21:10:24 2022 -0700 AGS: Reintroduce upstream's full alfont implementation
comment:5 by , 2 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Our alfont code is almost identical to the code from upstream AGS and I could not detect a difference that would explain the crash.
It does seem to have an inconsistency between alfont_get_font_real_height()
and the max_bmp_y
computed in alfont_textout_ex()
, causing the allocated surface to be smaller than expected for the draw by a few pixels. There are a number of hack on the computation of the real height, so possible one of those is the culprit. But I don't want to start changing those hacks, so instead I have added a sanity check in putpixel()
to make sure we do not attempt to write outside of the surface.
I can reproduce on macOS. Address sanitizer reports the following issue: