StackOverflowExceptions in 32 and 64Bit Windows Builds

I have StackOverflows only in R3, R2 works flawlessly.

They appear at various locations like in a HTMLViewer while it is resized by RubberViews, or while using HasKey on an empty Dictionary, or while querrying a mySQLCommunityServer with a ps = Server.Prepare(… and so on…

StackOverflowException HTMLViewer.!MainLoopHook &t Delegate.Invoke Application._CallFunctionWithExceptionHandling op REALbasic._RuntimeRun _Main main

StackOverflowException Application._CallFunctionWithExceptionHandling op REALbasic._RuntimeRun _Main main

I am 100% sure my Code is not the cause.

Because i can’t reproduce it in a simple project yet, i fear i have to wait until R3 is in the wild and other experience the same. Hopefully then we will be able to eliminate those.

BTW: In R3 i am not seeing those “StackOverflowException” Bubble anymore at the as faulty marked code line:
Link to original Image

I am extremely interested into making that bug disappear if indeed it comes from RubberViews. I resize this control just like others, and it is possible that something happens doing so in R3 that does not in R2. But I was not able to trigger the StackOverflowException in a Mac (you are on Mac, right ?) built executable of the demo, which contains an HTMLViewer that is resized, control and content.

Could you try to set ContentResizes so your HTMLViewer content is not resized ? It is far fetched, but it is possible the JavaScript interferes, somehow. If the error disappears, then we know where it is.

Maybe there is something else in the code attached to that control ?

I will appreciate any report, here or by email.

Even if i remove RubberViews completely from my project, i get StackOverflows. The errors occur at “random” positions.

I see Stack Overflow for example in the following code:

[code] If WAG4UserID > 0 Then

Dim ps As MySQLPreparedStatement
Dim data As RecordSet

ps = WAG4_Server.Prepare("SELECT username FROM wag_main_db.wag_main_user WHERE id=?")

ps.Bind(0, WAG4UserID, MySQLPreparedStatement.MYSQL_TYPE_LONG)

data = ps.SQLSelect

If Not WAG4_Server.Error Then
  If data <> Nil Then
    If Not data.EOF Then
      Return data.IdxField(1).StringValue.DefineEncoding(Encodings.WindowsANSI)
    End If
  End If
End If

End If

Return “”


The Debugger show the error at line:

 data = ps.SQLSelect

Can’t find the reason for a Stack Overflow here :frowning:

did “If Not WAG4_Server.Error” Then to If WAG4_Server.Error = false Then" and “If Not data.EOF Then” to “If data.EOF = false Then” solved the issue?

No, but if i replace the PreparedStatement with a simple “data = WAG4_Server.SQLSelect(…”, the StackOverflow moves and occurs right below the line wich called the above Method.

Looks like my issues are somehow associated with Timers running on 25 - 50ms periods, which are waiting for Threads which accessing mySQLCommunityServers.

If ThreadTest.State = Thread.NotRunning Then

But i can’t create a simple App raising the errors :frowning:

Curious- does your problem go away if you use the mysql plugin from r2?

Deleted the Plugin Cache and moved the R2 plugin into the R3 Folder. But the issue stays the same. restored the R3 Plugin.

Is it “normal” that Message and Reason of the StackOverflowException are empty and that the Code is 0?

Link to original Image

Just to be a bit more precise, i am Building on OS X El Capitan 10.11.1. Then Debugging on Windows 7 32Bit running in Parallels 11 Pro.

Maybe this issue is related to (]this change in the Windows Framework?

Because it happens only on Windows?

Timers and mySQLCommunityServer and/or mySQLPreparedStatements in combination seem to generate a Stack Overflow Error in Windows builds. As soon as i use a Timer to wait for a Thread in which i access a Database, to reach the NotRunning state, or while i am preparing or “selecting” prepared statements, i get stack overflow errors.

I am doing nothing special in my project. There is a login window which opens a connection to a mySQL DB to lookup the last time this machine logged in and compares the windows username with the login name. Then i start 1 Thread which opens 4 more connections to other Servers, to speedup later access to them. Then a second Thread starts which builds 2 string arrays (4 and 11 entries) and queries 3 times one of the previous connected Servers to build a 3rd string array and fill 2 more simple strings.

While i am doing the above, the stack overflow occurs in the 2nd Thread, just before it is running. If i remove 1 of these Threads and place the code into Methods of the Window, the next time a prepared statement is queried, a stack overflow is occurring…

Because no-one reported this until now, i assume i am coding something terribly wrong. :frowning:
I am giving up for now.


[quote=221650:@Sascha S]Maybe this issue is related to (]this change in the Windows Framework?
Because it happens only on Windows?[/quote]

This is an IDE change not a framework change
Basically the message area proved to be a bottleneck if your app wrote lot of messages to the log very rapidly so we queue them and if the speed of the messages still exceeds how fast the message area can show them it will occasionally purge waiting messages just to keep up

It affects all platforms the IDE runs on

But has nothing to do with the debugger - absolutely 0

I am still trying to replicate this in a simple project but i fear it’s related to the projectsize.

I still can’t replicate the issue fully, but i get the “feeling” it is somehow related to Threads accessing mySQL Servers and Timers waiting for such Threads to reach NotRunning States.

So i’ve attached a sample project to <> which is running fine while debugged on OS X and freezing while debugged on Windows 7 running on Parallels 11 Pro.

Maybe someone can find out if it’s doing the same running on a real Windows 7 machine and if the Xojo IDE is not catching the issue in the debugger because a Stack is overflowing?

Just a hunch, but since timers in Windows are much slower than in Mac OS X ( >60 ms even when set shorter) could it be that your timer is set too short ?

Min resolution for Timers on Win is 15ms. Oh, and i’ve tested it with Timers with a period of more then 50ms :slight_smile:

Have you tried much longer than that ?

Yes Michel :slight_smile:

I think this is the first time i can’t work with a new Xojo release. Can’t get rid of those damn StackOverflow Errors :confused:
And i hope we will soon start a new Beta round, hopefully fixing “my issue”. :smiley:

This is by far one of the most impressive Xojo releases i’ve seen and i am really keen to start working with it :slight_smile: