Crash on IF statement

Windows 7
Xojo 2018R4
Web Application

  • x86 64-bit
  • Stand alone
  • Aggressive optimization

I’m in a method where it is assembling a string as a HTML report it is going to send down to the browser. I’ve waaay boiled down the code, but here is what I think is important:

DIM nOrder, nModResult AS Integer = 1
DIM strClass AS String = ""
WHILE NOT rsInspections.EOF
  nModResult = nOrder MOD 2
  IF nModResult = 1 THEN   // <-- This is the line that causes the IDE (and app when built as an EXE) to crash.
    strClass = ""
    strClass = " class=odd"
  nOrder = nOrder+1

In the IDE you can see that nOrder has a value of 1, and the nModResult has a value of 1. I moved out the MOD command into it’s own line but it used to be in the IF statement as IF nOrder MOD 2 = 0 THEN … but I pulled that out and tried switching to comparing it to 1 instead of 0. Crazy. Ideas?

Well for one thing your WHILE loop will never end… there is nothing to advance rsInspections towards its EOF
So perhaps it is because nORDER reaches an overflow condition (ie. becomes zero again)

Thank you for catching that omission. I have that in my code but I accidentally cut it out when preparing this post.

This crashes on the first loop through the recordset. We can see this because nOrder = 1.

The picture you posted did not come through. What kind of exception are you getting? Or is it a hard crash?

Image grabbed from OP’s post.

Hard crash as far as I can tell. I couldn’t trap an exception in the method.

Exception err As TypeMismatchException
MsgBox("Tried to retype an object!")
Exception err As NilObjectException
MsgBox("Tried to access a Nil object!")

Are you sure rsInspections is not nil?

Yes, it has data in it. This is the bad part of me boiling down the code a ton. I had already pulled out information from the RecordSet. The rsInspections.FieldCount = 31 and the rsInspections.RecordCount =27. I’m not seeing any NULL values in the RecordSet and I think that is before anything really happens with the data.

One thing I didn’t mention was that this is M$ SQL Server data … but I’m not sure why this affects an IF statement. I’ve already displayed a version of this data into a WebListBox on the screen. I’m just handling when someone hits a [Print] WebButton. Weird.

Here’s another weird thing: If I comment out that code, then my HTML is returned just fine down through the browser. It just doesn’t have the alternating CSS styling that I used to have working. Let me try changing this out to an inline-IF statement and see if that affects things.

As a test, please rewrite the code like this and tell us what happens:

  nModResult = nOrder MOD 2
  dim nModResultIs1 as boolean = nModResult = 1

  IF nModResultIs1 THEN

If it’s not in a xojo control then it is possible to do alternating rows in pure CSS. If you’re interested I can try to offer some help with that. But we should find out why the code is causing this issue, I’m quite curious.

This works:

// Commented out = nModResult = nOrder MOD 2
strClass = IF( nOrder MOD 2 = 0, " class=odd", "" )

Let me try out Kem’s scenario next.

Surprisingly, your code also causes the hard crash. Here’s how I entered it:

nModResult = nOrder MOD 2
DIM lModResultIs1 AS Boolean = nModResult = 1
IF lModResultIs1 THEN
  strClass = ""
  strClass = " class=odd"
// Commented out :: strClass = IF( nOrder MOD 2 = 0, " class=odd", "" )

This sounds like a Xojo bug that should be reported. Glad you can work around it though.

Does it crash if you compile for 32bit?

I might try creating a new Xojo Web project and see if I can get it to crash with a simple project. I don’t think the way I wrote that IF statement is that weird. I’d like to submit a project with a bug report to help get this resolved. We’ll see if I can reproduce it when I boil down the situation.

It doesn’t! Works like a charm! And then when I switched it back to 64-bit, the error occurred again. I was worried that it would be fixed when I switched back, but the error still occurred.

It seems odd when I ask but its the thing that comes to my mind first. I’ve got feedbacks in that are over 12 months old now about issues with 64bit in Windows, my last reproducible issue was 6 months ago. I never run Xojo apps in 64bit as I don’t trust them. If this were on Mac I suspect it would have been addressed by now /shrug

@Kevin J Cully – Please try the other two optimization levels just in case it’s specific to one of them.

Well this sucks. Everything is now working. I’m hitting our live server to produce this report, and as our inspectors are completing their assigned inspections, the data is reducing in size. Is that a lead on what is causing this? Who knows. I’ll have to try this again tomorrow morning when we have a fresh batch of inspections.

Here is what I was testing (notice how it changes over time):

32bit : Aggressive : Pass
64 : Aggressive : Fail
64 : Moderate : Fail
64 : Default : Pass
64 : Aggressive : Pass { Ugh!!! }

I’ll take this for another spin tomorrow morning.