Too many crashes (1.72.2 PC)

Screet · Post by **Screet** » Mon Jan 19, 2009 4:41 am

Hi,

I really did wait quite some time, but neither did the problem dissolve nor did I get any hints yet as to what causes it.

Previously, the game crashed, typically after witchspace and very rarely when docking. It almost never crashed in-flight.

Since 1.72.2 I do have massive problems with crashes in flight! Furthermore, the crashes when jumping even appear at the first jump, while it usually took several jumps before.

Sadly, the log does not reveal anything.

Am I the only one with such an increase of problems? Concerning the in-flight crashes, I got the impression it /could/ have to do with the ID system, but I'm not sure and I really use that a lot. In heated up situations, the last image often was that where I should have gotten a new target.

Is anyone else experiencing that problem?

Is there any way to get more info from the log without blowing it up to an unreadable amount?

Screet

Post by **another_commander** » Mon Jan 19, 2009 7:23 am

Try looking if there is anything in the stderr.txt, inside oolite.app. As a blind shot, try to replace the new libpng with the old one (the one that was generating texture issues) or the one that Solas had linked to or the non-MMX one I had sent you some time ago and see if that helps, although I doubt this would be the problem.

However, it is perplexing that you were getting "typically" crashes even before, it's been since the days of v1.70 that we last had a crash report on docking or on hyperspace.

Svengali · Post by **Svengali** » Mon Jan 19, 2009 10:52 am

It seems to be related to RS (and maybe other oxps that have too much ships in it). I've spent the last days with the same problem to test the new Localhero with these oxps and to protect the missions in Localhero from getting unplayable, because too much ships with sometimes weird behaviours will be added that can/will attack and destroy mission ships.

I'm using now a 'guard' for this case, but it's not a general solution and only active if a mission is running. But this is not the way I like.

A better way would be to get a 'gentleman agreement' how to handle this situation. So I'll suggest a possible solution in the next days and have already a test oxp for this case. When the script is finalized I'll drop it in and we can discuss it.

Screet · Post by **Screet** » Mon Jan 19, 2009 1:58 pm

another_commander wrote:
Try looking if there is anything in the stderr.txt, inside oolite.app. As a blind shot, try to replace the new libpng with the old one (the one that was generating texture issues) or the one that Solas had linked to or the non-MMX one I had sent you some time ago and see if that helps, although I doubt this would be the problem.

However, it is perplexing that you were getting "typically" crashes even before, it's been since the days of v1.70 that we last had a crash report on docking or on hyperspace.

The previous crashes seem to be linked to memory usage of >1gb (still enough free, but vista thinks different).

The new ones are strange, because they are in-flight.

Concerning the lib, I can do so, I had the alternative dll in because of the texture problem and things were good. I also did test two of the new libs for the current test release without any problems. I can try, but I guess this is from somewhere else.

Svengalis idea with the sheer amount of ships...I could imagine that, however I did have RS in a long time and that problem is new with this version. I switched to the RS successor few days ago, though. It appears not to have changed the problem.

Screet

Svengali · Post by **Svengali** » Mon Jan 19, 2009 2:25 pm

Screet wrote:
Svengalis idea with the sheer amount of ships...I could imagine that, however I did have RS in a long time and that problem is new with this version. I switched to the RS successor few days ago, though. It appears not to have changed the problem.

Try to disable the script.plist in RS (or successor) and try again. This reduces the memory usage a lot and solves a lot of problems.

Post by **Eric Walch** » Tue Jan 20, 2009 4:52 pm

another_commander wrote:
THowever, it is perplexing that you were getting "typically" crashes even before, it's been since the days of v1.70 that we last had a crash report on docking or on hyperspace.

I just had a crash while I was on auto dock: second crash log. But two days ago I also had a crash. But than it was an NPC shop docking when I remember well. (upper crash log). I have never seen crashes with this info in the past.

Code: Select all

Date/Time:      2009-01-18 21:44:48.474 +0100
OS Version:     10.4.11 (Build 8S165)
Report Version: 4
Command: Oolite
Path:    /Applications/Games/Oolite/Oolite1.72.2.app/Contents/MacOS/Oolite
Parent:  WindowServer [64]

Version: Oolite version 1.72.2 (1.72.2)

PID:    330
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x0000002f

