Failure Condition: !sCurrentThread->mCurrentException

Runtime Error
Please report what caused this error along with the information below.
Common/ClassLib/RuntimeThread.cpp: 1419
Failure Condition: !sCurrentThread->mCurrentException

seen on 64-bit Linux.
What is that about?

Please file a bug report if you can reproduce it. It signals that a serious error has occurred with the 64-bit exception handling system and needs to be fixed.

Well I just got this too. The only thing I did was remove 2 canvas controls from the window. (this is a web app)

This has also happened to me quite a few times including about 5 minutes ago. 64bit Linux as well.

I was almost able to reproduce it but the complex logic of my program made it hard to pinpoint what line was causing it.

Most of the time it was when I was accessing a property of a session like cookies.

Mine turned out to be an uncaught out of bounds exception.

That might make sense with what I have been noticing, did it happen in an event handler?

I think my crashes were session not available exceptions.

Mine started out with “random” BBoDs. I wouldn’t get them but somebody else would. I could get them if I cleared my cache. I removed a number of canvases (acting like buttons) from the web page and replaced them with buttons. The exception then started to get caught locally on OS X 32-bit debugger. Pretty weird.

That’s what I have noticed as well, by running it locally I would see the error. I guess I never made the connection that these crashes were just unhandled errors that got past the framework.

I just had it happen again.

I was looping through all sessions using “SessionWithIdentifier”. After reloading the page the app it would attempt to access a session that was unavailable giving me a “SessionNotAvailableException” that wasn’t caught by the Xojo exception handling, causing a crash.

[quote=312599:@Alex Bombay]I just had it happen again.

I was looping through all sessions using “SessionWithIdentifier”. After reloading the page the app it would attempt to access a session that was unavailable giving me a “SessionNotAvailableException” that wasn’t caught by the Xojo exception handling, causing a crash.[/quote]

Did you find a solution to this issue @Alex Bombay? This error is popping up for me in a standalone web application on Windows 2012 R2.

Robert

[quote=323487:@Robert Litchfield]Did you find a solution to this issue @Alex Bombay? This error is popping up for me in a standalone web application on Windows 2012 R2.

Robert[/quote]

The way I caught the exception was when I ran it in debug mode and it dropped into the debugger. Right now, because there are no runtime function names for 64bit and I also wanted a runtime profiler, I created my own.

At the top of each of my sections of code I have:

Dim Profiler As New Profiler(CurrentMethodName)

By adding a runtime start arg, I can have my profiler print each section, giving me a ballpark location of where the error might be happening, then it’s just a matter of trying all possibilities in the debugger or adding in Print(<line_number>) to find out what line is causing the issue.

Best of luck,
Alex

[quote=329848:@dave duke]Im getting this on 5 live systems, is there anyway to trap it?

Runtime Error
common/ClassLib/RuntimeThread.cpp: 1419

The last operation the server did was to run a SQLcommand on a local DB. However there maybe a UI update there too.[/quote]

The best way so far to debug these issues for me is to start the program up in a 32bit debug environment. However, most of the time these issues happen in production and never happen when I am able to test. Setting up some sort of your own profiler with the ability to print when it enters and exits sections is also a good way of tracking down the method that it is happening in.

I am also seeing this on 64bit MacOS now. Actually I’ve been seeing it for a while. I’ll try a 32 bit compile to see if it goes away and if I get any exceptions that I wasn’t getting before. If it’s exception handling that causes it then perhaps I can do more pre-flight of bounds and eof’s and not rely on exceptions so much but it’s a real bear to figure out.

32 bit compile definitely makes it go away so that I can log the exceptions, will try to narrow it down to a test case that can duplicate it if possible.

by doing the 32bit compile and actually finding where the out of bounds exceptions was being created I was able to preflight some of that data and stop the error. That also stopped the problem on 64 bit. I tried to duplicate the issue with a test app which didn’t completely succeed but it can make the app hang up completely even if those dialogs don’t ever appear so it’s still a bug with error handling on 64 bit.

In my case I was causing the error in the paint event of a canvas, checking it’s type in the exception handler at the bottom of the routine and if it wasn’t something I wanted to handle there using raise to let it fall up to the global handler. This seems to be what was causing the problem though I can’t be sure as the test app that does that doesn’t fail in quite the same way.

If anyone has any more info please add it to the feedback report: feedback://showreport?report_id=50953

I have had this too, will look into how to reproduce

Yes, It looks to be tied to many different uncaught error cases, mostly OutOfBoundsException or SessionNotAvaliable for me. Almost all of the time 32bit will allow you to at least catch the error. Also appears to be closely tied to the use of threads.