[Csantucci]

I'm getting this crash https://bugs.launchp...or/+bug/1305165 when running an automatic build downloaded from James' site. If I instead run the executable downloaded from SVN (or rebuilt by myself) I don't get the bug. A process concurrency problem? Problem is, that this way investigating the bug is quite a hard task for me.

[dennisat]

I have had this crash recently but didn't look into it too closely because the next day I downloaded a new version from the SVN, rebuilt it, and so far the problem has not recurred. I assumed the problem had been fixed in (or before) the version I downloaded. Needless to say, I've forgotten the relevant version numbers.

Dennis

[James Ross]

As I've said previously, the two are built differently and will necessarily cause different timings. My builds, being "release", are much more representative because it'll be what all releases to the public actually are. There will also be differences between running the Subversion builds and running the code under a debugger. But, if you want to debug a release-only bug, switch Visual Studio to release mode, rebuild everything, run the program without debugging and then attach the debugger when it crashes.

[Csantucci]

Hi James, can you pls. explain me how I do "attach the debugger" after having run the release mode of the OR pack and having got the crash dialog box?

[Csantucci]

OK, I found what I think causes the problem. In my analysis it should not be a thread safety problem, and by the way it happens always on the same sequenceMaterial list (made by 4 objects).
Here is a working patch  RenderFrame.cs.patch.zip (388bytes)
Number of downloads: 432
As can be seen, I had to remove the sorting adjustment based on the sorting index.
On the Internet I also found this post http://www.pcreview....u-t2605541.html about the exception, where it is written that a report was sent to MS about it (by the way, maybe casually, the non-working study case created there has also 4 objects...)

So, if it is necessary to differentiate primitives with almost same or same location, I would ask to find another way to do it. If I am completely wrong, excuse me.

[James Ross]

Csantucci, on 12 April 2014 - 01:41 AM, said:

OK, I found what I think causes the problem. In my analysis it should not be a thread safety problem, and by the way it happens always on the same sequenceMaterial list (made by 4 objects).

This is not acceptable because we must sort similarly positioned objects correctly. If they do not have reasonable sort indexes, that should be fixed, but their use is not to be removed.

[Csantucci]

James,
I don't understand what is not acceptable. Have you read the discussion I have linked? Why things work when in debug mode? Why should the sort indexes be unreasonable?

[James Ross]

Csantucci, on 12 April 2014 - 01:07 PM, said:

I don't understand what is not acceptable. The problem seems to arise not from not reasonable sort indexes, but from the questionable way used to artificially distantiate objects using sort indexes. Eliminating such way solves the problem (I hope it does not create other ones).

If the sort indexes are reasonable, there will be no problem. So you must be experiencing unreasonable sort indexes - fix that, not that fact that they are used to influence the sort, which is required for models to render correctly.

[Csantucci]

Have you read the discussion I have linked? Why do things work in debug mode?

[James Ross]

Csantucci, on 12 April 2014 - 01:21 PM, said:

Have you read the discussion I have linked? Why do things work in debug mode?

If you'd read the discussion you linked, you'd see that someone identified a possible cause being a threading issues. That, among other possible reasons, is why different environments experience different results.

I am literally out of care for this now; either you work out what the problem with the sort indexes is or you work on something else. I am sick and tired of people thinking that e.g. linking to a strange and unclear thread on another forum somehow validates their theory instead of actually providing facts and evidence.

The sort cannot fail unless the data provided to it is wrong. Figure out why the data provided is wrong.

[gpz]

Carlo,

I think if

var xd = (x.XNAMatrix.Translation - XNAViewerPos).Length() - x.RenderPrimitive.SortIndex;

fails, then the most possible cause is that x.RenderPrimitive is null, or something similar.

[Csantucci]

This is what I have traced after the exception:

arning: Exception message = IComparer (o i metodi IComparable su cui questo si basa) non ha restituito zero quando Array.Sort ha chiamato x.CompareTo(x).  x: ''. Tipo di x: 'RenderItem'. IComparer: 'ORTS.Viewer3D.RenderItem+Comparer'.

Warning: sequenceMaterial.Key = EmptyMaterial, sequenceMaterial.Value.Count = 4, renderItemComparer.XNAViewerPos = {X:-566,4696 Y:562,159 Z:46,89798}

Warning: sequenceMaterial.Value[0].Material = SceneryMaterial(c:\saveroutes\train simulator bernina\trains\trainset\rhb_ew_iv\\pass_glas.ace:00000005:0) ,  sequenceMaterial.Value[0].RenderPrimitive.SortIndex = 21, sequenceMaterial.Value[0].XNAMatrix.Translation = {X:-565,4244 Y:562,8322 Z:50,28863}

Warning: sequenceMaterial.Value[1].Material = SceneryMaterial(c:\saveroutes\train simulator bernina\trains\trainset\rhb_ew_iv\\pass_glas.ace:00000005:0) ,  sequenceMaterial.Value[1].RenderPrimitive.SortIndex = 19, sequenceMaterial.Value[1].XNAMatrix.Translation = {X:-567,3919 Y:562,8322 Z:47,30493}

Warning: sequenceMaterial.Value[2].Material = SceneryMaterial(c:\saveroutes\train simulator bernina\trains\trainset\rhb_ew_iv\\pass_glas.ace:00000005:0) ,  sequenceMaterial.Value[2].RenderPrimitive.SortIndex = 20, sequenceMaterial.Value[2].XNAMatrix.Translation = {X:-566,4082 Y:562,8322 Z:48,79678}

Warning: sequenceMaterial.Value[3].Material = SceneryMaterial(c:\saveroutes\train simulator bernina\trains\trainset\rhb_ew_iv\\pass_glas.ace:00000005:0) ,  sequenceMaterial.Value[3].RenderPrimitive.SortIndex = 22, sequenceMaterial.Value[3].XNAMatrix.Translation = {X:-565,4244 Y:562,8322 Z:50,28863}

I don't see strange things, apart from the fact that the position of the first and the last object is the same.
This is the full log
 OpenRailsLog_sort.zip (3.5K)
Number of downloads: 383

I have made a basic and working proposal for solution. I don't have other ones and give up.

PS: Peter, I have seen now your hint, thank you very much. However, looking at the data I have collected, that does not seem the case.

[James Ross]

Csantucci, on 12 April 2014 - 02:13 PM, said:

I don't see strange things, apart from the fact that the position of the first and the last object is the same.

That is exactly why we have the SortIndex, to ensure such items are always drawn in the correct order. :sign_thanks:

[Csantucci]

This patch here avoids the crash and uses the original comparing algorithm. The comparison has only been compacted. I hope it can be accepted
 RenderFrame.cs.patch.zip (406bytes)
Number of downloads: 373

[gpz]

:) Interesting! This is the evil in the machine. :)
(I'm just wondering if the Math.Sign() is necessary there. I think it can be removed to save a couple of CPU instructions, since for compare it doesn't matter if the result is e.g. 1 or 8526. No need to normalize.)