This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

Crash in version 4.03!

Posted by Shadowfyr on Wed 18 Apr 2007 06:19 AM — 21 posts, 86,540 views.

Shadowfyr USA #0
I have mine set up to do several things:

On connecting, it sets a variable to ID me as starting for the day. Later I do "setquit on", which activates a trigger and sends an inventory command. This command tests to see if my inventory contains any items other than those that autoload, like my druid belt. If none are found, it turns on an alias that lets me type "quit". Typing Quit actually sends xyzzq to the mud, which is aliased to "quit", while the normal quit command it disabled. This is to prevent my logging off when still carrying equipment.

Everything works fine, until I type "quit" (or the aliased xyzzq command), then the client attempts to disconnect and crashes. Not sure if its something that changed with scripts (mine are all vbscript though) or something else. :(

This is in the new 4.03 btw.
Amended on Wed 18 Apr 2007 06:22 AM by Shadowfyr
Nick Gammon Australia Forum Administrator #1
I am having trouble understanding which part is causing the crash. Can you try to narrow it down? Is it the alias? If so, can you post it? Is it something to do with scripting? Is it a trigger firing?

Something that helps to reproduce it would be helpful.
Nick Gammon Australia Forum Administrator #2
There are a number of changes that might potentially cause problems:

  • New Lua DLL - although you say you aren't using Lua
  • New PCRE regular expression handler - all aliases and triggers go through this
  • New management of default directories (eg. world files) - maybe it might happen on saving the world


It would help if you can work out which part is probably causing the problem. Eg. save the world manually, change the wording of the alias so it doesn't disconnect but still fires, that sort of thing.
Shadowfyr USA #3
I have no clue what is causing it. Even if I just type "xyzzq", without going through the normal process, the client just crashes, and without displaying any of the lines that normally appear when logging out. I suspect, its crashing the moment the mud disconnects, so the output window never has a chance to update with the last lines. It *may* be somehow involved with logs, since you changed that too, and I started using the global setting for the log directory prior to this.

In other words, if I am right, then the client sends the quit command, detects that the connection closed, then attempts to close the log file and *boom!*. But that is just a guess.

Hmm. Ok, a new world using it doesn't cause the problem either, not even after setting the auto-log. So the problem seems to be some place else. Sigh... It crashed instead when I tried to close the client this time, so it may be in scripting, all of which is vbscript for me. Not sure if its some odd general problem that just cropped up or some specific plugin/script operation though. Its like 12am here, so I don't have time to really fiddle with it and find out. :(
Shadowfyr USA #4
BTW, something changed recently on the server your site is on. Instead of a post returning to the "page" you posted from, its instead displays the updated page with the new post, but with a URL of "http://www.gammon.com.au/forum/bbshowpost.php";. The result is that if you click on "reload" it tries to repost the message or something and can't display the page a second time, since there is no subject ID to tell the database *which* post is being dealt with. This means you have to back out to the "Bug Reports" section entirely, then reload the page from the original post link. This is in Firefox, so I have no idea if the behavior is also broken in anything else. Its starting to annoy me though, since it used to work right, but for the last 4-5 days its been broken. :(
Nick Gammon Australia Forum Administrator #5
It has always done that. Directly after posting, reloading the page re-sends the post. There is a test on the forum to discard double-posts if someone has done that.

Click on the "Refresh page" link at the bottom of a forum page to refresh it, that is safer.
Nick Gammon Australia Forum Administrator #6
I'm trying to reproduce but no success so far. I have tried aliases, triggers, forcing a disconnect (Connection menu), typing "quit". So far, nothing.
Nick Gammon Australia Forum Administrator #7
See if you can narrow it down to a particular plugin (eg. remove them one by one). Also try disabling all triggers and aliases (and scripting), see if that makes a difference.
Shadowfyr USA #8
Ok, have you tried loading an older pre-Lua vbscript based plugin or script, then trying it to disconnect, etc.? Maybe somehow something got glitched in the VBscript load/unload.. Hmm. Going to have to wait for tomorrow to nose through this mess on my end and see if I can find it. Got to get to sleep. :(

BTW, I do think the forum is behaving different though, I distinctly remember it *including* the "?bbsubject_id=7814&page=1" part in the URL *after* a post before, or I think so. I certainly don't remember it a) double posting or b) forgetting what page I was on and only showing the "http:.../bbshowpost.php" part without the thread number or current page. :p
Amended on Wed 18 Apr 2007 07:20 AM by Shadowfyr
Nick Gammon Australia Forum Administrator #9
I tried the Chat plugin, which is VBscript. Still no problems. You say it doesn't happen with a new world, so we need to work out what it is in your main one that does it.

Like I said, try disabling various things, until the crash goes away (save a copy of the world, and do it to that).
Nick Gammon Australia Forum Administrator #10
Quote:

I do think the forum is behaving different though ...


Not so sure about that. When you submit a new posting, it is a "post" method rather than a "get" method. The post method (ie. clicking the button) does not send the subject ID on the URL. I have noticed that for ages. Directly after making a post, I have to go up a level and drop back down, to see what the subject ID is (thread number), because it has just been allocated.
Amended on Wed 18 Apr 2007 07:34 AM by Nick Gammon
David Haley USA #11
I've seen the same behavior Nick has, I haven't noticed any changes at all in the forum.
Nick Gammon Australia Forum Administrator #12
Let me show you, the forum hasn't even been changed this year. This is a directory listing of the forum directory:


-rw-r--r--    1 username   group     13509 Aug 21  2006 bbsearch.php
-rw-r--r--    1 username   group     34188 Aug 21  2006 bbshowpost.php
-rw-r--r--    1 username   group     12461 Jul 20  2006 bbshowbio.php
lrwxrwxrwx    1 username   group        14 Dec  6  2005 index.php -> bbshowpost.php
-rw-r--r--    1 username   group     11815 Dec  5  2005 bbuserlist.php
-rw-r--r--    1 username   group     40917 Dec  5  2005 bbuseredit.php
-rw-r--r--    1 username   group      9043 Dec  5  2005 bbupdatetopic.php
-rw-r--r--    1 username   group      5220 Dec  5  2005 bbupdatesubject.php


The forum changed last in August 2006, which agrees with this announcement about different handling of the URLs:

http://www.gammon.com.au/forum/?id=7287
Nick Gammon Australia Forum Administrator #13
If anyone else can reproduce a crash I would be happy to hear about it. The last thing we want is buggy versions around.
Shaun Biggs USA #14
I'm getting crashes too, but on the opposite end of the world connections. With 4.03, I can open MC fine and poke around with the global configurations and all, but when I load up a world file, or even start up a new one, I get a crash. This happens even if I'm using the /wine argument. If I'm reading the error log from wine correctly, Lua was the last thing running. Lua5.1.2 was running fine when I swapped the dlls earlier (last version I was running was 4.01).

Edit: I've switched to 4.02, and everything is running smoothly, so it would appear that the issue was somewhere between 4.02 and 4.03 as Shadowfyr said. I'm going to tinker with 4.03 a bit in a different user account so that it's completely isolated. Hopefully I can get some information out of it.
Amended on Wed 18 Apr 2007 02:10 PM by Shaun Biggs
Nick Gammon Australia Forum Administrator #15
I think I have found it. There was an obscure problem with a CString object, which was statically declared, not correctly decrementing its reference count under certain circumstances. This part of the code has been reworked, and it seems to run reliably now.

As far as I could see you could trigger it by adding a plugin, which had a state file, and then closing the world.

The code was part of the stuff introduced in version 4.03 to fix the "wrong directory" problem that Shadowfyr had been talking about.
Shadowfyr USA #16
Ok.. I have narrowed the problem down to the "main" script file. When I disable script, the problem goes away, so the issue in with the main script. Now.. I use several callbacks in that script for connecting and disconnecting, some color changing code for some stuff in there, etc. What ever the problem is, its in there. My guess is that the problem is someplace "in" the code for closing a connection:

sub Terminate
  save ""
  if getvariable ("AReconnect") = "ON" then
    aa = now
    do
      cc = abs(datediff("s",aa,now))
    loop until cc > 1
    connect
  else
    if getvariable("ResetND") = "True" then 
      setvariable "FinalTime", -1
      if isplugininstalled("b5a12674355d40240455d8a1") then
        callplugin "b5a12674355d40240455d8a1","ResetIcons","Null"
      end if
    end if
  end if  
end sub


Though, I don't see anything in there that should be doing that. There isn't any other code I know of that should be called on disconnecting...

The "connect" code is:

sub Start
  setvariable "QuitSW", "OFF"
  setvariable "Stored","YES"
  setvariable "ResetND","False"
  NotecolourRGB &hFF9E3E, &h00
  if cint(getvariable("FinalTime")) = -1 or datediff ("s",getvariable("CurConTime"),now) > 28800 then
    hr = 2
    setvariable "FinalTime", hr * 60 * 60 '14400 = 4
    setvariable "CurConTime", now
    resettimer "ShowTime"
  end if
  setvariable "SExp", 0
  setvariable "LExpAvg",0
end sub


I also have the callback for "Close" set:

sub Close_World
  set winamp = Nothing
  setvariable "FinalTime", -1
end sub


But that can't be the problem, since I am not closing the world when merely disconnecting.

Now, obviously, since this happens even if I send the server aliased "xyzzq" command, its not anything called by an alias that is doing this. That still leaves a big chunk of code that deals with updating the status bar that does happen constantly when connected too. Nearly 1/4 all the code in my main script deals with that. The rest is miscelanious stuff that I haven't bothered to move to a plugin.

Hmm. Is there something wrong with 'save ""' now maybe? Let me check on that.
Shadowfyr USA #17
***Yes!!!*** Its the line that has 'save ""' in it. That is crashing the client. When that line is commented out, it doesn't crash at all. That narrow enough for you? lol
Shadowfyr USA #18
Bah.. You fixed it before I had a chance to hunt the problem down. lol But yeah, I kind of suspected it might be in the new code for the directory paths, which makes sense given what was crashing it.
Nick Gammon Australia Forum Administrator #19
Thank you for narrowing it down. At least that confirms my analysis. Hopefully you will also find that 4.04 works correctly.

For anyone interested, I think the roots of this problem go the problem of a race condition between statically-created classes. Take for example:


(File A.cpp)

someClass X;

------- (and in another source file)  -------

(File B.cpp)

someOtherClass Y;


Now if X and Y are outside any function they are "static" - that is they reside in main memory and not on the stack of any particular function call.

Let us assume that Y uses X in some way. For example, X is a string, and Y is something that requires knowledge of X. For example X is some global thing (like, a default directory).

Now we have the question of the construction order. Since X and Y are not inside a function they must be constructed at program startup time. Let's assume that the way things are linked together all the constructors for file A are called first. Thus, X is constructed (and is now valid), and then Y is constructed. So far, so good. When X refers to Y, Y is valid. We already have a problem if the order was reversed, because Y would use X before X became valid.

Even so, we have a problem with destructors. Assuming the compiler calls destructors in the same order (File A and then File B), then X is destroyed first, and then Y. However Y needs X and crashes when it tries to use the (now destroyed) X.

I think the problem does not exist with classes in the same compiled file, because the compiler is smart enough to maintain a list of all the static classes in that file, and call the destructors in reverse order to the constructors. Thus it would destroy Y and then X, which would be OK in this case.

This sort of bug is particularly insidious, because in a sense the programmer hasn't done anything "wrong", and what has been done would be OK in a single source file.

I *think* this is the root of the problem, however I also read about another possible problem, that with statically created classes (like strings), that if you happen to create them in one place, but use them in another place (like a DLL), then the DLL uses a different memory space to the main program, and the memory allocation is done in the wrong place. The script engine (VBscript in this case) runs in a DLL, so possibly the call to a function in the main program, which happened to use a static string, was to blame.

In any case, the code in question has been reworked to not use a statically declared string. :-)
Shadowfyr USA #20
How fun.. lol But, I don't think it was the memory address issue, but the X then Y, so Y then X one. It was crashing even if I just clicked the "save" button on the toolbar. :( Its working correctly now.