[SOLVED] Exception when calling a C# method from unigine script after some time

[helmut.bressler]

Hello,

 

I'm encountering an exception when calling any C# method from Unigine script after a certain amount of time.

I have the suspicion that this is happening since I have introduced two worker threads (System.Threading.Thread) which constantly generate some input data for my application (If I restrict the amount of work they generate, everything runs fine, when they are permanently producing data the exception occurs when any C# method is called from Unigine script).

 

I have produced a screenshot showing the source code of my method "isInitDoneEXE()" which should be called from Unigine script and the source code where it is being added to the Interpreter.

The exception is of type System.Runtime.InteropServices.SEHException.

 

 

The two worker threads don't use anything from the Unigine assemblies. They are synchronised with the main thread via Spinlocks, but the main thread is never really blocked (this is a requirement for STA applications, as far as I know).

 

I'm certainly not running out of memory, the application only allocated about 400 MB from 24GB of system memory.

The application is 64-bit.

I'm using Unigine 2.0 Professional, the float version.

 

I also tried to produce a simple test application for reproducing that problem (a thread running beside the unigine main loop, printing something on the screen), but everything went fine there.

 

 

Thank you for your help!

 Cheers, Helmut

 

 

 

 

 

[silent]

Hi Helmut,

 

 

 

I also tried to produce a simple test application for reproducing that problem (a thread running beside the unigine main loop, printing something on the screen), but everything went fine there.

I'm afraid, without stable crash reproduction on our side it will be almost impossible to find and fix this issue. Have you tried to check this behavior with the latest 2.1 SDK?

 

Thanks!

[helmut.bressler]

Hello Silent,

 

I have been working on my reproduction samples and indeed the crash can be reproduced quite easily.

It seems to happen after a certain amount of time and when invoking a C# method from Unigine script per frame. Here are the steps for reproduction (with Unigine 2.1 or 2.0.)

 

1. Please create a new C# 64-bit float project, without any addons and without configurator

2. Replace the unigine_project . cs file with the following content:

using System;
using System.Collections.Generic;
using Unigine;

/*
 */
class UnigineApp {
	
	/*
	 */
	[STAThread]
	static void Main(string[] args) {
		
		// init CS wrapper
		Wrapper.init();

                Interpreter.addExternFunction("getSomethingFromEXE", new Interpreter.Function0v(getSomethingFromEXE));
		
		// init engine
		Engine engine = Engine.init(Engine.VERSION,args);
		
		// main loop
		while(!engine.isDone()) {
			
			engine.update();
			engine.render();
			engine.swap();
		}
		
		// shutdown engine
		Engine.shutdown();
	}

    private static Variable getSomethingFromEXE()
    {
        Variable ret = new Variable();
        ret.setFloat(2.0f);
        return ret;
    }

}

Thats essentially the project template, except the function which is being invoked from Unigine script plus the code for adding it to the interpreter.

 

3. Please use the following code for the Unigine script world .cpp file:

#include <core/unigine.h>

/*
 */
int init() {
	Player player = new PlayerSpectator();
	player.setPosition(Vec3(0.0f,-3.401f,1.5f));
	player.setDirection(Vec3(0.0f,1.0f,-0.4f));
	engine.game.setPlayer(player);
	return 1;
}

/*
 */
int shutdown() {
	return 1;
}

/*
 */
int update() {

        float someVar = getSomethingFromEXE();

	return 1;
}

which is calling the C# method getSomethingFromEXE() per frame.

 

4. Start the project and leave it running for a couple of minutes. The crash should happen without any user interaction.

 

 

I wonder if it is some .net version problem, but here in our studio it happened on a couple of different machines, on windows 7 and 8. The faster the computer is, the application is running on, the sooner the crash seems to happen. Very strange. On the computers here in the studio it happened within the first 5 minutes when running the release build. I think it takes a little bit longer when running it inside the visual studio debugger, but it is also happening there.

We have english and german windows versions, both are affected.

 

Thank you for looking at this!

 Cheers, Helmut

[silent]

Hi Helmut,

 

I've successfully reproduced this behavior on our test stand. The bug was added to our internal bug tracker.

Thanks!

[helmut.bressler]

Hello Silent,

 

is there any update on that issue?

Is it fixed in Unigine 2.1.1?

 

Is there a possibility to work around by using another function signature? (other return type, other parameters....)

 

Thank you and cheers

 Helmut

[silent]

Hi Helmut,

 

This issue was not fixed in 2.1.1 due to lack of time for debugging. Dev team is currently investigating this issue (unfortuantely, can't give you any ETA on fix or workaround right now).

 

Sorry for the inconvenience caused.

[helmut.bressler]

Hello Silent,

 

thank you for your quick reply. This is our first project where we use C# instead of C++ for the executable.

So far I have written only conversion tools for images and meshes in C#.

For this project, I think I can wait until mid january. Then, in the worst case, I have to reimplement everything in C++.

 

Cheers

 Helmut

[silent]

Hi Helmut,

 

There is small chance that it will be fixed in 2.2 Update (February, 2016). 100% syncronization of UnigineScript / C++ / C# APIs taking a lot of time from the dev team currently and we can't promise right now that this issue will be fixed in 2.2, sorry.

[silent]

Hi Helmut,
 
We are deeply sorry for the very late reply :) Crash is caused because of C# garbage collector.
 
After rewriting your sample with a new concept of Logic classes, we were able to easily fix this crash (part of the AppSystemLogic.cs):

namespace UnigineApp
{
	class AppSystemLogic : SystemLogic
	{

        private Interpreter.Function0 func = new Interpreter.Function0(getSomethingFromEXE);
        
		public AppSystemLogic()
		{
		}

		public override int init()
		{
                        Interpreter.addExternFunction("getSomethingFromEXE", func);

			return 1;
		}
<...>

We are also plan to solve the initial issue by improving our C# API.

Sorry for the inconvenience caused.

[helmut.bressler]

Hello Silent,

 

thats a great news, thank you very much! The project where we wanted to use a c# executable is already finished, but I'm looking forward to use C# in upcoming projects as main programming language.

While that was not fixed, the C# binding was pretty much useless for us.

 

Cheers

 Helmut