Crash on entering system

Post by **Eric Walch** » Wed Aug 05, 2009 5:04 pm

It is long ago I had crashes but yesterday 2 and today again. Always the same crashlog so I assume this it is caused by a recent change in the trunk:

Code: Select all

Date/Time:       2009-08-05 18:49:47.306 +0200
OS Version:      Mac OS X 10.5.7 (9J61)
Report Version:  6
Anonymous UUID:  8F0E24B1-5FC1-4401-846B-F94A6FDA55B9

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000026874540
Crashed Thread:  0

Application Specific Information:
[bigShips_populator] OOJSGlobal.m:197: 2 big trader(s) added to the Tivere system.


Thread 0 Crashed:
0   libGLImage.dylib              	0x966f8850 void glgConvertTo_32<GLGConverter_RGBA8_ARGB8, (GLGMemory)2>(GLGOperation const*, GLDPixelMode const*) + 608
1   libGLImage.dylib              	0x966d2f8f glgProcessPixelsWithProcessor + 1359
2   com.apple.GeForce8xxxGLDriver 	0x14841c2d gldAllocVertexBuffer + 24733
3   com.apple.GeForce8xxxGLDriver 	0x14823181 gldDestroyQuery + 2673
4   com.apple.GeForce8xxxGLDriver 	0x14844fe8 gldGetTextureLevel + 10296
5   com.apple.GeForce8xxxGLDriver 	0x14836927 gldUpdateDispatch + 487
6   GLEngine                      	0x146aefdb gleSetupAndDrawArraysOrElementsOutOfLine_ListExec + 2331
7   GLEngine                      	0x146aa1bc gleCallList + 188
8   libGL.dylib                   	0x91ce6a3b glCallList + 27
9   org.aegidian.oolite           	0x0010d78f -[PlanetEntity drawEntity::] + 1460 (PlanetEntity.m:1152)
10  org.aegidian.oolite           	0x0010de03 -[PlanetEntity drawEntity::] + 3112 (PlanetEntity.m:1268)
11  org.aegidian.oolite           	0x00045a44 -[Universe drawUniverse] + 5002 (Universe.m:3688)
12  org.aegidian.oolite           	0x0005c185 -[MyOpenGLView drawRect:] + 386 (MyOpenGLView.m:204)
13  com.apple.AppKit              	0x9010c22c -[NSView _drawRect:clip:] + 3853
14  com.apple.AppKit              	0x9010ad23 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1050
15  com.apple.AppKit              	0x90109679 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 759
16  com.apple.AppKit              	0x90105adf -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 3090
17  com.apple.AppKit              	0x900464b3 -[NSView displayIfNeeded] + 933
18  org.aegidian.oolite           	0x000134b2 -[GameController doPerformGameTick] + 335 (GameController.m:325)
19  org.aegidian.oolite           	0x0001335d -[GameController performGameTick:] + 42 (GameController.m:284)

I have system redux installed, used the latest trunk version and am entering the Tivere system. Seen the log I suspect it has to do with planet drawing.

Post by **Eric Walch** » Thu Aug 06, 2009 8:02 pm

I just had a new crash. This time I was docked and wanted to look at the F7 screen. The screen was drawn but the planet picture was missing for a few seconds. Than oolite crashed with the following log:

Code: Select all

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000002980d540
Crashed Thread:  0

Application Specific Information:
[texture.planet.generate] TextureStore.m:146: genning texture for land_fraction 0.51000


Thread 0 Crashed:
0   libGLImage.dylib              	0x966f8850 void glgConvertTo_32<GLGConverter_RGBA8_ARGB8, (GLGMemory)2>(GLGOperation const*, GLDPixelMode const*) + 608
1   libGLImage.dylib              	0x966d2f8f glgProcessPixelsWithProcessor + 1359
2   com.apple.GeForce8xxxGLDriver 	0x14841c2d gldAllocVertexBuffer + 24733
3   com.apple.GeForce8xxxGLDriver 	0x14823181 gldDestroyQuery + 2673
4   com.apple.GeForce8xxxGLDriver 	0x14844fe8 gldGetTextureLevel + 10296
5   com.apple.GeForce8xxxGLDriver 	0x14836927 gldUpdateDispatch + 487
6   GLEngine                      	0x146aefdb gleSetupAndDrawArraysOrElementsOutOfLine_ListExec + 2331
7   GLEngine                      	0x146aa1bc gleCallList + 188
8   libGL.dylib                   	0x91ce6a3b glCallList + 27
9   org.aegidian.oolite           	0x0010d5df -[PlanetEntity drawEntity::] + 1460 (PlanetEntity.m:1152)
10  org.aegidian.oolite           	0x00045944 -[Universe drawUniverse] + 5002 (Universe.m:3688)
11  org.aegidian.oolite           	0x0005c085 -[MyOpenGLView drawRect:] + 386 (MyOpenGLView.m:204)
12  com.apple.AppKit              	0x9010c22c -[NSView _drawRect:clip:] + 3853
13  com.apple.AppKit              	0x9010ad23 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1050
14  com.apple.AppKit              	0x90109679 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 759
15  com.apple.AppKit              	0x90105adf -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 3090
16  com.apple.AppKit              	0x900464b3 -[NSView displayIfNeeded] + 933
17  org.aegidian.oolite           	0x000133b2 -[GameController doPerformGameTick] + 335 (GameController.m:325)
18  org.aegidian.oolite           	0x0001325d -[GameController performGameTick:] + 42 (GameController.m:284)

