Opened 17 years ago

Closed 17 years ago

Last modified 2 years ago

#1331 closed defect (fixed)

GUI: Using options dialog causes a crash

Reported by: SF/khalek Owned by: fingolfin
Priority: normal Component: GUI
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 fingolfin, 17 years ago

Owner: set to SF/jamieson630

comment:2 by fingolfin, 17 years ago

Indeed. I fixed this in CVS.

comment:3 by fingolfin, 17 years ago

Owner: changed from SF/jamieson630 to fingolfin
Resolution: fixed
Status: newclosed

comment:4 by SF/jamieson630, 17 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 digitall, 2 years ago

Component: GUI
Note: See TracTickets for help on using tickets.