Python Chat functionality crashes the client.

Hey,

I've had this problem quite a bit now that often when/if I return a wrong type from a function regarding the chat-system, mushclient seems to crash. It's getting hard to debug this kind of issues and I'm wondering if there shouldn't be some sort of error-handling regarding these functions?

I'm not sure what my issue is right now but as soon as I try to connect with my script, mushclient crashes. In order to solve this I basically have to set up a few extra mushclients and do a type of divide-and-conquer solution by starting out with a really thin version of my script and adding things to it part by part. Each time mushclient crashes, I have to reboot my computer since there seem to be an issue with dangling information influencing outside of Mushclient's scope. I have come to this conclusion since it has solved my issue several times by simply rebooting my computer.

So I'm asking again, can there please be error-handling regarding these kind of things? If I had the time on my hands to look into it in the mushclient-source I would, but unfortunately I don't have that time on my hands. Is the wrapper-API you guys are using really that crappy?

Cheers,
Simon

To be fair, there have been virtually no reports of crashes using Python. Searching for "crash" in the Python section reveals one post in May 2010 which reports a crash to do with multi-threading.

Beyond that, it is mostly "type mismatch" error reports (about one a year) which seemed to be because of Python's stricter type checking.

The interface between MUSHclient and the Windows Script Host is identical for all script languages, except Lua which is hard-coded. The *only* difference is the name of the script engine which is instantiated. So if there is a really buggy implementation, then VBscript, PerlScript, JScript etc. should all be crashing as well. So this points, to me, to the Python implementation, not the MUSHclient implementation.

Once MUSHclient hands control over to the script engine DLL, there isn't much it can do it the DLL happens to crash, loop, gobble up memory, or do other strange things. Just as an example, a while back if you got a syntax error using PHPscript, the client just exited back to the operating system. Why? Because the script implementors thought that after reporting an error message they should call exit (0) to exit the script. They forgot that a script might be called by a program that didn't want to exit just then.

I'll try to track this down, but bearing in mind this is the first report from you about a crash, perhaps a more mildly-worded complaint might be in order.

Also, when you started this message you were asked for (in bold type in the hope that it would be noticed):

• The version number of MUSHclient you are using
  
• The error message you get, if any
  
• The code that would reproduce the problem
  
• In your case, the version of Python you use might be helpful

Armed with that information, it might be possible to reproduce it. And it might be possible to fix it.

In another thread you said:



Well, world.GetChatList is indeed a function in MUSHclient. So if Python starts changing functions to variables you have to wonder what else it is doing.

I should also point out that a Google search for "activepython crash" returns "About 19,400 results". A search for "crash" in the Python section of the forum here returns 9 results, some very old.

Hey Nick, and thanks for your answer.

I did report about one crash in OnPluginChatDisplay, if you follow this link:
http://www.mushclient.com/forum/?id=10683, which was solved by basically returning the correct type.

I'm sorry that I didn't provide more information. The crashes occur in .64, .65 and .66. Most likely it occured in .63 but I have no logs of that. I'm using python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]. The crash indicates a null-pointer call. I've tried looking into the callstack but since I don't have any debug-symbols (and haven't built the code), I'm unable to look into it further.

I'll supply my entire script so that you can reproduce it. Incidentially it doesn't seem to happen from all machines: It happens from my 64-bit i7 at work running win7 but not as much from my 32-bit laptop running win7.

It seems like one of the cases where it does crash more often is when I had a reconnect-dialog up in my server-side chat-mushclient and trying to connect with either my laptop or my work-machine would yield in a mushclient-crash.

I'm supplying you the entire python code, it might not be the best-looking around though.

One mushclient should do
rmt accept

while the other should do
rmt name tapir
rmt connect xxx.xxx.xxx.xxx

which should yield the crash.

If I get the time I could try to download all the code and reproduce it with debug-symbols but that would most likely be in 1-3 months and I would be extremely happy if this issue was solved before that.

Code at:
http://pastebin.com/n76sa6ws

Could it be that the scripting-wrapper that you're using is doing funky things like this? I doubt that python suddenly decides to change a function to a member.

