Regular crashes are back with 1.73.4 :(

[pmw57]

PS (Edit): pmw57, I have been having the exact same sort of crash that you describe, too, and have not found any source of it. Not even a hint

There's a hole in the bucket.

After every witchspace jump I've paused the game to note down the memory usage.

690956 - Reesdice
737372 - Erbiti
768772 - Esusti
829512 - Zadies

She's leaking captain!

Edit: These jumps have been in rapid succession. Get fuel and get out, sorta thing.

[Screet]

There's a hole in the bucket.
She's leaking captain!

Recent versions of Oolite always wrote a stderr entry when running out of memory. This doesn't happen for me during the crashes I see. Thus I guess that the memory leak you describe is not the source of these crashes (although it would cause a crash after some jumps).

However, I could also imagine that it's not even leaking, but that it's texture cache in RAM which increases in size because there's a new set of ships around after each jump, thus requiring to load more models without releasing the old ones (as that's not necessary with enough free RAM).

Screet

[pmw57]

There's a hole in the bucket.
She's leaking captain!

Recent versions of Oolite always wrote a stderr entry when running out of memory. This doesn't happen for me during the crashes I see. Thus I guess that the memory leak you describe is not the source of these crashes (although it would cause a crash after some jumps).

However, I could also imagine that it's not even leaking, but that it's texture cache in RAM which increases in size because there's a new set of ships around after each jump, thus requiring to load more models without releasing the old ones (as that's not necessary with enough free RAM).

Screet

That's a relief.

Here is Vista's report about the crash.

Log Name: Application
Source: Application Error
Date: 29/09/2009 8:38:30 p.m.
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Paul-PC
Description:
Faulting application oolite.exe, version 0.0.0.0, time stamp 0x4ab8fd7c, faulting module objc-1.dll, version 0.0.0.0, time stamp 0x490b5e03, exception code 0x40000015, fault offset 0x00007383, process id 0x1a90, application start time 0x01ca40bcd4ed6f00.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2009-09-29T07:38:30.000Z" />
<EventRecordID>10711</EventRecordID>
<Channel>Application</Channel>
<Computer>Paul-PC</Computer>
<Security />
</System>
<EventData>
<Data>oolite.exe</Data>
<Data>0.0.0.0</Data>
<Data>4ab8fd7c</Data>
<Data>objc-1.dll</Data>
<Data>0.0.0.0</Data>
<Data>490b5e03</Data>
<Data>40000015</Data>
<Data>00007383</Data>
<Data>1a90</Data>
<Data>01ca40bcd4ed6f00</Data>
</EventData>
</Event>

[Lestradae]

Aha; Vista's report about the crash! Perhaps the devs can make something of it?

[Screet]

UFF. I almost thought that I did not have any copies of buoyrepair 1.02.1 left for the test, but then found one in an old test installation.

I updated to the latest trunk version (which is a problem since many files had been changed for tests and now have been merged).

Running the debugger, it did not crash. However, there were several error reports after loading the commander and then manually exiting the game, and they worry me.

Sadly I did not find a way to copy&paste the text from the debugger output. The error messages are repeated quite often and are of this type:

Code: Select all

WARNING:
built-in varying gl_TextCoord [0] has mismatched access semantics between the vertex and fragment shader

ERROR:
1:12
:
'=' : assigning non-constant to 'const float'

ERROR:
compilation errors. No code generated.

I did clean, then make debug=yes, launched gdb, targeted the oolite.dbg.exe and then run it. The error messages and warnings only did show up after I did exit Oolite.

Next thing I'll try to make a trunk executable and test that with the old buoyrepair version....maybe the problem has been solved already?

EDIT: confirmed. 1.73.4 regularly crashes upon loading that commander without any log info, while the trunk executable does not.

Screet

[Eric Walch]

UFF. I almost thought that I did not have any copies of buoyrepair 1.02.1 left for the test, but then found one in an old test installation.

I updated to the latest trunk version (which is a problem since many files had been changed for tests and now have been merged).

Buoy repair does not add stations in the first system after a reload with the trunk version. That is because it adds the stations already on the reset handler that is removed from trunk. (And as it never was added in Lave there was no point adding ships on startUp)

This already happened with 2.0.1 so the station was already added before you launched. That makes it weird that your observed crash could be related to launching in a buoy-station system.

Ill upload a new buoyRepair version today that also works with trunk.

