View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001704||NoesisGUI||C# SDK||public||2020-05-27 14:08||2023-02-02 17:31|
|Summary||0001704: Errors spam on NoesisGUI Shutdown|
we're still using the 3.0.0 RC6 build and why investigating some logs with the game stuck on exit I've noticed that sometimes there is a massive dump of entries like:
The calling thread (18460) cannot access this object (TextBlock) because a different thread owns it (12484)
The calling thread (18460) cannot access this object (ContentPresenter) because a different thread owns it (12484)
The calling thread (7052) cannot access this object (View) because a different thread owns it (12484)
I guess it's related to the .NET finalizer thread.
|Tags||No tags attached.|
And I assume you don't have a thread (12484) that is accessing a view created in a different thread , do you?
@jsantos, I'm certain this cannot be the case. Our game engine is mostly single-threaded. Multiple threads are used only to load assets and perform similar loading tasks that don't affect UI or logic. The rest are kept in the main thread to keep me sane :-)
Alas, I cannot reproduce this issue. I've searched my own logs folder (with two dozens of log files for the past two weeks) and found only a single log file where this issue appeared. And it never appeared in the debug version of the game (there is a hundred of log files for the past month)...so it's very random. I will update the task when I gather more info.
12484, 18460 are numbers we get from the current thread ID. So I am 99% confident Noesis objects were accessed from those threads. I am not sure if we could have a bug here @sfernandez
It would be really helpful if you could dump all your thread ids to the log.
Could it be that the .NET finalizer thread is accessing these objects during the finalization stage? It's happening during the application shutdown only (and it's a very rare/random issue).
I will add the logging of all the thread IDs on shutdown if I notice that this issue continues.
|Yes, that could be the reason and I would say it is a bug @sfernandez|
Unless we have a bug, all objects are released in the main frame. When a C# proxy is destroyed in the finalizer thread we enqueue the release of its reference to occur always in the main thread.
Perhaps these errors are unveiling another kind of bug. If you can provide a game build that generates those random errors I can take a look.
|2020-05-27 14:08||ai_enabled||New Issue|
|2020-05-28 11:11||jsantos||Assigned To||=> sfernandez|
|2020-05-28 11:11||jsantos||Status||new => assigned|
|2020-05-28 11:11||jsantos||Target Version||=> 3.0|
|2020-05-28 11:12||jsantos||Note Added: 0006409|
|2020-05-28 11:12||jsantos||Status||assigned => feedback|
|2020-05-28 11:12||jsantos||Note Edited: 0006409|
|2020-05-28 16:03||ai_enabled||Note Added: 0006411|
|2020-05-28 16:03||ai_enabled||Status||feedback => assigned|
|2020-06-08 14:08||jsantos||Note Added: 0006429|
|2020-06-08 14:08||jsantos||Status||assigned => feedback|
|2020-06-08 14:23||ai_enabled||Note Added: 0006430|
|2020-06-08 14:23||ai_enabled||Status||feedback => assigned|
|2020-06-08 14:26||jsantos||Note Added: 0006431|
|2020-06-08 14:34||sfernandez||Status||assigned => feedback|
|2020-06-08 14:34||sfernandez||Note Added: 0006432|
|2020-06-08 14:39||sfernandez||Note Edited: 0006432|
|2023-02-02 17:31||jsantos||Relationship added||related to 0002500|