Lestradae · Post by **Lestradae** » Thu Aug 06, 2009 8:37 pm

I have absolutely no idea if it's related - but since the beginning of 2009 I have had crashes to desktop either when exiting witchspace or when docking at a station. It took me some time to find out that it always happened after three to four witchjumps + station dockings.

It never happened inbetween, never at launch, it happens with less oxps slower (more than the three to four ratio) and with more oxps faster.

There is never anything of importance in the log about the crash.

When I save game, quit, and restart, at the point where the crash would have come the game continues without a problem.

After crashing my system is rather sluggish for half a minute or so, and if I let the Vista task manager run it shows me a pattern of rising RAM usage that doesn't go down to where it was again - after coming out of witchjumps and/or docking!

So I concluded (and Katharsis, friend of mine who is a programmer, did so too) that there must be some info that Oolite doesn't need any more but doesn't completely discard after a jump or docking, thereby leading to an out-of-memory crash after three or four such actions.

Immediately before a crash happens I sometimes have the transparent planet bug appearing. Not only no texture, but the planet gets look-through suddenly. That got me the idea it could actually be related with what you describe, if it has to do with drawing of planets (at least partially).

As I said, no idea if your and my crashes really are in any way related, perhaps my report helps?!

Hope you find the bugger

L

Cmdr Wyvern · Post by **Cmdr Wyvern** » Thu Aug 06, 2009 9:52 pm

I had two sudden, completely random crashes while playing with trunk.

The first was just as the jump countdown reached zero.

The second was after I q-bombed a nest of pirates and was watching the pretty fireworks in my rear view.

The only relation I can find between the crashes if that they seem to happen during a long play session of 1 hour or more. L may be on to something, it could be a memory leak.

hmm... It brings back memories of the chronic memory leak crashing pre-1.65 versions suffered.

Post by **Eric Walch** » Fri Aug 07, 2009 12:06 pm

There are probably several situations that still can lead to crashes. One is with wormhole scanner on startup. The other is with repeating timers in shipscripts.

For this one I think it has to do with textured planets as it started at the moment the default value changed from NO to YES in trunk. Before I never had seen oolites own textured planets, only the ones from redux.
On the mac, a crash leaves a crash-log with a back-trace of the last calls the code was executing. This gives at least a clue were to look in case of a crash.

Post by **Kaks** » Fri Aug 07, 2009 12:11 pm

Uh-Oh. Eric, it horribly sounds like these problems started with v2275. I've just had a quick look with svn and:

There have been no changes to planet textures / F7 screen code since the 4th of June (v2195). 2275 doesn't seem to modify related stuff either. Will keep looking. If it's fairly easy to replicate the crash using a saved game, please PM me the savegame, I'll see if I can get the same problems on my mac.

Edit: I've just read your 12:06 post and see what you mean now. Will look into the textured planets code with the mac, and hopefully will find what's causing your crashes. It doesn't seem to cause problems with me, but maybe I didn't playtest long enough. How long do you need to play before Oolite crashes?/Edit

L, it might have something to do with the amount of flashers in OSE, flashers seem to cause many, many interesting problems.

Wyvern, did you have RS or OSE installed?

Post by **Eric Walch** » Fri Aug 07, 2009 12:42 pm

Kaks wrote:
Uh-Oh. Eric, it horribly sounds like these problems started with v2275. I've just had a quick look with svn and:

There have been no changes to planet textures / F7 screen code since the 4th of June (v2195). 2275 doesn't seem to modify related stuff either. Will keep looking. If it's fairly easy to replicate the crash using a saved game, please PM me the savegame, I'll see if I can get the same problems on my mac.

The code might not have changed, but the default changed to YES so before I never had it in use.
I never could replicate. Two of the three times it happened already in the second system after a startup. The third time after one our of being away. No idea if it was the second system like the others. According to the log it bugs in the graphic driver so it also could be an incompatibility with a certain graphic card.

Lestradae · Post by **Lestradae** » Fri Aug 07, 2009 2:32 pm

