#1331 closed defect (fixed)
GUI: Using options dialog causes a crash
| Reported by: | SF/khalek | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
When clicking on the in game Options item from the F5 menu (not the launcher), ScummVM crashes.
The backtrace in gdb seems to be recursing literally thousands of times on: Scumm::OptionsDialog::open()
I assume but have not verified this behavour was introduced after jamieson changed things to get around some of the faults of MSVC6
Tested on my x86 Linux machine and reported by BillyH on irc who is using windows.
Ticket imported from: #858262. Ticket imported from: bugs/1331.
Change History (5)
comment:1 by , 21 years ago
| Owner: | set to |
|---|
comment:2 by , 21 years ago
comment:3 by , 21 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:4 by , 21 years ago
Yes, my solution was incorrect. Arisme showed me the spec passage that deals with overrides of virtual functions. For some reason I grew up in C++ with a hammered-in notion that overrides without the "virtual" keyword were non-virtual in the sense that if the override was referenced in the context of the derived class, the vtable would not be used.
The typedef approach does not work for MSVC6 either, i.e. saying...
typedef GUI::OptionsDialog GUI_OptionsDialog;
...does not allow me to call GUI_OptionsDialog::open(). For some reason, a call is still being made to Scumm::OptionsDialog::open(). (Looking at the disassembly, I see that the call is being made DIRECTLY, not through the vtable. That is REALLY weird.)
In his initial post to scumm-devel, Arisme recommended changing the function names in Scumm::OptionsDialog. But since these functions are overrides, I don't think changing their names is an option.
What CAN be done is create "internal" versions of open(), close() and handleCommand() in GUI::OptionsDialog. That way, the public versions (that override GUI::Dialog functions) would simply call the internal versions. Likewise, derived classes like Scumm::OptionsDialog can call the internal versions without a function name conflict.
I really hate to do this, since it just muddies up code for the sake of a non-compliant compiler. But it's the only solution I can think of. Fingolfin? Any other ideas?
comment:5 by , 6 years ago
| Component: | → GUI |
|---|
Indeed. I fixed this in CVS.