Mac OSX
My application is now bombing when I run it, reporting an access violation. All was fine, nothing changed, it just started doing it. Every time I start it asks me if I want to allow access to desktop files and I click on yes.
Sonoma 14.2.1
Newest version of Xojo
I had been using a 2023 version of Xojo when it started doing this.
Is this as a built-app, or under the debugger?
Got a crash report?
Maybe something broke on your computer.
You need to determine where the cause is, or supply some sample, as this guy did for example
The program is filling an array of objects, by loading a text file for each object then converting the text into object properties.
The coincidental part is that I had just changed out the folder full of text files, and I had copied it over to the Mac from a PC.
The funny part is that on tracing my code, ALL of those files load correctly. The array has 255 objects in it, and they are all apparently fine. No nil objects in the array as far as I can see, and the code checks for Nil objects and won’t add a Nil object to the array.
Where it crashes, is in calling Sort on the array. A sorting method is provided. This has been working “forever”. The call is of the form: myArray.Sort AddressOf mySortingMethod
The error report is as follows:
“The application crashed due to an access violation. The debugger may show invalid values. Check the selected line, make corrections, and try again.”
The debugger stops in the compare method. It is showing a couple of Nil objects that have apparently been passed into the compare method. It doesn’t appear that any line of the compare method is highlighted.
The compare method:
Function KindsCompare(k1 As KindCls,k2 As KindCls) As Integer
const CurrentMethodName = “KindsMod.KindsCompare”
// report if a kind would sort before or after another kind
// sort order is (element letter, kind number)
// 1 means after, -1 means before
If k1 = Nil Then // put any Nils at the end
Return -1
End If
If k2 = Nil Then
Return -1
End If
If Asc(k1.elmLtr) > Asc(k2.elmLtr) Then
Return 1
ElseIf Asc(k1.elmLtr) = Asc(k2.elmLtr) Then
If k1.id > k2.id Then
Return 1
End If
End If
Return -1
End Function
It feels like a corrupted Xojo app. Though there is another Xojo app I tried and it crashes also. There is a third app I managed to run.
And its not bombing on entry to the Sort method.
Its happily sorting away then it gets the access violation error.
Could it be my computer runs out of memory?
Make a minimal sample mimicking the processing and error (using the same files being loaded by you?) and share.
Are you taking into account the different EOL chars? What does the code that loads the files look like?
The files are loading fine. The problem occurs in the method that is being passed to array.Sort.
That’s why I say, its coincidental I changed the files.
This is code that has been working for a decade, and EOL question was answered way back when. I can’t remember how I handled that!
But I do wonder, if there is something inside of Xojo that gets confused, because of some small difference in the Windows files vs Mac.
So I’ll pull the old version of the text file folder out of a backup, drop that in, and see whether it makes a difference. I will also try getting a backup of the app out, and trying that. See if I can make it go away.
Thanks for all ideas.
The question to be asking is whether you’re handling encoding correctly. They can be very different on Mac/Windows and if you’re not properly encoding, functions like Sort could be left to deal with strings containing null characters. IIRC, that could cause string truncation, and then these “access violation” crashes.
Ok thanks for that idea.
I found the file command, got into the folder in Terminal, and ran “file -I *.txt | more”
Looked at them all, all “text/plain; charset=us-ascii”
That’s good to know (if accurate) but it really depends on how Xojo is reading the files and assigning their encoding internally.
I got the TextEncoding for each file text string (ie the entire contents of the file).
All were “macintosh”
Though all the files load fine, and each file is converted into an object.
Where it bombs is in the method that I provided for sorting these objects.
I think the error message given seems like it should be with regard to one of my files, but I think its something else. The message is being generated by Xojo, which is evidenced by it mentioning the debugger. I think it may be more like some process accessing some other process’es memory.
So it just occurred to me to do the obvious. Take out the Sort.
And lo and behold, it runs.
I’m going to try reconstructing the sort method. I think there is some corruption in the Xojo app file.
I copied the code from the compare function into a new function, changed the Sort call to call this new function, and it still bombs.
I looked up “access violation” and it does indeed refer to a process accessing memory it does not own. A bad pointer in the system, and that I presume would be inside Xojo, not user code. This is not C. So in any case…next question. What is a good way to rebuild an app from scratch, short of copying and pasting all the code one method at a time? Is there a way of decorrupting a Xojo app file?
That’s a good question.
Whatever you do, save a backup of your current project, before you do anything.
What project format is it saved in, Text, XML or Binary?
If I thought one of my projects were corrupted, I might try saving a copy to a different format (in a new folder) and see if that new version runs with the problem method. And if so, save it back to the format I prefer and see if it still works. But that’s just me.
Good luck.
Out of curiosity, have you tried putting a breakpoint at the line of the crash, running the app, and examining the variables (i.e. just before the crash)? You may see something abnormal there already.
My point is that Xojo doesn’t do anything automatically. You have to set it to what you expect when reading the file.
@Tom_Dowad - when you read these files, are you using a textInputStream or a binarystream?
It’s important to note that you shouldn’t be able to make your app crash like this without explicitly writing code to do so (for example, a Declare that attempts to read memory you don’t have rights to). Since this is happening in a framework function and you can easily recreate it, I suggest you bundle up the project and submit it too Xojo as a bug report.
Of course we can continue to try and narrow down the problem in the meantime - but reproducible framework bugs are super valuable to the Xojo team.
What is the purpose of this line?
I thought CurrentMethodName was a framework provided constant, in which case you shouldn’t be able to write to it. But I’m not at my desk to test my assumption.
Also, have you tried clearing the Xojo Cache, under Settings?