Oolite Bulletins

i see this kind of graphic when i start oolite from my 64bit router (xorg 7 there, xfree 4.3 on my notebook, they don't seem to like glx over network together ...) and when i use the 32bit binary on my notebook with the gnustep libs from 1.55 ....

so the same binary works without this collision boxes else when i use normal libs

nevertheless i will go back to 1.62-2 when i compile it next to stay there then until next update

That screenshot is just what a commander sees if he breaks open a cargo cannister of narcotics to sample the goods, those Isinorian magic mushrooms are well known for this sort of thing.

Yeah, that's the development version showing off the octree derived from the geometry of the ship. Laser<->ship collision detection is not working in the current version as it's in the process of being developed (inch by bloody inch).

For building to test your set-up, use the version at [url]svn://thor.acedragon.co.uk/svn/repos/tags/1.62[/url]

as i said, that very same version with the right gnustep libs i installed in my system just shows of without that octree, it only shows up when i start it per remote display or when i use the gnustep libs provided as depency in the tar.gz ....


another thing i've noticed, is that ceesxe (galaxy 0, tech lvl 15) shows up as tech lvl 14 in the starchart dump

Walker wrote:

another thing i've noticed, is that ceesxe (galaxy 0, tech lvl 15) shows up as tech lvl 14 in the starchart dump

Um, isn't displayed TL the listing in the dump+1? I know that's the case with galaxy numbers...

It's really bogged my system down, I'm running Mandriva 2006, 1.4g athlon, gfx5600, 750mb ram. I have 100% cpu usage most of the time not even running or trying to start oolite. I used the autopackage install. How do I get rid of the install? It's so slow I can watch it draw accross my screen when I minimize a browser window. Menu items from the K button are almost unusable, I can leave the room and come back and see it drawing the menu items to display.

Fixed it, reinstalled the latest Nvidia drivers to the kernel module. GLXgears went from 150 frames to over 3700. Not sure why the autopackage install would have changed any of that.

Wild_Byte wrote:

Fixed it, reinstalled the latest Nvidia drivers to the kernel module. GLXgears went from 150 frames to over 3700. Not sure why the autopackage install would have changed any of that.

It shouldn't have. The installer doesn't touch your X config at all. I'd chalk it up to another random Mandriva gremlin...

Wild_Byte wrote:

Fixed it, reinstalled the latest Nvidia drivers to the kernel module. GLXgears went from 150 frames to over 3700. Not sure why the autopackage install would have changed any of that.

Based on your description, I'd say this was simply an OpenGL issue on your box and unrelated to the runaway memory allocation bug we are experiencing.

OK, I've managed to recreate it now (although it takes a *long* time to happen on my hardware - I've found I can recreate it if I park myself by the navigation beacon and wait... and wait... [...] and about 3 hours later the OOM killer gets it).

When my visitors have gone, I'll make a simple GNUstep object allocation analyser (which will be triggered to write an object dump by thresholds, so I don't have to sit and watch it work).

winston wrote:

I'll make a simple GNUstep object allocation analyser (which will be triggered to write an object dump by thresholds, so I don't have to sit and watch it work).

Sounds pretty elementary to me too...........

Why not buy one on ebay!

I realised that oolite was stuttering again and shoved it into window mode and fired up gdb. This is the result of doing a few rounds of Ctrl-C, bt, cont - there seems to be significant stack recursion through bellf - is this intentional? I don't know if this is useful - I might pull down the latest code and try compiling that up instead to see if it still occurs.

