Trunk nightly

[another_commander]

We were aware of CTDs in trunk even before they were reported here. Be patient and we'll eventually get to fix them.

[Cody]

We were aware of CTDs in trunk even before they were reported here.

I wish you'd told me that yesterday - I spent most of last night fiddling with various combinations of OXPs.

[Diziet Sma]

Having now installed a couple of OXZs through the new manager, it occurs to me that another key in the manifest.plist might be worthwhile.. perhaps in the "Mostly-required keys" section.. one for the filesize. It would be useful to know how big a download was going to be, without having to begin the download to find out..

What do you think?

[Zireael]

Having now installed a couple of OXZs through the new manager, it occurs to me that another key in the manifest.plist might be worthwhile.. perhaps in the "Mostly-required keys" section.. one for the filesize. It would be useful to know how big a download was going to be, without having to begin the download to find out..

What do you think?

Seconding it so hard.

[cim]

I presume no-one else is getting CTDs?

I've had a series of test rigs doing not much but make witchspace jumps for hours, and in all that time I've got two CTDs (and at least two shot down by pirates), which narrowed down the location but not enough... But there's definitely something there. Tonight's nightly will have some extra logging: if the crash is what I think it is, you should end up with some [dataCache.integrityCheck] lines in your Latest.log immediately afterwards. Their contents might be very useful.

It would be useful to know how big a download was going to be, without having to begin the download to find out..

Yes, true. It's a field that could only be known after you'd packed the OXZ with the manifest inside it, of course, but as an optional field that's more for the copy of the manifest in the index that's possible.

[Norby]

It's a field that could only be known after you'd packed the OXZ with the manifest inside it

File commanders solve this easily: press enter on the .oxz then F4 on manifest, edit the size number and save will repack the modified plist into the oxz.

[cim]

and save will repack the modified plist into the oxz.

...changing its size.

It doesn't matter - you don't need the value if you have the file because you can see how big it is, and it's okay if it's a few bytes (or even a few K) off for advisory on downloading.

[Keeper]

Last x64 trunk build I had was from around Jan. 9. I decided to try the latest tonight. I'm getting crashes to desktop on the map screens with regularity -- not while docked, but while in flight. It usually happens as I click on a system (but not every time).

Each time, the log indeed ends with a dataCache.integrityCheck. Here are two:

23:09:11.182 [dataCache.integrityCheck]: Integrity check (setObject:forKey: after for "recent textures"): expected 47 nodes, found 48. Cannot repair; clearing cache.

22:37:18.497 [dataCache.integrityCheck]: Integrity check (setObject:forKey: after for "recent textures"): expected 40 nodes, found 41. Cannot repair; clearing cache.

[Cody]

Oolite has been toying with me today - it simply refused to crash, until just now:

Code: Select all

15:24:55.483 [dataCache.integrityCheck]: Integrity check (setObject:forKey: after for "recent textures"): expected 48 nodes, found 49. Cannot repair; clearing cache.

I'm liking the new 'instructions' from mother ships, cim - but I've seen a few solo ships issue 'prepare to hyperspace' messages too.

[cim]

Okay, those log lines tell me that ... the code I added which is supposed to examine the current situation to see what might be causing the crash is itself crashing. Excellent.

I'm liking the new 'instructions' from mother ships, cim - but I've seen a few solo ships issue 'prepare to hyperspace' messages too.

They're mainly in because I have a suspicion some of them are jumping out before the 15 seconds are up and I want to keep a closer eye on them.

[cim]

Okay, tonight's nightly will try to log the crash slightly differently. There should, if it works, be a few more lines after that one.

[Nyarlatothep]

As I was trying to figure out a proper berth control method I left my ship docked to the main station. After about half an hour I got a series of these:

Exception: ReferenceError: ai is not defined
Active script: Oolite Assassin AI 1.79
oolite-priorityai.js, line 3051:
if (ai.getParameter("oolite_flag_witchspacePursuit"))

I had the aliens & bigships oxps from the oxp manager, but this seems to be from Oolite itself. Please ignore if it's already fixed in trunk.

[Cody]

Okay, tonight's nightly will try to log the crash slightly differently. There should, if it works, be a few more lines after that one.

Here you go, Admiral - it's only one extra line, but I hope it helps:

Code: Select all

16:38:44.689 [dataCache.integrityCheck]: Integrity check (setObject:forKey: after for "recent textures"): expected 45 nodes, found 46. Cannot repair; clearing cache.
16:38:44.689 [dataCache.integrityCheck]: Key is: NULL

As an aside: my RHL took a hit in the last encounter with assassins, but it continued to locate hermits.
Is there anything different in recent trunk that might cause that?

[cim]

After about half an hour I got a series of these:

Thanks - fixed in 01bb1e1 for tonight.

Okay, tonight's nightly will try to log the crash slightly differently. There should, if it works, be a few more lines after that one.

Here you go, Admiral - it's only one extra line, but I hope it helps:

Well, that will probably be easier to debug than if there'd been twenty extra lines and that one right in the middle. I shall have another look at what's going on.

As an aside: my RHL took a hit in the last encounter with assassins, but it continued to locate hermits.
Is there anything different in recent trunk that might cause that?

Not that I know of. Unless it's changed since I had one, it "worked" by adding nav buoys with beacons when you entered the system, so damage only made a difference once you went to a new system. I don't think it's been updated since 1.77 made beacon codes writable by script, anyway.

[cim]

file_size has been added as an optional manifest property and applied to the index.

The witchspace-related crash bug I put a potential fix for in which was in Thursday's build: the crashes were rare enough that if it did work it might take a while to tell. If you see any more crashes with a [dataCache.integrityCheck] line in the log, please report them so that we can try something else.

If you see any more crashes without that log line, there is a second known crash bug being investigated, so it will still be useful to know.