Returning the wrong type from a plugin-callback has previously shown me either crashes or infinite loops of an error message similar to "wrong type" (I think this was the case with OnPluginChatDisplay where returning True/False did not work but I was required to return 0 or 1). I guess that could be related.

I don't really want to spend hours looking for a bug in code that was released in February 2008 - especially a null-pointer call on an error. Hopefully it has been fixed in the last 2.5 years.

According to:

http://www.activestate.com/activepython/downloads

The following versions are available for download:

• ActivePython 2.6.6.15
  
• ActivePython 2.7.0.2
  
• ActivePython 3.1.2.4
  
• ActivePython 2.5.5.7

It isn't clear the differences between them, nor can I find release notes which might clarify if a crash was fixed due to a bad return type.

But really, over two years is a long time in terms of scripting engines and bug fixes. I would try a later version. Especially as you are getting problems in Windows 7. According to Wikipedia: "Windows 7 was released to manufacturing on July 22, 2009, and reached general retail availability on October 22, 2009".

So the version of Python you are using was released over a year before Windows 7. It doesn't totally surprise me you are having problems.

No. Why would I do that?



There is nothing in my interface that changes behaviour depending on whether or not the function being called takes arguments. My guess is that Python "helpfully" notices that the function takes no arguments, and says to itself "well since you can't supply arguments the brackets are redundant", so it expects you to omit them. Then if you put in the brackets it thinks the thing the function has returned has to be called.

In other words, it's turned it into what the WSH calls an "attribute". Which makes me wonder: what would it do if you tried to use something you really did define as an attribute in the WSH binding? :S

Strangely enough, I had Python 2.5.2 installed, and tested your chat callback that you said caused a crash:


Version = 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit (Intel)]
Modules = ('__builtin__', '__main__', '_ast', '_bisect', '_codecs', '_codecs_cn', '_codecs_hk', '_codecs_iso2022', '_codecs_jp', '_codecs_kr', '_codecs_tw', '_csv', '_functools', '_heapq', '_hotshot', '_locale', '_lsprof', '_md5', '_multibytecodec', '_random', '_sha', '_sha256', '_sha512', '_sre', '_struct', '_subprocess', '_symtable', '_types', '_weakref', '_winreg', 'array', 'audioop', 'binascii', 'cPickle', 'cStringIO', 'cmath', 'collections', 'datetime', 'errno', 'exceptions', 'gc', 'imageop', 'imp', 'itertools', 'marshal', 'math', 'mmap', 'msvcrt', 'nt', 'operator', 'parser', 'rgbimg', 'signal', 'strop', 'sys', 'thread', 'time', 'xxsubtype', 'zipimport', 'zlib')




Note that it worked - no crash, and displayed what it was supposed to. (This is Windows XP)

So I can't really accept that the MUSHclient interface is all that buggy.

Plugin here:

What I meant was the WSH. That's why I used the phrase "that you're using" not "that you've implemented".

Look, I'm not trying to point fingers here or try to say that Mushclient is crap, it's not. It's the absolutely best mudclient I've ever used. I'm really grateful for all the hard work you're putting into all of this Nick, you're often responding to implementing feature-requests faster than any other freeware software I've ever seen.

I'll try to install activepython, I've actually used the version recommended to integrate with windows from python-webpage, pywin32. I didn't know that mushclient recommended using activepython (I haven't really heard of it at all). That might clear up the issue.

The WSH hosts are basically DLLs. There is a fairly simple wrapper that looks up the names (eg. world.Note) in them and calls them, when required.

I *did* implement that, not totally understanding what I was doing, as the Windows documentation is sparse, to say the least, and doesn't seem to have improved much over 10 years.

However the wrapper I use is identical for all script languages, excepting Lua which doesn't use WSH at all.

Conceivably there should be a try...catch block in there for errors, but ever since scripting was implemented, VBscript - which uses the same wrapper - has never had any such problems. And after all, Microsoft wrote that. So I tend to think that some of the other scripting guys, when writing their DLLs, haven't quite done things right. Not totally blaming them because, as I say, the documentation is light.



Thanks!



Recommending is too strong a word. "Aware of" is about as far as I would go. Suffice to say that my test using the ActivePython download seemed to work. Why, I can't say.