In my code I have a timer that I call in one spot with Xojo.Core.Timer.CallLater. This method I am calling is basically a method that will reset a TCPSocket if the socket doesn’t receive any data by the time the timer fires. In the DataAvailable event for the socket, I cancel the timer via Xojo.Core.Timer.CancelCall.
Sometimes, but not always, I’m getting a Xojo.Core.IteratorException with the value: “Dictationary was mutated while iterating over it”
But I don’t have a dictionary that I am messing with so I am assuming something is going on with a dictionary in the framework code for the timer. I’ve always had a problem with exceptions in the framework that I can’t control being raised. But I’m also wondering what may be causing this to happen. Am I doing something wrong? I was wondering if perhaps the timer was in the process of executing and from a thread I’m trying to cancel it at the same time. Nope. That’s not it. It’s all in the main thread.
So what could be causing this? Is this a Xojo issue (personally, if the framework has an unhandled exception, then I think it IS a Xojo issue but I can’t prove it reliably enough to write an example project and file a bug report) or is this something I might be doing to trigger it?
I guess for now, I’ll put a try/catch block around the CancelCall statement and see what happens with that.
An iterator exception should never ever happen. You’re not doing something wrong.
I know exactly what you mean about filing bug reports while not being able to make a proper example.
In this case, I tried: <https://xojo.com/issue/41954>
…but as expected, it was shot down for that reason.
For what it’s worth, I’m using Katkosoft Persistant timer. It’s the same but uses Variants instead of Auto’s.
If you add a few extra ‘if dictionary.haskey’ -checks around the dictionary.remove’s, then it’s rock solid. And I use it a lot.
Shot down is a bit hyperbolic
A report that has no means to reproduce the issue isn’t useful
Its like going to the mechanics and saying “Something is wrong with my car” but not being able to tell him what or how to notice the issue. Just that “something” is wrong. Yes he could take your entire car apart & maybe find it, or not, but the bill you’d get is certainly going to be very large.
However, the report being closed doesn’t mean “And don’t ever bother us about this again”.
Its simply that “we have no idea how to reproduce this or see the issue so this report is closed for now”.
Should you find a way to reproduce it, or someone else does, add to the report & it will reopen and we can reevaluate it at that time.
You’re certainly not the only one who gets “Closed” statuses on their reports because we can’t reproduce it.
I have a number that I’ve noticed while working on the IDE that I then go back to reproduce & can’t.
1.) Multiple users (at least two of us - Marco and myself) are experiencing the issue.
2.) The framework is taking and raising an unhandled exception in its code to the user (a no-no really)
3.) The exception happens in the Xojo.Core.Timer class
4.) More specifically the exception happens in the Xojo.Core.Timer.CancelCall method of the timer class.
5.) The exception happens when the framework code is iterating over a dictionary which is in all likelihood in the Xojo.Core.Timer class
So with this kind of direction and instruction, I don’t think Xojo needs to take the entire car apart to find the problem. We’ve told you where the problem is. There can’t be that much code and that many dictionaries in the Xojo.Core.Timer class. I’m sure the timer has a set of dictionaries it uses to manage all the different methods that it has to handle. There should be no reason for this to happen.
Here’s a stack trace of the error. Maybe that will help…
So somewhere there’s a .MoveNext method that is being called and this is where this looks to be happening…
Sometimes when it’s oddball framework stuff like this we can’t duplicate it easily. Getting a bug fixed should not require the users, (i.e.: us), to be able to prove it with an example, particularly when we have given you a map to where the problem is located.
I’m bumping this up as it’s never been addressed. I’m still getting reports/seeing examples of the Xojo.Core.Timer IteratorException error.
It would be nice if Xojo would fix this problem as it is in their code. Joe once said he thought it was fixed, but it’s not. So a year later and it still happens. I’ve stopped using CallLater as a result in most cases…
Just happened to me too… Anyone using threads? Could this due to multiple calls to Timer.CancelCall from different threads? I think at one point a thread is calling Timer.CancelCall while another thread is already in that function iterating a dictionary somewhere causing this exception, much like if you try and modify a Xojo.Core.Dictionary while iterating it.