Has anything changed in how ThreadAccessingUIExceptions are handled in 2016r2? I’m getting those most beloved exceptions in totally new places since upgrading. They occur when closing a window at “end sub”. What am I doing wrong here? How do I debug these issues? Examples:
what is the stack trace of those exceptions?
I didn’t keep that. One thread is checking an IMAP connection and the other gets data from Evernote and updates the display.
Maybe that could be helpful: http://www.realsoftwareblog.com/2012/10/detecting-ui-access-from-threads.html
I had the same issue with a project once i moved it over to the current release. Because it was happening at the end sub on the window close event. my Try Catch block could not catch it. Long story short after trying different ways to kill the thread in the close event of the window I ended up adding to my app.unhandled exceptions.
if error isa ThreadAccessingUIException then
//We dont need to report this
Return true
end if
It seems that the second of the two screenshots maybe is not an error. See: ThreadEndException. This is raised when a thread ends and is a notification, and you have to re-raise it.
[quote=278052:@Jordan Morris]I had the same issue with a project once i moved it over to the current release. Because it was happening at the end sub on the window close event. my Try Catch block could not catch it. Long story short after trying different ways to kill the thread in the close event of the window I ended up adding to my app.unhandled exceptions.
[/quote]
If you can reproduce it and you think it’s a bug, please file a case in Feedback. It’s hard to tell from this thread exactly what’s happening.
I have created a ticket (44680) along with a sample project
@Eli Ott: sigh… The app has been Cocoa for a longer while so I really know what this exception is.
@Joe: the window is very complicated. I just noticed this error 2 times in a couple of days when opening the window and closing it then quickly. I’ll try to reproduce.
@Jordan: I’ll have a look at your ticket.
What’s going on here is that the thread finishes after the window is closed and the thread is left holding on to the last reference to the window. When the thread finishes, that last reference is removed and the window is destroyed on a non-main thread. That’s where the exception comes from and why it’s at the end of the method.
I suspect this goes back much further than 2016r2, but have not checked yet.
So if the thread were killed before Close finished the exception would go away ?
Killed, resumed, waiting for the thread to finish via a lock, or anything like that should resolve it.
Does that mean a thread cannot be destroyed while it runs ?
Correct.
@ Joe: thanks for the explanation. But I’m already checking on close if the threads are running and then I kill them. There are even semaphores in place so that everything happens only one. When doing the semaphores I remember that I did intensive testing with closing the window. I never saw such a crash in the last year or so.
[code]if ThreadCheckImap.State = Thread.Running then
ThreadCheckImap.Kill
end if
if ThreadGetMailboxes.State = Thread.Running then
ThreadGetMailboxes.Kill
end if
#pragma BreakOnExceptions false
try
if theSemaphore <> Nil then theSemaphore.Release
catch err as IllegalLockingException
'just ignore
end try
#pragma BreakOnExceptions True
[/code]
@Jordan Morris : What is supposed to happen if you run your sample project? If the window is closed an exception is raised? FWIW: I don’t see that on earlier versions (2015r41 or 2014r21). Your workaround using the app.unhandled exceptions does seem to work.