[Svengali]

So first tests with Screets savedgame:

Nothing!
Neither in v1.73.4 nor in v1.74(SVN2612). Neither with neocaduceus (Omega) nor without (changed player ship to Cobbie). Neither buorRepair v1.02.1 nor 1.02.3. No crash at all.
All screens are accessible without problem, actions can be done. In v1.73.4 even the facility is placed correctly.

[Screet]

So first tests with Screets savedgame:

Nothing!
Neither in v1.73.4 nor in v1.74(SVN2612). Neither with neocaduceus (Omega) nor without (changed player ship to Cobbie). Neither buorRepair v1.02.1 nor 1.02.3. No crash at all.
All screens are accessible without problem, actions can be done. In v1.73.4 even the facility is placed correctly.

That's wierd. I still can reproduce the crash from that save game with 1.73.4, but the trunk version works. I would use trunk, if it were not so slow (4 fps compared to the super-fast 1.73.4).

Screet

[another_commander]

I would use trunk, if it were not so slow (4 fps compared to the super-fast 1.73.4).

Screet, I think your installation is messed up. There is absolutely no justification for trunk running at 4fps and 1.73.4 running fast. If anything, trunk is even faster and smoother than 1.73.4 at the moment.

[Screet]

I would use trunk, if it were not so slow (4 fps compared to the super-fast 1.73.4).

Screet, I think your installation is messed up. There is absolutely no justification for trunk running at 4fps and 1.73.4 running fast. If anything, trunk is even faster and smoother than 1.73.4 at the moment.

Hmmmm. I did a clean installation for 1.73.4, but for the test, I only built a debug and a non-debug exe. After the problem did not show up during gdb run, I used the trunk non debug exe from the 1.73.4 folder. Does it require to update the whole thing for new AI and other resources?

Screet

[another_commander]

Hmmmm. I did a clean installation for 1.73.4, but for the test, I only built a debug and a non-debug exe. After the problem did not show up during gdb run, I used the trunk non debug exe from the 1.73.4 folder. Does it require to update the whole thing for new AI and other resources?

Yes, 1.73.4 and trunk are two different animals, each requiring its own set of resources. Mixing them up is not advised at all, especially when you intent to test things. Also, note that the game will indeed run much slower when executed through gdb, but it should display perfectly normal behaviour when run outside of the debugger.

[Screet]

Yes, 1.73.4 and trunk are two different animals, each requiring its own set of resources.

Well, it was not a debug version, that was so slow...however, I just built an installer and used that. Got back into the previous speed range.

When showing FPS, what is this KiB info? I've seen it being pretty low and suddenly, for only a few frames, jumping up to much larger sizes, then dropping back down to the previous level. I didn't see anything special on screen during those times.

I've yet to check on the old machine (XP instead of Vista, maybe that's a difference somehow?) if I can reproduce the 1.73.4 trouble with buoy repair...just out of curiosity.

The trunk version, however, also shows the annoying behaviour of suddenly closing without any log entry about what went wrong. Looks like I'll have some tough time experimenting with temporarily cutting out OXP parts, as the crash problem is bad enough to prevent me from doing a single flight...or I need to test in debugger on that slow machine. The question is, would the debugger catch that problem if Vista does not report a crash and OOlite simply closes?

Screet

[another_commander]

Under normal circumstances, the debugger should be able to give you a backtrace after the crash, which can lead you to the line of code that was executing at the time the crash happened. It should work under Vista, too.

Also, there is no rule that the log must report something when crashing. Reports on abnormal exit are logged only in the case there is an exception for which provisions have been made. When things crash unexpectedly, it's usually because provisions for an incoming error have not been made.

[Screet]

It should work under Vista, too.

I've got the 64bit version, which is the reason why I had to move the development stuff to an older machine with 32bit environment...it simply didn't work with my other machine. Did there change anything about that?

Guess I'll give it a try to let the game run in debug mode on it's own (cloaked flying around or such) and hope that there's a crash that the debugger will catch.

Screet

[drew]

I'm having a lot of trouble with v1.73.3 and v1.73.4. So much so I've gone back to 1.72.2 so I can actually play the game. Just keeps crashing to the desktop mid flight for no apparent reason every so often.

If I install OSE it crashes immediately on launch with the same symptoms.

1.72.2 seems rock solid by comparison - but no Griff goodness for me

Cheers,

Drew.