Thread 0 Crashed:
0   libobjc.A.dylib                	0x90a410f8 objc_msgSend + 24
1   org.aegidian.oolite            	0x00096434 -[ShipEntity enterDock:] + 48 (crt.c:355)
2   org.aegidian.oolite            	0x000c1f88 -[StationEntity shipIsInDockingCorridor:] + 1516 (crt.c:355)
3   org.aegidian.oolite            	0x000453fc -[CollisionRegion findCollisions] + 1084 (crt.c:355)
4   org.aegidian.oolite            	0x00024fd4 -[Universe findCollisionsAndShadows] + 108 (crt.c:355)
5   org.aegidian.oolite            	0x00038458 -[Universe update:] + 2424 (crt.c:355)
6   org.aegidian.oolite            	0x0000e97c -[GameController doPerformGameTick] + 136 (crt.c:355)
7   com.apple.Foundation           	0x92be8e88 __NSFireTimer + 116
8   com.apple.CoreFoundation       	0x907f2390 __CFRunLoopDoTimer + 184
9   com.apple.CoreFoundation       	0x907ded08 __CFRunLoopRun + 1680
10  com.apple.CoreFoundation       	0x907de2bc CFRunLoopRunSpecific + 268
11  com.apple.HIToolbox            	0x9329db20 RunCurrentEventLoopInMode + 264
12  com.apple.HIToolbox            	0x9329d1b4 ReceiveNextEventCommon + 380
13  com.apple.HIToolbox            	0x9329d020 BlockUntilNextEventMatchingListInMode + 96
14  com.apple.AppKit               	0x937a2bc4 _DPSNextEvent + 384
15  com.apple.AppKit               	0x937a2888 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116
16  com.apple.AppKit               	0x9379edcc -[NSApplication run] + 472
17  com.apple.AppKit               	0x9388f974 NSApplicationMain + 452
18  org.aegidian.oolite            	0x00002194 _start + 340 (crt.c:272)
19  org.aegidian.oolite            	0x0000203c start + 60

Next happened with docking computer on:

Code: Select all

Date/Time:      2009-01-20 17:42:11.166 +0100
OS Version:     10.4.11 (Build 8S165)
Report Version: 4
Version: Oolite version 1.72.2 (1.72.2)

PID:    397
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000005

Thread 0 Crashed:
0   libobjc.A.dylib                	0x90a41120 objc_msgSend + 64
1   org.aegidian.oolite            	0x000c3a5c -[StationEntity dockingInstructionsForShip:] + 2308 (crt.c:355)
2   org.aegidian.oolite            	0x0006f3bc -[ShipEntity(AI) requestDockingCoordinates] + 212 (crt.c:355)
3   org.aegidian.oolite            	0x00009cc8 -[AI takeAction:] + 420 (crt.c:355)
4   org.aegidian.oolite            	0x00009a68 -[AI reactToMessage:] + 544 (crt.c:355)
5   org.aegidian.oolite            	0x00009f54 -[AI think] + 216 (crt.c:355)
6   org.aegidian.oolite            	0x000383e0 -[Universe update:] + 2304 (crt.c:355)
7   org.aegidian.oolite            	0x0000e97c -[GameController doPerformGameTick] + 136 (crt.c:355)
8   org.aegidian.oolite            	0x0000e1f8 -[GameController goFullscreen:] + 1628 (crt.c:355)
9   com.apple.AppKit               	0x93843d44 -[NSApplication sendAction:to:from:] + 108
10  com.apple.AppKit               	0x9389e5b0 -[NSMenu performActionForItemAtIndex:] + 392
11  com.apple.AppKit               	0x9389e334 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 104
12  com.apple.AppKit               	0x9389dddc -[NSMenu performKeyEquivalent:] + 272
13  com.apple.AppKit               	0x9389da28 -[NSApplication _handleKeyEquivalent:] + 328
14  com.apple.AppKit               	0x937a74e8 -[NSApplication sendEvent:] + 2944
15  org.aegidian.oolite            	0x0003a534 -[OoliteApp sendEvent:] + 188 (crt.c:355)
16  com.apple.AppKit               	0x9379edf0 -[NSApplication run] + 508
17  com.apple.AppKit               	0x9388f974 NSApplicationMain + 452
18  org.aegidian.oolite            	0x00002194 _start + 340 (crt.c:272)
19  org.aegidian.oolite            	0x0000203c start + 60

JensAyton · Post by **JensAyton** » Tue Jan 20, 2009 7:23 pm

Looks like a memory management problem with docking instructions.

Screet · Post by **Screet** » Tue Jan 20, 2009 7:26 pm

Ahruman wrote:
Looks like a memory management problem with docking instructions.

