[jpmackay]

I am not sure what is exactly the problem with the program of Open Rails Monogame on my desktop. I am using the latest version of OR Monogame. While the player train is waiting at red signal after about 15 minutes of travelling from the yard. I see there are few flashing on my desktop screen while running in OR Monogame. My desktop is HP Omen #870-119 with ZOTAC Geforce GTX 1050TI 4Gb and the operating system is Windows 10 Pro with all updates to this date of today. Anyway I am enclosing the log.txt file for anyone who want to look at to see what is the actual problem with this.

Thank you,

John

Attached File(s)

•  OpenRailsLog.txt (27.43K)
  Number of downloads: 308

[Csantucci]

Hi John,
is this occurring in a specific activity at a specific point, or is this occurring in further circumstances?

[jpmackay]

Hi Carlos,

The route is cnbalav2 1.2 (the latest update of this route) and the activity that I ran is cn_451 and the train consist is cn_a45131. Hope that you need the information from me that you asked for.

Thank you,

John

[jpmackay]

Did you find anything with this log file?

John

[Csantucci]

This is a practically impossible problem to solve for me, sorry:
1) It's a graphics problem and I'm not expert in graphics
2) The crash doesn't occur within OR; it occurs within the MonoGame library
3) I can't re-create the problem because I don't have the route.

[roeter]

This problem reminds of a more or less similar problem which occured on my system with some regularity some years ago. That concerned a crash in XNA, also through an invalid index. In that case, the problem occured in EndDraw, rather than Draw.

I could not sort the problem, but avoided the program crash using the following patch (in game.cs) :

        [ThreadName("Render")]
        protected override void EndDraw()
        {
            try
            {
                RenderProcess.EndDraw();
                base.EndDraw();
            }
            catch (Exception e)
            {
                Program.Simulator.Confirmer.Message(ConfirmLevel.Information, "Render : " + e.Message);
            }
        }

I set the confirmer message so I could keep some trace of how often the problem occured.
Something similar could be tried here. You will loose a frame, but the program will continue.

Regards,
Rob Roeterdink

[Csantucci]

Thanks Rob,
that's an idea in effect. I can add that in next OR NewYear MG version, together with a further message containing some parameter to check.

John,
is the problem repeatable? That is, if you run again the activity, you get the same problem at the same point?

[jpmackay]

Hi Carlos,

I have not try to run again but will do shortly to see if that happen again or not. As far as I know that this is not a repeatable problem.

Thank you for your time to reply.

John

[Csantucci]

I believe I have found the (theoric) reason of the crash; there seems to be a problem on thread safety.
Here is the code that crashed (within the DrawIndexedPrimitives call):

                if (FirstActiveParticle < FirstFreeParticle)
                {
                    var numParticles = FirstFreeParticle - FirstActiveParticle;
                    graphicsDevice.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, FirstActiveParticle * VerticiesPerParticle, numParticles * VerticiesPerParticle, FirstActiveParticle * IndiciesPerParticle, numParticles * PrimitivesPerParticle);
                }

This code is executed in the Render Process.
However both FirstFreeParticle and FirstActiveParticle are updated in the Updater Process, and in particular FirstFreeParticle is periodically subject to a modulo (%) operation that reduces it. So, if the Updater Process reduces FirstFreeParticle after the if clause in the Render Process, numParticles becomes negative, and I assume that DrawIndexedPrimitives could not like negative parameters...
A rough solution conld be to test numParticles before the call, and skip the draw call if it is negative. In fact the subsequent lines after the if block are

              else
                {
                    var numParticlesAtEnd = MaxParticles - FirstActiveParticle;
                    if (numParticlesAtEnd > 0)
                        graphicsDevice.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, FirstActiveParticle * VerticiesPerParticle, numParticlesAtEnd * VerticiesPerParticle, FirstActiveParticle * IndiciesPerParticle, numParticlesAtEnd * PrimitivesPerParticle);
                    if (FirstFreeParticle > 0)
                        graphicsDevice.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, FirstFreeParticle * VerticiesPerParticle, 0, FirstFreeParticle * PrimitivesPerParticle);
                }

and that else block contains a check for numParticlesAtEnd > 0.

So, John, you don't need to run the activity again. You simply were misfortunate... but your post was very useful.
If there aren't particular comments from the IT gurus, I'll implement this in next release of OR NewYear MG.

[James Ross]

Csantucci, on 29 May 2019 - 09:43 AM, said:

This code is executed in the Render Process.
However both FirstFreeParticle and FirstActiveParticle are updated in the Updater Process, and in particular FirstFreeParticle is periodically subject to a modulo (%) operation that reduces it. So, if the Updater Process reduces FirstFreeParticle after the if clause in the Render Process, numParticles becomes negative, and I assume that DrawIndexedPrimitives could not like negative parameters...
A rough solution conld be to test numParticles before the call, and skip the draw call if it is negative. In fact the subsequent lines after the if block are

Yup, I suspect you're correct. This code is a bit racy, so either put both fields into local variables before the if, or check numParticles before the draw call.

Csantucci, on 29 May 2019 - 09:43 AM, said:

If there aren't particular comments from the IT gurus, I'll implement this in next release of OR NewYear MG.

I hope this doesn't mean you're going to neglect the official version, and instead are simply testing the fix out in NewYear MG first. :)