Descriptive Problem Summary:
Setting a mob's ckey to another ckey while it already has a ckey attached will not trigger Logout(). (this actually vaguely sounds familiar. I'm remembering a convo about this in our coder channel years ago, but I was unable to find a bug report on it.)
See post below with more details
ID:2282749
Aug 13 2017, 3:24 pm (Edited on Oct 10 2017, 2:23 pm)
|
|||||||||||||
Resolved
| |||||||||||||
I attempted to reproduce this but was unable.
Basically, the pattern is that we get a bad client runtime relating to some win* call followed almost immediately by a bunch of null ref runtimes relating to lists that are maintained by login/logout. I had thought the bad client runtime was a clue (as it showed just before the null ref runtimes in the last few cases). but it turns out it's likely just another symptom. I have of course done the normal checking for ..() on all of our Logout overrides. This was my first assumption. I'm not sure how Logout() could fail to be called at all, really. Ya, I started focusing on this after I was unable to reproduce with winexists or winget. And I found the answer! (as I was typing this post, because that's when all my best ideas happen) Setting a mob's ckey to another ckey while it already has a ckey attached will not trigger Logout(). (this actually vaguely sounds familiar. I'm remembering a convo about this in our coder channel years ago, but I was unable to find a bug report on it.) Normal (del()) client/New() Also normal (having the client run .reconnect) client/New() Abnormal (setting the mob's ckey to null.) client/New() |
Yeesh, I meant to get to this sooner. Apologies for letting it fall through the cracks. It probably won't get into the next release (I'd like to get that out today if feasible) but I'll see what I can do after that.
|
I'm not sure how Logout() could fail to be called at all, really.