Oolite reliable crash: Timers! SOLVED via Windows-Workaround

[Screet]

Hi,

when a Windows operating system has Data Execution Prevention (DEP, a processor feature of modern processors) enabled, Oolite does regularly crash with timers.

This can be reproduced with the timercrash-test oxp:
1) run Oolite with DEP turned off - it works.
2) run Oolite with DEP turned on - it crashes.

Any ideas beside turning off DEP?

Screet

[Lestradae]

Any ideas beside turning off DEP?

How can I turn on / off the frakkin' DEP (thanks again, Gates, for all the fun) and what would be the consequences if I do?

[Screet]

Any ideas beside turning off DEP?

How can I turn on / off the frakkin' DEP (thanks again, Gates, for all the fun) and what would be the consequences if I do?

It's in the advanced system propertiers (typically accessible via computer, properties, advanced system settings and there the tab for data execution prevention.

It's basically a protection against bugs and malware like viruses. It allows the CPU to detect when it's asked to run data from a program as if it would be program code.

Aside from that, it looks like this is also the (only!) crash source I did get during my recent tests on Vista where I tracked it down to addition of hardpirates by OSE. These ships (also in the common behemoth oxp) do create a ship-script with a timer, just like the crash-test for timers does. Running in gdb I do not get any useful information (hopefully some dev can). It's only reporting one lib in the bt there.

Screet

[Kaks]

Confirmed!

Good thinking about DEP, who'd have thunk it. Most computers don't really need any tweaking in that department.

As to why my DEP was set the way it was on my dev machine, it's a real mystery, though I suspect I must have run a none-too-clever 'security lock down' program at some point in the distant past...

PS: Screet, could you please put - SOLVED at the end of the title? That way, if other people have this problem, it should be easier for them to find this thread!

[Lestradae]

Confirmed! ... PS: Screet, could you please put - SOLVED at the end of the title?

Erm ... me being a bit thick here ... how is it solved now?

Is it solved if I switch off the nice DEP "feature", or does this mean that now that you know what's going on you can alter something in trunk that prevents the timer-related crashes from now on?



L

[Kaks]

If you get a crash with timers you go to DEP as explained by Screet. In there you will see a list of programs you might want to exclude from Data Execution Protection. Oolite should be there, but unticked. If it's not in that list, you add it to the list, using the button that says 'Add...' which cleverly adds a program to this list. Make sure Oolite is ticked, and bob's your uncle: no more timers crashes.

[Lestradae]

Thanks Kaks! My question would be, to be more precise, shouldn't this information be quite of interest for other Windows $&$%&/ users too, perhaps even of a sticky-thread like interest?

If I hadn't followed this (for me) rather esoteric thread, I would have enjoyed the crashing forever ...

Just my 0.2 Cr (or 150€ as we know because of DH)

L

[Screet]

If you get a crash with timers you go to DEP as explained by Screet. In there you will see a list of programs you might want to exclude from Data Execution Protection. Oolite should be there, but unticked. If it's not in that list, you add it to the list, using the button that says 'Add...' which cleverly adds a program to this list. Make sure Oolite is ticked, and bob's your uncle: no more timers crashes.

Yes, even my vista machine seems to have no more problems with nearly 2000 entities shooting at each other

However, I'd really be happy if that underlying problem would be solved, yet I'm not familiar enough with the code to have an idea of how this could be done.

DEP is a nice feature for developers, as this helps to detect when something is being deleted, but still in use. This would not always crash under normal conditions, but has a high risk to do so if the code is being modified and then misleads the developer to think that the newly added code is wrong while it's the old that has the problem.

Screet

[Kaks]

As far as I can tell it's a feature of the underlying libraries that windows doesn't like, and unless they are changed upstream to somehow please windows, there's nothing any oolite developer can do.

Happy to be corrected if I'm wrong...

[Lestradae]

This should really become a sticky for Windows users.

If it is/was the reason for my crashes, it is an extremely annoying thing that nearly galled my enthusiasm for playing this game! Sure I'm not alone with this.

And the DEP is very difficult to find. It's eight menues down. The path is:

Windows-E -> (Windows-E)
Rechtsklick "Computer" -> (Rightclick "Computer")
Eigenschaften -> (No idea)
Erweiterte Systemeinstellungen -> (Advanced System Settings?)
Erweitert -> (No idea)
Leistung (Einstellungen) -> (No Idea)
Datenausführungsverhinderung -> (Data Execution Prevention)
Nicht zu verhindernde Programme eingeben & Computer neu starten (Add Oolite(exe?) and check its checkbox & restart the Computer)

Don't know what it's in english. Oolite is now the only program that is excluded here!

A last question, too: Do I have to activate a checkbox for the Oolite executable file oolite.exe only or do I have to check other files, too?



L

[Screet]

A last question, too: Do I have to activate a checkbox for the Oolite executable file oolite.exe only or do I have to check other files, too?

For me, it seems to be enough to only add Oolite there.

And the DEP is very difficult to find. It's eight menues down. The path is:
Windows-E -> (Windows-E)
Rechtsklick "Computer" -> (Rightclick "Computer")
Eigenschaften -> (Properties)
Erweiterte Systemeinstellungen -> (Advanced System Settings)
Erweitert -> (Advanced)
Leistung (Einstellungen) -> (Performance)
Datenausführungsverhinderung -> (Data Execution Prevention)
Nicht zu verhindernde Programme eingeben & Computer neu starten (Add Oolite(exe?) and check its checkbox & restart the Computer)

Screet

[Kaks]

Computer>Properties> new window called
System Properties
Advanced>Performance settings>new window called
Performance Options
data execution prevention

tick oolite.exe

No other oolite files need to be ticked.

Normally you don't need all that faffing about, though.

Maybe there's a new 'feature' in Vista 64 (and windows 7?) that explicitly turns on this 'extra secure' mode?

[Lestradae]

Maybe there's a new 'feature' in Vista 64 (and windows 7?) that explicitly turns on this 'extra secure' mode?

Sadly, this 'feature' has been around on my system for 2.5 years now, and it's simply Vista32.

Which implies that a lot of people who use oxps with certain timers will experience the mysterious crashes. Most of them, I fear, will stop playing.

For me personally this is solved now, thanks everyone, but I really, really think this should either be solved somehow from the core game side or it should be told to Windows users in a really big sticky or flag that they should disable this for the Oolite.exe!

Cheers

L

[CheeseRedux]

I sadly cannot recall how I first came to turn on the DEP function on my laptop (Running XP Professional). I do remember it being turned off by default though. (Well, okay, not exactly off, but it was on the "only essential programs" setting and I switched it to "everything".)

However, when Oolite first tried to do something the DEP didn't like, I automagically got the dialog box where I could mark off the exception.
I don't remember Oolite crashing, probably just got minimized.

But definitely something that should be pointed out somewhere prominently in the documentation included in the download.

[Screet]

However, when Oolite first tried to do something the DEP didn't like, I automagically got the dialog box where I could mark off the exception.

Yes, I know that box - the strange thing is, that I did not get it for Oolite! Neither on XP32 nor on Vista64...and these OS also did not detect that Oolite crashed, but the program simply did close.

Screet