Kaks wrote:
L, it might have something to do with the amount of flashers in OSE, flashers seem to cause many, many interesting problems.

Then I really hope someone knowledgable will go hunting for the flasher memory bug (?!) at some point at least before the MNSR comes out ...

L

PS: Please?

Cmdr Wyvern · Post by **Cmdr Wyvern** » Fri Aug 07, 2009 5:10 pm

Kaks wrote:
Wyvern, did you have RS or OSE installed?

No. My machine is too old and underspec'd to run it. I can forget OSE, Assassins, and a few other monster, resource-guzzling oxps. The biggest oxp I have installed is Random Hits.

Post by **another_commander** » Fri Aug 07, 2009 7:06 pm

Procedurally textured planets were initially disabled after 1.69 - if I recall correctly - due to reported crashes by Ahruman, which I could never reproduce. I now wonder if you are seeing this same problem now, Eric. If it is a problem related to OpenGL on the Mac, then this could explain why I could never crash it under Windows. It would be interesting to switch procedural textures back to NO and see if there are any more of those crashes. My best guess is that Wyvern's crash cases are completely different to this, though.

Post by **Eric Walch** » Fri Aug 07, 2009 8:15 pm

another_commander wrote:
Procedurally textured planets were initially disabled after 1.69 - if I recall correctly - due to reported crashes by Ahruman, which I could never reproduce. I now wonder if you are seeing this same problem now, Eric. If it is a problem related to OpenGL on the Mac, then this could explain why I could never crash it under Windows. It would be interesting to switch procedural textures back to NO and see if there are any more of those crashes.

That what I was already doing after getting another identical crash. Log is always the same:

Big_ship populator has written its log, meaning the main-planet is already set up and oxp's are now executing their stuff. That means that [PlanetEntity drawEntity::] + 1460 (PlanetEntity.m:1152) refers to planets set of by redux. And it is always the second planet in the log he is crashing over.

Post by **Eric Walch** » Sat Aug 08, 2009 4:44 pm

I have done some more testing. With "procedurally textured planets" on I crash within a few jumps, when off I can't generate the crash. However redux has nothing to do with it. I just tested without:

Code: Select all

Date/Time:       2009-08-08 18:34:20.117 +0200
OS Version:      Mac OS X 10.5.8 (9L30)
Report Version:  6
Anonymous UUID:  8F0E24B1-5FC1-4401-846B-F94A6FDA55B9

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000211a8540
Crashed Thread:  0

Application Specific Information:
[bigShips_populator] OOJSGlobal.m:197: 1 big trader(s) added to the Gerebied system.


Thread 0 Crashed:
0   libGLImage.dylib              	0x9643a850 void glgConvertTo_32<GLGConverter_RGBA8_ARGB8, (GLGMemory)2>(GLGOperation const*, GLDPixelMode const*) + 608
1   libGLImage.dylib              	0x96414f8f glgProcessPixelsWithProcessor + 1359
2   com.apple.GeForce8xxxGLDriver 	0x14842c1d gldAllocVertexBuffer + 24733
3   com.apple.GeForce8xxxGLDriver 	0x14824171 gldDestroyQuery + 2673
4   com.apple.GeForce8xxxGLDriver 	0x14845fd8 gldGetTextureLevel + 10296
5   com.apple.GeForce8xxxGLDriver 	0x14837917 gldUpdateDispatch + 487
6   GLEngine                      	0x146affdb gleSetupAndDrawArraysOrElementsOutOfLine_ListExec + 2331
7   GLEngine                      	0x146ab1bc gleCallList + 188
8   libGL.dylib                   	0x96d0fa3b glCallList + 27
9   org.aegidian.oolite           	0x0010d5df -[PlanetEntity drawEntity::] + 1460 (PlanetEntity.m:1152)
10  org.aegidian.oolite           	0x00045944 -[Universe drawUniverse] + 5002 (Universe.m:3688)
11  org.aegidian.oolite           	0x0005c085 -[MyOpenGLView drawRect:] + 386 (MyOpenGLView.m:204)
12  com.apple.AppKit              	0x9657fbf8 -[NSView _drawRect:clip:] + 3853
13  com.apple.AppKit              	0x9657e6ef -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1050
14  com.apple.AppKit              	0x9657d045 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 759
15  com.apple.AppKit              	0x965794ab -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 3090
16  com.apple.AppKit              	0x964b9e7b -[NSView displayIfNeeded] + 933
17  org.aegidian.oolite           	0x000133b2 -[GameController doPerformGameTick] + 335 (GameController.m:325)
18  org.aegidian.oolite           	0x0001325d -[GameController performGameTick:] + 42 (GameController.m:284)
19  com.apple.Foundation          	0x93f10507 __NSFireTimer + 279

