Hunting a memory leak in Xojo Web target
A few months ago we saw memory leaks in the Xojo web engine. Sessions were not released properly. The suspicion was that somewhere in the web framework may be a weak reference. The bug was reported by me as 63687. By reproducing it with the official EEWeb sample project, it was clear that it's not my own code.This bug turned out to be a duplicate of 63378. And that one was fixed in April, so it may be in current test version and may go into verification and the next release. Hurray!
Now the hunt continues because while looking for the bug we got a little code to dump class counts. The code uses runtime object iterator to loop over all objects and counts how many of each class/vartype we have. Just counts on how many arrays of each type (integer, object, boolean, etc.) and what object classes via Introspection like how many Dictionaries, JSONItems, WebPages, etc. The print showed that with newer Xojo versions the EEWeb project leaks thousands of dictionaries. At least I would expect that when a session ends, we go back to the object counts we had before. Not for the first session as it initializes a couple of global objects. But when I let first session expire and then create 3 new ones and wait for those to close, the counts should go back to normal.
I wondered why we had so many dictionaries. For my test code I added code to dump those dictionaries to a text file. That showed a ton of dictionaries containing JavaScript snippets, probably stuff Xojo's web engine sent to the browser. Since the JSONItem class didn't show in my statistics, I wondered who would leak the dictionaries. The newer JSONItem in Xojo 2021r1 calls GenerateJSONString framework function internally, which is implemented in C++. Somewhere inside the reference court for the dictionary is increased, but later not decreased. The increase may be superfluous. Usually objects coming in as parameter don't need to be retained and released.
To demonstrate the problem to Xojo engineers, we got this snippet:
Sub Open()
System.DebugLog "Objectcount: "+Str(Runtime.ObjectCount)
Dim Responses As New JSONItem
Dim js As New JSONItem
js.Value("test") = "something"
js.Value("message") = "Hello World"
Responses.Append js
'Dim t As String = Responses.ToString
js = Nil
Responses = Nil
System.DebugLog "Objectcount: "+Str(Runtime.ObjectCount)
End EventHandler
System.DebugLog "Objectcount: "+Str(Runtime.ObjectCount)
Dim Responses As New JSONItem
Dim js As New JSONItem
js.Value("test") = "something"
js.Value("message") = "Hello World"
Responses.Append js
'Dim t As String = Responses.ToString
js = Nil
Responses = Nil
System.DebugLog "Objectcount: "+Str(Runtime.ObjectCount)
End EventHandler
If you run it, you may see that object count before/after is the same. Now if you uncomment the toString line, the object count raises by five in my test. The dictionary is not freed. And of course the various variant objects used here. In the EEWeb project this leads alone to over 1000 object leaks per session.
Let's wait and see if this can go into a bug fix release for 2021r1 soon.
My wish for the future would be to have a test project and on the todo list for a Xojo release to check memory usage/leaks. I wrote details into case 64459 and I hope Xojo Inc. will take this seriously. Feel free to subscribe/favorite the mentioned cases.