Due to a type coupled with an unfortunately named routine in my window manager plugin, I discovered that when I call the global function SaveState (with or without arguments, which in my case would have included a meaningless set of nested tables) during OnPluginSaveState (but not, oddly, during OnPluginEnable), I cause MUSHClient itself to crash silently.
Crash when calling SaveState() during OnPluginSaveState
Posted by Manacle on Thu 30 Dec 2010 02:52 AM — 5 posts, 20,330 views.
This was, by the way, using MUSHClient v4.70, and the exact close that caused the error was:
function OnPluginSaveState()
SaveState(campaignwindow)
SaveState(questwindow)
SaveState(gquestwindow)
end
(editted to show the old code, not the new code that works)
function OnPluginSaveState()
SaveState(campaignwindow)
SaveState(questwindow)
SaveState(gquestwindow)
end
(editted to show the old code, not the new code that works)
SaveState does not take any arguments.
It simply causes the plugin state to be saved. Calling that in OnPluginSaveState is likely to cause a stack overflow, because you call SaveState which then calls OnPluginSaveState which then calls SaveState and so on until you run out of stack space.
SaveState
The documentation for the SaveState script function is available online. It is also in the MUSHclient help file.
It simply causes the plugin state to be saved. Calling that in OnPluginSaveState is likely to cause a stack overflow, because you call SaveState which then calls OnPluginSaveState which then calls SaveState and so on until you run out of stack space.
...when I call the global function SaveState (with or without arguments...
I'm sorry, I should have been more clear that I actually wasn't complaining about SaveState not working the way I thought it would (I actually meant to call WindowManager.SaveState, but I've since refactored that library so I can't make this mistake again).
I see though that it's not a bug or a use scenario that's worth detecting and handling gracefully. Thank you for your response and the explanation of what was happening.
I'm sorry, I should have been more clear that I actually wasn't complaining about SaveState not working the way I thought it would (I actually meant to call WindowManager.SaveState, but I've since refactored that library so I can't make this mistake again).
I see though that it's not a bug or a use scenario that's worth detecting and handling gracefully. Thank you for your response and the explanation of what was happening.
I have amended the client do disallow loops of this sort by detecting if it is saving its state and not allowing you to save it while it is being saved already.