Similar crashlog but now only with one [drawentity] entry like the similar crash from within the F7 screen.
The crash comes when all oxp's have added their stuff and when the planet is drawn. Line 11 is from a mac-only part of the oolite library. So it seems this is a mac-only problem. And when this problem already hangs around since 1.69 I would suggest to turn it only off for the mac and hope it will be fixed before 1.74 for all systems.

Post by **another_commander** » Sat Aug 08, 2009 7:04 pm

In this case, I would recommend switching the default back to NO for all architectures, like we had it up to now and let users decide if they would like to have it switched on.

Post by **Eric Walch** » Sat Aug 08, 2009 9:03 pm

another_commander wrote:
In this case, I would recommend switching the default back to NO for all architectures, like we had it up to now and let users decide if they would like to have it switched on.

Is okay, but put a note in the docs that mac users only switch it on their own risk. I have no idea if every machine is affected.

While trying to hunt above bug, I was mainly occupied with another crashing bug. Yesterday was everything fine, today it was one constant crashing. The course had to be in an old oxp were I made some minor changes yesterday. Nothing else had changed.

At last I fond the reason. I tried to add a "nil" ship. When you write: system.legacy_addShips("dummy", 1) and dummy does not exist you get

Code: Select all

[script.addShips.failed] PlayerEntityLegacyScriptEngine.m:1651: ***** SCRIPT ERROR :in <anonymous actions>, addShips: could not add 1 ships with role "dummy"

as answer, but when you write system.legacy_addShips(this.dummy, 1) and this.dummy is undefined you get

Code: Select all

[system] Exception raised during posting of notification.  Ignored.  exception: '*** -[NSCFString appendString:]: nil argument'  invoked observer method: '*** -[NSTextField textDidEndEditing:]'  observer: 0x19f73520  notification name: 'NSTextDidEndEditingNotification'

as answer in the log. At that moment nothing happens, but about 10 seconds later Oolite crashes with

Code: Select all

Thread 0 Crashed:
0   org.aegidian.oolite           	0x001f96ca JS_Assert + 73 (jsutil.c:63)
1   org.aegidian.oolite           	0x001fc9ac js_GC + 745 (jsgc.c:2886)
2   org.aegidian.oolite           	0x001fadac js_NewGCThing + 204 (jsgc.c:1425)
3   org.aegidian.oolite           	0x0024c5b5 js_NewObject + 255 (jsobj.c:2414)
4   org.aegidian.oolite           	0x001f1ede js_NewArrayObject + 58 (jsarray.c:1852)
5   org.aegidian.oolite           	0x0026ad8f JS_NewArrayObject + 37 (jsapi.c:3065)
6   org.aegidian.oolite           	0x0008b859 JSArrayFromNSArray + 255 (OOJavaScriptEngine.m:680)
7   org.aegidian.oolite           	0x0008b9db JSNewNSArrayValue + 80 (OOJavaScriptEngine.m:708)
8   org.aegidian.oolite           	0x0008cdb9 -[NSArray(OOJavaScriptConversion) javaScriptValueInContext:] + 44 (OOJavaScriptEngine.m:1117)
9   org.aegidian.oolite           	0x0016cd83 SystemFilteredEntities + 428 (OOJSSystem.m:680)
10  org.aegidian.oolite           	0x001b562a js_Invoke + 3304 (jsinterp.c:1375)
11  org.aegidian.oolite           	0x001c6e3f js_Interpret + 65022 (jsinterp.c:3944)
12  org.aegidian.oolite           	0x001b56ff js_Invoke + 3517 (jsinterp.c:1394)
13  org.aegidian.oolite           	0x001b5a9b js_InternalInvoke + 315 (jsinterp.c:1469)
14  org.aegidian.oolite           	0x0026cb35 JS_CallFunction + 70 (jsapi.c:4309)
15  org.aegidian.oolite           	0x0008a816 -[OOJavaScriptEngine callJSFunction:forObject:argc:argv:result:] + 98 (OOJavaScriptEngine.m:313)
16  org.aegidian.oolite           	0x00172f85 -[OOJSTimer timerFired] + 163 (OOJSTimer.m:146)

A very nasty one, also because of the delay. It happens so long after entering the system that you look for the bug elsewhere. And a typo in a variable name is easy made. I think this needs an explicit check in the JS engine to prevent the crash.

Post by **Kaks** » Tue Aug 11, 2009 5:00 pm

another_commander wrote:
In this case, I would recommend switching the default back to NO for all architectures, like we had it up to now and let users decide if they would like to have it switched on.

Ok!

I've got some free time later on & I'll chase the js 'nil' bug too while I'm there.

Hopefully I'll be able to replicate Eric's original problem too, but that'll probably take more than a couple of hours to figure out...

Cheers.