Pressing F12 crashes latest debug version of game.

[Switeck]

I still get this error with latest svn compile build (4652).

[Kaks]

That's right.

And it's not likely to be fixed either, it's an obscure gdb specific crash - it only ever happens if you run Oolite using gdb, and it's seemingly related to gdb's interaction with a native windows dll - its priority is therefore very low, and seemingly not coming from Oolite's code.

And given that the stack trace seems close to useless, the only way we'd have to fix it is to have a sudden, major brainwave.



This 'might' sound flippant, so here's more info!


Every single piece of code that gets called when pressing F12 is also called in other places without triggering this bug.

Here's what Oolite does when F12 is pressed:

Code: Select all

					case SDLK_F12:
						[self toggleScreenMode];
						if([[PlayerEntity sharedPlayer] guiScreen]==GUI_SCREEN_GAMEOPTIONS)
						{
							//refresh play windowed / full screen
							[[PlayerEntity sharedPlayer] setGuiToGameOptionsScreen];
						}
						break;

Oolite doesn't do anything else - at all - whenever F12 is pressed.

SDLK_F12 is a flag that's passed to Oolite by the SDL dll, and over which Oolite hasn't got any control.

If you're not looking at the game options screen all that happens is

Code: Select all

 [self toggleScreenMode];

if you're looking at the game options screen, Oolite redraws it, to toggle the display line to read 'play in full screen' and 'play in window' according to which mode you're in.

What happens when you toggle between full screen and windowed modes by clicking on the F2 'play in full screen' / 'play in window' line?

The relevant bit of code is this:

Code: Select all

	if ((guiSelectedRow == GUI_ROW(GAME,DISPLAYSTYLE)) && selectKeyPress)
	{
		[gameView toggleScreenMode];
		// redraw GUI
		[self setGuiToGameOptionsScreen];
	}

The only difference? It doesn't check to see if we're looking at the game option screen.
In order to reach this part of the code we must be looking at that screen, so no extra check is needed.

Naturally, the code to check if we're looking at a specific gui screen is used in a lot of different places, without causing any trouble at all.

So it's definitely a puzzle. And one with only 2-3 pieces at that!

I don't know if all SDL programs do crash the same way if ran via gdb & using the same windows dll, but my first guess would be an emphatic 'yup'!
It might be something that the SDL people are aware of already, and it might have been addressed for the upcoming version of that library, but I haven't checked that myself: 'meh, life's too short'.

In any case, there's always the gdb workaround I gave you before. You might want to change gdb's settings so it launches with

Code: Select all

handle SIGTRAP noprint nostop

by default...


Cheers,

Kaks.

[CommonSenseOTB]

This is probably a stupid thought but what would happen if you substituted "===" in place of the "==" in the above sections of code?

[Capt. Murphy]

It's Obj C code not JS and == in Obj C is equivalent comparator to === in JS. Obj C doesn't have an equivalent 'fuzzy equals' that == is in JS.

[Micha]

This is probably a stupid thought but what would happen if you substituted "===" in place of the "==" in the above sections of code?

It wouldn't compile because "===" is not a valid Objective-C operation.

We're talking about the actual game code here, not about OXP Javascript.

Ninja'd!

[Switeck]

And it's not likely to be fixed either, it's an obscure gdb specific crash - it only ever happens if you run Oolite using gdb, and it's seemingly related to gdb's interaction with a native windows dll - its priority is therefore very low, and seemingly not coming from Oolite's code.

And given that the stack trace seems close to useless, the only way we'd have to fix it is to have a sudden, major brainwave.
...
In any case, there's always the gdb workaround I gave you before. You might want to change gdb's settings so it launches with

Code: Select all

handle SIGTRAP noprint nostop

by default...

I didn't put much value in backtrace results in the first place...but it seems I can't even trust the debugging tools. (To say nothing of Microsoft Windows XP itself!) I guess that means I'll have to get more creative in testing.

[CommonSenseOTB]

It's Obj C code not JS and == in Obj C is equivalent comparator to === in JS. Obj C doesn't have an equivalent 'fuzzy equals' that == is in JS.

This is probably a stupid thought but what would happen if you substituted "===" in place of the "==" in the above sections of code?

It wouldn't compile because "===" is not a valid Objective-C operation.

We're talking about the actual game code here, not about OXP Javascript.

Ninja'd!

Thankyou Capt. Murphy and Micha.