NSRunLoop exiting too soon -- FIXED by upgrading GNUstep

[Y A J]

Hi,

I have run into an odd problem which doesn't seem to have been reported before: when I start Oolite, I get a splash screen and then a very very brief title screen, and immediately after that appears, Oolite exits with status 0.

A little bit of source hunting revealed that the main NSRunLoop iterates only once and then returns: performGameTick is invoked exactly once.

I can work around the problem by patching GameController.m to execute run indefinitely:

Code: Select all

    
    for(;;)
        [[NSRunLoop currentRunLoop] run];

but I don't understand why this is a problem for me and (apparently) nobody else. (After each iteration, timer is still valid and still has the correct interval, so it's not a case of the timer becoming invalid and being removed from the loop. I can't think of other possibilities to investigate right now.) The same thing happens under versions 1.65, 1.73.4, and SVN trunk.

This is running on GNUstep 1.19.1. The kernel is Linux 2.6.31, architecture is x86-64, compiler is gcc 4.3.3, libGL is Mesa 7.5.1, libffi is version 3.0.1, libc is glibc 2.9, I'm right handed, and the moon is waxing gibbous.

Thanks very much!

- Yet Another Jameson

[Kaks]

And what distro would that be? & How much memory?

That aside, I've got the horrible feeling that your compiler might be too recent/untested by any of the dev team...

Instead of compiling, have you tried installing the autopackage? And if so, with what results?

[Y A J]

And what distro would that be? & How much memory?

Hi, Kaks! The distribution is slackware-current (64 bit), and 2 GB memory.

That aside, I've got the horrible feeling that your compiler might be too recent/untested by any of the dev team...

Good point... if I get sufficiently energetic, I might try installing an older version and giving that a try. And also an older GNUstep, which I suspect might be the culprit.

Instead of compiling, have you tried installing the autopackage? And if so, with what results?

No, I haven't... I read somewhere there was no 64-bit autopackage available.

Thanks for the help!

- Yet Another Jameson

[Kaks]

Well, not much of a help. Getafix is the resident autopackage wizard, hopefully he'll pop around soon!

Oh, and welcome to the boards!

[Micha]

No there isn't yet, although I think the autopackage system now supports 64-bit. Time to try building one I suppose.

You can try using 'alien' to import the 64-bit jaunty debian package. However, that will just use the libraries on your system so if the new gnustep-base is to blame, that won't fix it.

[JensAyton]

This is running on GNUstep 1.19.1.

It’s possible this is your issue. 1.19.1 is an out-of-date development release. The current stable is 1.18.0 and the current unstable is 1.19.3.

[Y A J]

Thanks, folks. It does sound like trying different GNUstep versions is worth a try.

The only thing is... the workaround I mentioned is enough to get the game to run, and, wow... this has got to be right up there with the best games of the past 25 years. I suppose I could save my commander and stop the game and mess around with library versions and diagnose this bug, but -- if you'll excuse me, I need a couple more milkruns to afford a military laser, and then I've got a rating in desperate need of improvement. If I track down the NSRunLoop thing I'll certainly let you know, but don't stay up...

- Yet Another Jameson

[Getafix]

No, I haven't... I read somewhere there was no 64-bit autopackage available.

No there isn't yet, although I think the autopackage system now supports 64-bit. Time to try building one I suppose.

Well, it has just become available from GURPO.

Cheers.

[Y A J]

This is running on GNUstep 1.19.1.

It’s possible this is your issue. 1.19.1 is an out-of-date development release. The current stable is 1.18.0 and the current unstable is 1.19.3.

Thanks, Ahruman! You were exactly right. Upgrading to 1.19.3 fixed the problem.

(Another happy side effect of the upgrade is that it fixed a nasty GNUstep memory leak somewhere... under 1.19.1, I was leaking about 40 MB per second when viewing the short range galactic chart, since that screen does a generateSystemData every single frame on every system within range, and a library was losing a bunch of memory each time. I had been digging through the Oolite code for a while trying to spot the leak, but it turns out Oolite was innocent!)

Thanks again,
- Yet Another Jameson