Oolite reliable crash: Timers! SOLVED via Windows-Workaround

[Kaks]

Well, since DEP is the reason why Oolite crashed, I'd suspect that both XP & Vista do detect when they themselves make the program crash.

One possibility is the usual windoze 'are you sure' annoyance. After seeing that type of message a few billion times, many of us simply go 'yeah, yeah, whatever'... I know I've done that myself in the past, just to go 'noooooh....' 3 milliseconds later.

Messages will be put up to point at this particular problem.

In the meantime: Screet, you've pointed out how serious it could be.
Could you please put - SOLVED as the title of this thread, so people who experience these otherwise mysterious crashes wth 1.73.4 in windows might have a chance to find the solution you found?

[Screet]

Well, since DEP is the reason why Oolite crashed, I'd suspect that both XP & Vista do detect when they themselves make the program crash.

The strange thing is, they usually open an alert box and notify the user, giving the option to disable DEP for that particular program. Somehow, this mechanism does not happen for Oolite (tested with XP32 and Vista64). Instead, Oolite simply closes as if there was no crash.

In the meantime: Screet, you've pointed out how serious it could be.
Could you please put - SOLVED as the title of this thread, so people who experience these otherwise mysterious crashes wth 1.73.4 in windows might have a chance to find the solution you found?

You mean, changing the title of the initial message? Can do that...but I'd really like if someone with access to the devs bug-tracker or todo list would add something there that (if possible) the thing should be fixed in the code. That would not only make things easier for first-time ooliteers, but also can help devs to catch problems in the future, should there arise some.

Screet

[another_commander]

This feature appeared for the first time under Windows XP SP2, but probably defaults to "all programs" in later Windows versions. I have it on my system running XP SP3, but it is by default set to "essential Windows programs and services only". From what I read on MSDN, there are ways to overcome it programmatically, but I am not sure how they would be applied to the Oolite code. I would prefer to have the game code deal with this problem, but for now it may be a good idea to make it a notification in the readme file for Windows.

[pmw57]

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!

This is not a fix, it's a hack, at best a workaround.

A solution is where the screwing around with windows settings is not required.

The solution is achieved by updating the OXPs so that the scripts that start a timer, also stop the timer when the player enters witchspace.

[Screet]

The solution is achieved by updating the OXPs so that the scripts that start a timer, also stop the timer when the player enters witchspace.

As Eric did point out, this would also require new triggers for OXPs as loading a commander does not provide a message to the scripts.

Screet

[Screet]

Hmmm. How about this approach:

Scripts may not use JS timers, but register for receiving timer info from Oolite? Oolite itself should know when an object (and thus it's script) is being removed, thus allowing to make this safe in all conditions.

It could also help since this would only require one general timer within Oolite which calls a method that checks which scripted timer requests should be triggered.

Screet

[pmw57]

As Eric did point out, this would also require new triggers for OXPs as loading a commander does not provide a message to the scripts.

Isn't there an existing workaround for that, where the startUp event contains the init code, with the restart method passing to the startUp event?

http://wiki.alioth.net/index.php/OXP_mi ... ring_on_JS

[Eric Walch]

The solution is achieved by updating the OXPs so that the scripts that start a timer, also stop the timer when the player enters witchspace.

As Eric did point out, this would also require new triggers for OXPs as loading a commander does not provide a message to the scripts.

Screet

That problem will solve itself with 1.74 were scripts are completely restarted when loading a new commander. But I think we are dealing with two different problems.

A) Timers in ship scripts that are active when the script itself is removed. That could crash oolite 1.72 but ahruman changed that into a situation with 1.73 were this timer bug was logged instead of crashing Oolite.

B) A protection feature in some window versions that also leads to crashes when the script that generated the timer is still present.

And now B is discovered we can think about solutions for that.

[drew]

Er... woot! Work's for me as well! OSE wip 0.69 started working too!

Cheers,

Drew.

[Screet]

Er... woot! Work's for me as well! OSE wip 0.69 started working too!

You know that there have been a few bugs found where I did post solutions on that thread and that as of today there's a version 0.7 out? For example, the fuel collector and some RMB missiles have been fixed. The fuel collector was able to crash via attempting to log something and RMB missiles had a potential for AI stack overflow.

Screet

[drew]

Oops. spoke too soon. 1.73.4 seems to run ok, but wip 0.69 OSE does crash it about 50% of the time.

I'll try 0.70.

Other than that, new version now seems stable for me!

Cheers,

Drew.

[JensAyton]

Hmmm. How about this approach:

Scripts may not use JS timers, but register for receiving timer info from Oolite?

That’s what a JS timer is.

I’m not clear on what Oolite is doing to trigger DEP, but the most logical explanation would be that in some circumstances it’s calling an invalid function pointer or a method on a freed object. This requires some serious debugging, by someone who’s familiar with Windows.

[Thargoid]

What's all this vendetta against timers for anyway?

Timers in worldscripts are not a problem in the slightest, and timers in ship-scripts we know the limitation and we code for it using the event for the player jumping.

If js scripts can't use timers, you may as well remove the whole damn thing and go back to legacy.

[Screet]

I’m not clear on what Oolite is doing to trigger DEP, but the most logical explanation would be that in some circumstances it’s calling an invalid function pointer or a method on a freed object. This requires some serious debugging, by someone who’s familiar with Windows.

Yes, both creating a timer without a valid method or creating one and then removing the scripted object (probably removing the script in the process) does seem to cause trouble. Trying to execute code for a deleted object, at least in C++, will cause DEP to trigger.

If Oolite has to handle the timers already...maybe it's just requiring some cleanup when it invalidates the source of the script which created the timer by removing the timer instantly.

Screet