[James Ross]

It's weird, as I've never had a single crash from this code. But I am sure that we can do better than a lock. ;)

For what it's worth, I don't believe the following to be true:

dennisat, on 06 December 2014 - 01:23 PM, said:

I understand that compare/exchange can only protect contiguous items of data, not many separate items which is what a dictionary must usually be.

Compare/exchange simply allows you to update a pointer atomically - it doesn't matter what kind of data it is. It does, however, matter that the data structures using it are immutable, which is why the code was quite complex: to add or remove a sound source (in a List in the Dictionary) it must create a new List (with the item added/removed) and a new Dictionary, then swap the new and old Dictionaries. Judging by the crash stack, something, somewhere is not correctly doing this and is instead modifying a List that is currently in-use. (Unfortunately there's no good way to validate that data structures are immutable in .NET.)

It would be really useful if someone could provide some example situations when this occurs which I might be able to test with since, like I said, I don't believe I've seen this happen even once. (Log files are useful here in case you have different settings than me, for example.)

[dennisat]

James Ross, on 03 January 2015 - 02:31 PM, said:

For what it's worth, I don't believe the following to be true:
I understand that compare/exchange can only protect contiguous items of data, not many separate items which is what a dictionary must usually be...

It must be true, I found it on the Internet! ;) One of the many things I read while trying to find a way to use compare/exchange on collections of collections. Being an ex-assembler programmer it did make a kind of sense.

However, I also know it should be possible to design a method which would cater for non-contiguous collections of collections. I just never got any of the options to work and took the easy way out. However, as I said above, to mitigate the effects of using lock, I've made the sound update interruptible.

As for a reliable test case, it doesn't seem to be possible to get a regular failure at one point. Probably the variables are too many. Something in the background might kick in, slightly altering timings in the program and hey presto! - No crash or crash at a different point. A crash can usually be created by starting an intense activity on MEP or Dorset Coast that runs through the most complex areas. It may happen in minutes or take an hour but it will crash. Unfortunately it never happens at the same place twice.

Dennis

[Csantucci]

James Ross, on 03 January 2015 - 02:31 PM, said:

It's weird, as I've never had a single crash from this code. ...
It would be really useful if someone could provide some example situations when this occurs which I might be able to test with since, like I said, I don't believe I've seen this happen even once. (Log files are useful here in case you have different settings than me, for example.)

As dennisat says, it's random. The only thing I can say is that to me usually the crash occurs when an AI train is created near to the player train or arrives at the distance to the player train where its sound sources enter into the dictionary.

[James Ross]

Csantucci, on 04 January 2015 - 12:19 AM, said:

As dennisat says, it's random. The only thing I can say is that to me usually the crash occurs when an AI train is created near to the player train or arrives at the distance to the player train where its sound sources enter into the dictionary.

Sure, but random things are more or less likely based on a number of environmental factors. Since I have never seen this happen I must be in some kind of favourable environment, where as you are not. The game settings are part of that, as is the route/activity. I'll try with MEP but without knowing more about your environment I may still not be able to reproduce the problem.

[dennisat]

James Ross, on 04 January 2015 - 03:54 AM, said:

Sure, but random things are more or less likely based on a number of environmental factors...

A thought. Changing sleep time in soundprocess.cs from 50ms to something lower, such as 5ms, would get the update turning over much faster and may increase the chances of a clash with add and delete sound sources.

Dennis

[Csantucci]

James Ross, on 04 January 2015 - 03:54 AM, said:

Sure, but random things are more or less likely based on a number of environmental factors. Since I have never seen this happen I must be in some kind of favourable environment, where as you are not. The game settings are part of that, as is the route/activity. I'll try with MEP but without knowing more about your environment I may still not be able to reproduce the problem.

In my Launchpad bug report, https://bugs.launchp...et/bugs/1401967 that you correctly marked as duplicate, there is my logfile, where you can check my settings.
As for the computer, I run OR on a Windows 7 SP1 (32 bit) Asus notebook with an Intel Core2 Duo CPU T5900 @2,20GHz, with 4 GB RAM and nVIDIA GEForce GT 120M graphics hardware.

[James Ross]

Csantucci, on 04 January 2015 - 08:37 AM, said:

In my Launchpad bug report, https://bugs.launchp...et/bugs/1401967 that you correctly marked as duplicate, there is my logfile, where you can check my settings.
As for the computer, I run OR on a Windows 7 SP1 (32 bit) Asus notebook with an Intel Core2 Duo CPU T5900 @2,20GHz, with 4 GB RAM and nVIDIA GEForce GT 120M graphics hardware.

Thanks; I shouldn't have marked that as a duplicate, since it was a new/different issue (the original was an issue with the original code, yours was an issue with my fix for the original), so I've corrected that.

[cjakeman]

dennisat, on 03 January 2015 - 04:09 PM, said:

As for a reliable test case, it doesn't seem to be possible to get a regular failure at one point. Probably the variables are too many. Something in the background might kick in, slightly altering timings in the program and hey presto! - No crash or crash at a different point. A crash can usually be created by starting an intense activity on MEP or Dorset Coast that runs through the most complex areas. It may happen in minutes or take an hour but it will crash. Unfortunately it never happens at the same place twice.

Are you saying that Replay doesn't help here?
Is it not precise enough to repeat exactly and crash in the same place?

[dennisat]

cjakeman, on 04 January 2015 - 11:34 AM, said:

Are you saying that Replay doesn't help here?
Is it not precise enough to repeat exactly and crash in the same place?

I'm not entirely sure how the replay works but does it take into account I/O times, for example? Since this bug is a problem with thread synchronization timings need to be reproduced exactly. A small difference caused, perhaps, by I/O times could mean threads on reruns being out of phase with the first. I've had problems with this in the past because Windows caches frequently accessed I/O. A subsequent run will always run faster unless you re-boot.

Dennis

[cjakeman]

dennisat, on 04 January 2015 - 01:32 PM, said:

I'm not entirely sure how the replay works but does it take into account I/O times, for example?

No. It merely repeats the input from keyboard and mouse, so more accurate than repeating by hand but that's as far as it goes.

Might be worth trying though. It's a real boon when you need to repeat something many times like you might in testing a new feature.