Then this might be similar to my PC problems with the current test release!

I just had a crash <60s after launching the game: Virtual memory exhausted. I've got 4 gigs, of which 3 can be used, Vista screams as soon as this (or any other program) uses more than a gig, because then it's system cache has to drop below 2 gigabytes and the system asks the user to close the programs because there would not be enough memory.

With these early crashes, I never got such a low mem warning, yet, stderr says that oolite had virtual memory exhausted.

Screet

JensAyton · Post by **JensAyton** » Tue Jan 20, 2009 7:28 pm

Screet wrote:
hen this might be similar to my PC problems with the current test release!

I just had a crash <60s after launching the game: Virtual memory exhausted.

No, Eric’s problem is the exact opposite of yours: memory being released when it’s actually still in use.

The docking instructions code all looks fine, though. Bah.

Lestradae · Post by **Lestradae** » Tue Jan 20, 2009 7:46 pm

I'm having a lot of crashes recently, since the release of 1.72.2.

The error log tells me it's out of virtual memory if it tells me anything. Either the game is suddenly extremely slow and then the crash, or it crashes upon docking.

I was originally thinking it was something in my OSE WiP, but as many different people also without OSE WiP (which just 8 people happen to have atm) are experiencing similar crashes, perhaps it's something in the new version that has to do with docking, player or NPC?

I stopped playing for the time being, it looks to me like it could be some sort of memory loop again?

EDIT: Two relevant infos. First, if I test-play with the OSE WiP as only oxp, no crash.

Second, could it be that you changed some sort of command which is executed at docking, and doesn't work any more or differently, but is in diverse older oxps and produces crashes when executed on a player or even sometimes NPC ship? (completely into-the-blue-guess, that)

Post by **Eric Walch** » Tue Jan 20, 2009 10:30 pm

I added today a ship in my list with a wrong shader definition. Others have reported crashes after adding this ship. So my second crash log could be related to that, but the first not as it is two days older. Ill see if it re-occurs without the wrong ship.

I remember the crash occurring while on auto pilot and I had shortly before activated the target inspector on the player and logged the dockingAI as the ship seemed to do nothing. The docking procedure brought him completely in front of the buoy and than my ship stayed inactive.

Post by **another_commander** » Wed Jan 21, 2009 7:15 am

@Lestradae: I think your assessment of other people without OSE experiencing similar crashes is incorrect. Can you please point me to the exact threads where this has been reported by others? It seems to me that only Screet and yourself are experiencing similar crashes with memory exhaustion. If you are indeed not getting any problems with just OSE installed, then please start putting back your other OXPs one by one and try to pinpoint which one is causing the crashes.

Ark · Post by **Ark** » Wed Jan 21, 2009 7:52 am

That is very odd!!!
The last in flight and during docking crash I had was in 1.69 and the last crash during a load or a hyperspace jump was in 1.70 (due to the populator bug with the hunters). It would be wise for all of you that have those crashes to always play with shift-f open and to report the numbers of objects and collisions during the crash.

That way the dev team would be able to determine if that “virtual memory exhausted” message has to do with an insane overpopulation (like we had in the past) or something else (an endless loop or something). It is not much but at least is a start.

Also remove for the time being the realistic shipyard oxp.

Post by **Eric Walch** » Wed Jan 21, 2009 8:52 am

One crash is still very persistent on my mac. I reported this elsewhere. When converting certain properties to a string I always get a crash. eg. ship.mass, .distanceTo. And several other properties. It happens when I explicitly convert them to string with string(), or when those numbers are written to the log, in which case oolite is converting them to strings. In buoy repair I had to remove distance logging to prevent crashes, since starting with 1.72. Currently I bypass these crashes by using Math.round(this.ship.mass). The bug seems very platform or hardware specific but the source is converting some, probably corrupted, numbers to strings.

Lestradae · Post by **Lestradae** » Wed Jan 21, 2009 8:54 am

Ark wrote:
Also remove for the time being the realistic shipyard oxp.

Erm - nope, you're wrong here.

That Realistic Shipyards (at least V3.02b) does not produce these crashes is assured.

It could be that OSE - the Realistic Shipyards successor WiP, which only about eight people, including Screet, have atm - has to do with the crashes.

I want to make that point clear so that the 1.5 thousand RS players are not unnescessarily disconcerted. And OSE will only be published if and when after possible problems have been ironed out, which is why some people beta-test each of the current WiP versions.

Cheers

L