Opened 16 years ago

Closed 16 years ago

Last modified 11 months 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, 16 years ago

Owner: set to SF/jamieson630

comment:2 by fingolfin, 16 years ago

Indeed. I fixed this in CVS.

comment:3 by fingolfin, 16 years ago

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

comment:4 by SF/jamieson630, 16 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, 11 months ago

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