Callback on collected delegate

[Milan van den Muyzenberg]

First of I'd like to express my appreciation for the client DLL for .Net. Works great. There's one thing that's bugging me at this moment. It's this exception:

Managed Debugging Assistant 'CallbackOnCollectedDelegate' 
  Message=Managed Debugging Assistant 'CallbackOnCollectedDelegate' : 'A callback was made on a garbage collected delegate of type 'fsuipcClient!FSUIPC.WAPI+LogCallback::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.'

I get this when disconnecting from MSFSVariableServices. When disconnecting, I first remove all generic and lvar callbacks. Subsequently, I stop the services. Nevertheless, this exception occurs. What am I doing wrong?

[Paul Henty]

Hi,

First, can you please check that you're using all the latest versions:

My DLL: 3.2.17 (Update on NuGet)

FSUIPC: 7.3.1 (http://fsuipc.com)

FSUIPC_WAPID.DLL from the 0.5.6 version of the "FSUIPC WASM Module" package. (http://fsuipc.com)

If you're still getting the error:

Are you disposing of the MSFSVariableServices object, or setting the reference to null when this happens?

I think when you call stop() the WASM module will try to send back a log message to say it's shut down. If the MSFSVariableServices class no longer exists it'll throw this exception. The best thing is to keep the instance alive once you've created it. Calling Stop() is enough to shutdown the connection.

If none of that helps, perhaps you can post your code where you call Stop() and also where you create the MSFSVariableServices.

Paul

 

[Milan van den Muyzenberg]

Hi Paul,

Thanks for your quick response. Your DLL, FSUIPC and the FSUIPC_WAPID.DLL all have the version numbers you refer to.

When I disconnect, I first remove the "generic" callbacksm (OnLogEntryReceivedOnValuesChangedOnVariableListChanged) followed by a call to Stop() on the MSFSVariableServices object. After that, I set the reference to null. I do not explicitly call Dispose() on the object. 

Even though I can (and will for now) implement your suggestion (i.e. do not dispose of the object), I wonder how I can get rid of it without running the risk of getting this exception. Can you explain how to get rid of it in a controlled way?

Edit: the suggested fix somehow does not work. After calling Stop() and Start(), the IsRunning getter returns false consistently...

Edited March 11, 2022 by Milan van den Muyzenberg

[Paul Henty]

I've been looking into this in more detail. 

When I made MSFSVariableServices a normal class, this was a design mistake by me. It should have been a static class. The FSUIPC_WAPID.dll that I use is written in a singleton pattern, and only one copy of that DLL can be loaded by my dll.

So it doesn't make sense to dispose the MSFSVariableServices once you create it. Setting the reference to null means that the .NET garbage collector will dispose of it for you.

I will change this to a static class in the future, but for now you should not dispose it or lose the reference to it by setting it to null.

Quote

 After calling Stop() and Start(), the IsRunning getter returns false consistently...

This is a separate issue from the above. Here are some things you can try to find the problem:

1. Turn the logging level up (e.g. debug/trace) and see what the log says when the connection fails.

 

2. Try stopping and starting with my example code application for MSFSVaraibleServices: (You might need to update the FSUIPC_WAPID.dll and my DLL via nuget).

http://fsuipc.paulhenty.com/#downloads

If this works then something is different in your code. You can compare them.

 

3. Try stopping and starting with John's client program in the FSUIPC-WASMv0.5.6 package (\WASMClient\WASMClient.exe).

If this doesn't work either then there is problem with John's code, or your setup.

 

Paul

 

[Milan van den Muyzenberg]

Following your suggestion to not dispose object of type MSFSVariableServices, I ran into another issue. After first start of MSFSVariableServices, everything runs fine, i.e. am getting LVAR change updates. After stopping and restarting, I do no longer get LVAR updates. I trimmed down my entire application to a bare minimum, which I am obviously willing to share if you are interested.

[Paul Henty]

I don't have MSFS here so I'm not sure how useful your project will be. I can certainly have a look and see if I can see anything obvious. But I won't be able to run and debug it.

I still recommend the three steps in my last post:

• The debug/trace level log will likely show the problem.
• My example code should work and will show you if the DLL works okay.
• John's client program will show if the problem is in your MSFS/FSUIPC install is okay.

Paul

[Milan van den Muyzenberg]

Debug/trace does not reveal any issue. Your example code works. In fact, my code is very much the same and partly taken from the example.

Hopefully, you find anything by briefly looking at the code (see DM). It's not much and not complex. Thanks.

Edited March 12, 2022 by Milan van den Muyzenberg

[Milan van den Muyzenberg]

Problem seems to be solved. For anyone reading this topic dealing with the same issue: don't dispose the MSFSVariableServices or set its reference to null. Timing of subscribing delegates to change of an LVar somehow seems to matter...

[Paul Henty]

I will be making changes to MSFSVariableServces to prevent both these problems.

Paul

[Milan van den Muyzenberg]

Thanks Paul; looking forward to this release

[Paul Henty]

Version 3.2.19 is now on NuGet.

Details of the changes to MSFSVariableServices are here:

https://forum.simflight.com/topic/94374-breaking-changes-for-msfsvariableservices-in-version-3219/

Paul

[Milan van den Muyzenberg]

Whow, that's fast. Will migrate asap. Migrated and working fine. Thanks