Regular crashes are back with 1.73.4 :(

[Thargoid]

As I said, on XP I routinely get those derelict log errors during my testing without nuking my ooniverse (v1.73.4). So I'm wondering why Screet gets the problem he does, do we perhaps have an interaction with something else but triggered by FC, or is it something in Vista?

[Kaks]

Well, there's this OXP that was created to test some odd timer related issues I kept having with 1.73.
If Screet's computer crashes when he leaves the station instead of writing stuff to the log, it might well mean that 'my' bug is affecting him too.

[JensAyton]

I don’t have a problem with toString(), but in verifying this I found that the constructor can crash if you give it bad arguments. Here’s a fixed implementation, since BerliOS is still down (OOJSTimer.m:315):

Code: Select all

// new Timer(this : Object, function : Function, delay : Number [, interval : Number]) : Timer
static JSBool TimerConstruct(JSContext *context, JSObject *inThis, uintN argc, jsval *argv, jsval *outResult)
{
	JSObject				*this = NULL;
	jsval					function = JSVAL_VOID;
	double					delay;
	double					interval = -1.0;
	OOJSTimer				*timer = nil;
	
	if (argc < 3)
	{
		OOReportJSBadArguments(context, nil, @"Timer", argc, argv, @"Invalid arguments in constructor", @"(object, function, number [, number])");
		return NO;
	}
	
	if (!JSVAL_IS_NULL(argv[0]) && !JSVAL_IS_VOID(argv[0]))
	{
		if (!JS_ValueToObject(context, argv[0], &this))
		{
			OOReportJSBadArguments(context, nil, @"Timer", 1, argv, @"Invalid argument in constructor", @"object");
			return NO;
		}
	}
	
	function = argv[1];
	if (!JS_ObjectIsFunction(context, JSVAL_TO_OBJECT(function)))
	{
		OOReportJSBadArguments(context, nil, @"Timer", 1, argv + 1, @"Invalid argument in constructor", @"function");
		return NO;
	}
	
	if (!JS_ValueToNumber(context, argv[2], &delay) || isnan(delay))
	{
		OOReportJSBadArguments(context, nil, @"Timer", 1, argv + 2, @"Invalid argument in constructor", @"number");
		return NO;
	}
	
	// Fourth argument is optional.
	if (3 < argc && !JS_ValueToNumber(context, argv[3], &interval))  interval = -1;
	
	// Ensure interval is not too small.
	if (0.0 < interval && interval < kMinInterval)  interval = kMinInterval;
	
	timer = [[OOJSTimer alloc] initWithDelay:delay
									interval:interval
									function:function
										this:this];
	*outResult = [timer javaScriptValueInContext:context];
	if (delay >= 0)	// Leave in stopped state if delay is negative
	{
		[timer scheduleTimer];
	}
	[timer release];	// The JS object retains the ObjC object.
	
	return YES;
}

[Screet]

As I said, on XP I routinely get those derelict log errors during my testing without nuking my ooniverse (v1.73.4). So I'm wondering why Screet gets the problem he does, do we perhaps have an interaction with something else but triggered by FC, or is it something in Vista?

I'm not sure...however, I did now encounter proper ships. Moving the log for the timer into the if clause solved the problem: No more crashes and proper logging when there's a real derelict

NOT A SINGLE CRASH FOR SEVERAL HOURS!!!

Can you imagine how happy I am?

Screet

[Screet]

Well, there's this OXP that was created to test some odd timer related issues I kept having with 1.73.
If Screet's computer crashes when he leaves the station instead of writing stuff to the log, it might well mean that 'my' bug is affecting him too.

KABOOM!

with Vista64 on a Phenom QuadCore

No log/stderr info, the app simply does close. Vista does not detect that the app did crash.

Screet

[Lestradae]

Moving the log for the timer into the if clause solved the problem: No more crashes and proper logging when there's a real derelict

Screet, I would be very interested as to how exactly you reformulated the two lines in frame's fuel collector script, as I would like to use the non-crashy version you discovered, too.

I did outcomment the second line the way Kaks suggested (and I am happy to report that - still no crashes - they're well & truly gone ) but I assume that simply removing that line takes away functionality?

Can you post your solution?

Cheers

L

[Screet]

Screet, I would be very interested as to how exactly you reformulated the two lines in frame's fuel collector script, as I would like to use the non-crashy version you discovered, too.

Removing the log line does not remove functionality - it only reduces the possibility to track other problems with the timer. This version works by securing against the crash and still keeping the logging for situations which do use the timer:

Code: Select all

                                           if(this.theplayer.position.distanceTo(pl_target) < 301)
                                            {
                                                    log("Fuel Collector", "distance below 301")
													let isRunning = false
                                                    if(this.DerelictCheckTimer)
                                                    {
														log("Fuel Collector", "this.DerelictCheckTimer is " + this.DerelictCheckTimer)

Screet

[Kaks]

KABOOM!

Yes!! I knew I wasn't seeing things that time... The bad news is that there is no known cure for that problem yet, apart from rebuilding your system from scratch.

And Lestradae, while repositioning the log line works, commenting it out (as I said a few posts ago) also stops Screet's computer from crashing.

As a matter of fact, both log lines ( 'distance below 301' and 'this.DerelictCheckTimer is' ) are not needed by the fuel extractor script itself. To my 'untrained' eye, it looks very much like these two lines were used by Frame to see what was happening inside the script as he was developing it.
Ironically, had Frame removed both of them before releasing fuel extractor .6, no crashes would have happened.

[JensAyton]

Kaks: just to be clear, does that still crash for you in trunk?

[Screet]

Kaks: just to be clear, does that still crash for you in trunk?

For me it does...

Rebuild the complete system? Are you talking about my OS? ARGH! NO WAY!

Screet

[Kaks]

Kaks: just to be clear, does that still crash for you in trunk?

Well, to be as clear as mud, yes and no!

Explanation: I had those crashes on my dev computer, an XP sp3 system which has been limping along for the last 3 months or so. Among all the stuff loaded in there, I have visual studio express, sql server express, mysql, apache, php5 & of course GNUstep.

I've now got a partition with a fresh install of xp sp3 on drive E:, but I kept the older xp installation in its own partition (appearing as drive C:, rather boringly, from both the old and new xp installations).

If I run the same oolite executable, with exactly the same dlls, etc ( and I do mean the very same one, not a copy - C:\GNUstep\Local\oolite\trunk\oolite.app , which points at the very same directory from both installations), I get different results depending on which xp installation is active at the time.

From the old xp installation, the test oxp crashes Oolite trunk 3 seconds after launching from the station.

Using the new xp installation, Oolite just writes happily to the log, without any crash whatsoever.

I still regularly compile using the old xp installation, since I haven't got round to tweaking the dev environment on the new partition the exact way I want it.
Of course, trunk compiled from the old XP doesn't crash at all if ran from the new XP installation!

Rebuild the complete system? Are you talking about my OS? ARGH! NO WAY!

Well, it did work for me, and from what you have been saying, your OS sounds pretty flakey anyway, what with its random Blue Screens Of Death. Oolite crashing might be just another warning sign - kind of a gentle reminder that your computer does need a spring clean...

I did puzzle about it for a couple of weeks, but I really can't find a specific reason why my knackered XP installation crashes Oolite in some circumstances.
Screet, if you manage to find out & correct the underlying cause of this weird problem (all I can think of is 'microsoft'...) you'll have my eternal gratitude. Well, at least for a month or so!

[pmw57]

Screet, if you manage to find out & correct the underlying cause of this weird problem(all I can think of is 'microsoft'...) you'll have my eternal gratitude. Well, at least for a month or so!

A month of eternal gratitudinalnessness? Who's to argue about that!

Is there anything that other microshaft users with an unstable system can do to help if they want to be of assistance?

[Diziet Sma]

Is there anything that other microshaft users with an unstable system can do to help if they want to be of assistance?

Download Ubuntu (or better yet, SuperOS), burn it to cd.. type format C:\ at a command prompt, then boot the cd and install Linux

[Kaks]

Is there anything that other microshaft users with an unstable system can do to help if they want to be of assistance?

Download Ubuntu (or better yet, SuperOS), burn it to cd.. type format C:\ at a command prompt, then boot the cd and install Linux

Aye, and wine is your friend! If it wasn't for how slooow Eclipse can be, and how many people are using windoze, I wouldn't give it a second thought!

[Screet]

Download Ubuntu (or better yet, SuperOS), burn it to cd.. type format C:\ at a command prompt, then boot the cd and install Linux

NO! The wine using tester of my program always has trouble - he's losing his connection and reconnecting does, unlike under windows, not work! NO!

Screet