Program received signal SIGINT, Interrupt.
[Switching to Thread -1208195392 (LWP 6617)]
0x00ec3f7e in class_pose_as ()
from /usr/lib//Oolite/oolite-deps/lib/libobjc.so.1
(gdb) bt
#0 0x00ec3f7e in class_pose_as ()
from /usr/lib//Oolite/oolite-deps/lib/libobjc.so.1
#1 0x00ec39c2 in objc_get_class ()
from /usr/lib//Oolite/oolite-deps/lib/libobjc.so.1
#2 0x080c406d in longitudeFromVector ()
#3 0x010d6cd7 in -[NSObject performSelector:] ()
from /usr/lib//Oolite/oolite-deps/lib/libgnustep-base.so.1.11
#4 0x08050c70 in bellf ()
#5 0x080509f4 in bellf ()
#6 0x080507b9 in bellf ()
#7 0x08050cce in bellf ()
#8 0x080509f4 in bellf ()
#9 0x08050f08 in bellf ()
#10 0x081024e6 in fillSquareImageDataWithBlur ()
#11 0x0805a794 in my_glDisable ()
#12 0x0806d0d9 in main ()
(gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
0x00eca355 in objc_msg_lookup ()
from /usr/lib//Oolite/oolite-deps/lib/libobjc.so.1
(gdb) bt
#0 0x00eca355 in objc_msg_lookup ()
from /usr/lib//Oolite/oolite-deps/lib/libobjc.so.1
#1 0x01037c81 in -[GSPlaceholderArray initWithObjects:count:] ()
from /usr/lib//Oolite/oolite-deps/lib/libgnustep-base.so.1.11
#2 0x0106bb05 in -[NSArray initWithArray:] ()
from /usr/lib//Oolite/oolite-deps/lib/libgnustep-base.so.1.11
#3 0x0106a90f in +[NSArray arrayWithArray:] ()
from /usr/lib//Oolite/oolite-deps/lib/libgnustep-base.so.1.11
#4 0x08050928 in bellf ()
#5 0x0805076f in bellf ()
#6 0x08050cce in bellf ()
#7 0x080509f4 in bellf ()
#8 0x080507b9 in bellf ()
#9 0x08050cce in bellf ()
#10 0x080509f4 in bellf ()
#11 0x08050f08 in bellf ()
#12 0x081024e6 in fillSquareImageDataWithBlur ()
#13 0x0805a794 in my_glDisable ()
#14 0x0806d0d9 in main ()
(gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
0x011497d4 in -[GSLazyLock unlock] ()
from /usr/lib//Oolite/oolite-deps/lib/libgnustep-base.so.1.11
(gdb) bt
#0 0x011497d4 in -[GSLazyLock unlock] ()
from /usr/lib//Oolite/oolite-deps/lib/libgnustep-base.so.1.11
#1 0x0107c410 in +[NSCharacterSet _staticSet:length:number:] ()
from /usr/lib//Oolite/oolite-deps/lib/libgnustep-base.so.1.11
#2 0x0107c812 in +[NSCharacterSet whitespaceAndNewlineCharacterSet] ()
from /usr/lib//Oolite/oolite-deps/lib/libgnustep-base.so.1.11
#3 0x080522e0 in bellf ()
#4 0x08050b3b in bellf ()
#5 0x080509f4 in bellf ()
#6 0x080507b9 in bellf ()
#7 0x08050cce in bellf ()
#8 0x080509f4 in bellf ()
#9 0x08050f08 in bellf ()
#10 0x081024e6 in fillSquareImageDataWithBlur ()
#11 0x0805a794 in my_glDisable ()
#12 0x0806d0d9 in main ()
(gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
0x08119d97 in drawWormholeCorona ()
(gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
0x080509b8 in bellf ()
(gdb) bt
#0 0x080509b8 in bellf ()
#1 0x080507b9 in bellf ()
#2 0x08050cce in bellf ()
#3 0x080509f4 in bellf ()
#4 0x08050f08 in bellf ()
#5 0x081024e6 in fillSquareImageDataWithBlur ()
#6 0x0805a794 in my_glDisable ()
#7 0x0806d0d9 in main ()
(gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
0x0105c860 in strCompUsCs ()
from /usr/lib//Oolite/oolite-deps/lib/libgnustep-base.so.1.11
(gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
0x00eca355 in objc_msg_lookup ()
from /usr/lib//Oolite/oolite-deps/lib/libobjc.so.1
(gdb) bt
#0 0x00eca355 in objc_msg_lookup ()
from /usr/lib//Oolite/oolite-deps/lib/libobjc.so.1
#1 0x08052269 in bellf ()
#2 0x08050b3b in bellf ()
#3 0x080509f4 in bellf ()
#4 0x08050f08 in bellf ()
#5 0x081024e6 in fillSquareImageDataWithBlur ()
#6 0x0805a794 in my_glDisable ()
#7 0x0806d0d9 in main ()

I’m not really familiar with gdb, but if that’s supposed to be a call stack something is wildly wrong. bellf() isn’t recursive, for one thing, and fillSquareImageDataWithBlur() is only called once, from -[TextureStore getTextureNameFor:].

indeed bt - backtrace is the command to show the calling stack from the running program or the segfaulted program through the core file


if there is not an usual kind of stack usage in obj-c it should really show what functions called which for the stopped thread

#0 is the uppermost position in which function the program was stopped
#1 calles #0
#2 calles #1 and so on .....

so if there is not a recursion through the constructors (and bellf is not in obj-c but in c) there is something else runnning wild on the stack

i should try to compile a debug version of oolite and do the same .... lets try

to give a better explanation of my effect, first:

my cpu load starts to get 100% from oolite
then drops after a few seconds to normal load
after a few moments cpu load starts to get 100% again

this time i've stopped it in the debugger and this is the source position and backtrace here:
(gdb) list
208 * This avoids using the designated initialiser for performance reasons.
209 */
210 - (id) initWithDictionary: (NSDictionary*)other
211 copyItems: (BOOL)shouldCopy
212 {
213 NSZone *z = GSObjCZone(self);
214 unsigned c = [other count];
215
216 GSIMapInitWithZoneAndCapacity(&map, z, c);
217
(gdb) bt
#0 0x405cdcc7 in -[GSDictionary initWithDictionary:copyItems:] (self=0xc827e28, _cmd=0x4081c678, other=0xc827cb0, shouldCopy=0 '\000') at GSDictionary.m:213
#1 0x4063b8e2 in -[NSDictionary initWithDictionary:] (self=0xc827e28, _cmd=0x4081c738, otherDictionary=0xc827cb0) at NSDictionary.m:491
#2 0x4063b142 in +[NSDictionary dictionaryWithDictionary:] (self=0x4081c5e0, _cmd=0x8175308, otherDictionary=0xc827cb0) at NSZone.h:277
#3 0x080ed204 in instructions (station_id=536, coords={x = -50548.2344, y = 57873.7539, z = 566943.938}, speed=128, range=38, ai_message=0x8175770, comms_message=0x0,
match_rotation=0 '\000') at StationEntity.m:270
#4 0x080ed3d2 in -[StationEntity dockingInstructionsForShip:] (self=0x4c060010, _cmd=0x8170a00, ship=0x55d58010) at StationEntity.m:300
#5 0x080cbd7e in -[ShipEntity(AI) requestDockingCoordinates] (self=0x55d58010, _cmd=0x823c460) at ShipEntity (AI).m:1799
#6 0x40677bbd in -[NSObject performSelector:] (self=0x55d58010, _cmd=0x815d820, aSelector=0x823c460) at NSObject.m:1756
#7 0x08051461 in -[AI takeAction:] (self=0x91f1950, _cmd=0x815d7e8, action=0x8a2e078) at AI.m:307
#8 0x08051168 in -[AI reactToMessage:] (self=0x91f1950, _cmd=0x815d7c0, message=0x815d92c) at AI.m:249
#9 0x08050f2f in -[AI setState:] (self=0x91f1950, _cmd=0x815d7d8, stateName=0xc827510) at AI.m:209
#10 0x0805155c in -[AI takeAction:] (self=0x91f1950, _cmd=0x815d7e8, action=0x8a2cfb0) at AI.m:300
#11 0x08051168 in -[AI reactToMessage:] (self=0x91f1950, _cmd=0x815d7c0, message=0x81757e8) at AI.m:249
#12 0x080516ed in -[AI think] (self=0x91f1950, _cmd=0x81781e8) at AI.m:344
#13 0x0810db08 in -[Universe update:] (self=0x8549e10, _cmd=0x815ff00, delta_t=0.0096470047428738326) at Universe.m:5087
#14 0x0805bd12 in -[GameController doStuff:] (self=0x831e420, _cmd=0x81634e8, sender=0x0) at GameController.m:444
#15 0x0806ebe6 in -[MyOpenGLView pollControls:] (self=0x82e4810, _cmd=0x815fea8, sender=0x98787d0) at MyOpenGLView.m:976
#16 0x40677cd0 in -[NSObject performSelector:withObject:] (self=0x82e4810, _cmd=0x40831458, aSelector=0x815fea8, anObject=0x98787d0) at NSObject.m:1782
#17 0x406c1239 in -[NSTimer fire] (self=0x98787d0, _cmd=0x4082bf80) at NSTimer.m:218
#18 0x406995ac in -[NSRunLoop limitDateForMode:] (self=0x831f3e0, _cmd=0x4082bee0, mode=0x4082c0d8) at NSRunLoop.m:815
#19 0x4069a75f in -[NSRunLoop runMode:beforeDate:] (self=0x831f3e0, _cmd=0x4082c010, mode=0x4082c0d8, date=0x8323e50) at NSRunLoop.m:1107
#20 0x4069a9f8 in -[NSRunLoop runUntilDate:] (self=0x831f3e0, _cmd=0x4082c008, date=0x8323e50) at NSRunLoop.m:1165
#21 0x4069a963 in -[NSRunLoop run] (self=0x831f3e0, _cmd=0x815fed8) at NSRunLoop.m:1148
#22 0x0805bb73 in -[GameController applicationDidFinishLaunching:] (self=0x831e420, _cmd=0x8162af0, notification=0x0) at GameController.m:388
#23 0x0806ce0c in main (argc=1, argv=0xbfffec84) at main.m:55


await a few more post like this from me, when the cpu load gets to 100% also memory decreases, currently i am not yet swapping though, cause of enough ram there, i will post every step now until it starts swapping (sry for spamming, but i believe this could help)