About Us
Products
Purchase
Downloads
Support
Forums
Contact Us
Site
 Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
kjaerhus
Magician


Joined: 18 Dec 2006
Posts: 317
Location: Denmark

PostPosted: Sun Jan 25, 2009 12:51 am   

Debugging problems
 
I have some problems with my current scripts. They may run for a while but at some point I'll get "invalid pointer" errors or CMUD will simply freeze leaving me with no alternative but to kill it the hard way.

I wonder if there is any way to tell exactly what caused the problems. The error window with the stack trace I'm not sure what to get from - I don't recognize anything there. The script debugger doesn't help me much either I think. What do you guys use when things are blowing up?
Reply with quote
kjaerhus
Magician


Joined: 18 Dec 2006
Posts: 317
Location: Denmark

PostPosted: Sun Jan 25, 2009 10:07 am   
 
To be more specific: Is there by chance a way to see which line in the script that caused the exception?
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sun Jan 25, 2009 2:32 pm   
 
The stack trace isn't for you, it's for Zugg - in normal operation, CMUD shouldn't produce exceptions no matter what your scripts do (except, perhaps, if they outpace your memory). Post the crash report here and Zugg should hopefully be able to discover the problem.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
kjaerhus
Magician


Joined: 18 Dec 2006
Posts: 317
Location: Denmark

PostPosted: Sun Jan 25, 2009 2:43 pm   
 
Fang Xianfu wrote:
The stack trace isn't for you, it's for Zugg - in normal operation, CMUD shouldn't produce exceptions no matter what your scripts do (except, perhaps, if they outpace your memory). Post the crash report here and Zugg should hopefully be able to discover the problem.

I guess I could try but I never got any feedback from submitting the crash report so I have kinda lost faith in that method. And I do get a lot of crashes so I'm surprised that you say that it should never happen although I definitely agree.

Still it would be nice if you could tell where the scripts went wrong. My scripts are a bit too complex to just make a guess.
Reply with quote
kjaerhus
Magician


Joined: 18 Dec 2006
Posts: 317
Location: Denmark

PostPosted: Sun Jan 25, 2009 3:13 pm   
 
Fang Xianfu wrote:
Post the crash report here and Zugg should hopefully be able to discover the problem.

Suddenly I realized you suggested to post it here. Did you really mean that or did you mean to send it using the CMUD exception window?
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sun Jan 25, 2009 5:29 pm   
 
I meant what I said, posting it here. The crash report system as it stands is a little difficult to link with specifically-reported threads - posting the report in the thread is the best solution. Use the [code] tag.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
kjaerhus
Magician


Joined: 18 Dec 2006
Posts: 317
Location: Denmark

PostPosted: Sun Jan 25, 2009 5:59 pm   
 
Well, here is one I just got - hope you can make something of it. I changed personal information to X'es.

Code:

date/time         : 2009-01-25, 18:54:48, 312ms
computer name     : XXX
user name         : XXX <admin>
registered owner  : XXX
operating system  : Windows XP Media Center Service Pack 3 build 2600
system language   : Danish
system up time    : 8 hours 18 minutes
program up time   : 7 hours 58 minutes
processors        : 2x Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz
physical memory   : 898/2046 MB (free/total)
free disk space   : (C:) 3,52 GB (D:) 82,84 GB
display mode      : 1440x900, 32 bit
process id        : $1848
allocated memory  : 65,21 MB
executable        : cMUD.exe
exec. date/time   : 2008-12-16 20:08
version           : 3.3.0.1
compiled with     : BCB 2006/07
madExcept version : 3.0h
contact name      : XXX
contact email     : XXX@XXX.dk
callstack crc     : $ea9eaa50, $805d06c6, $805d06c6
exception number  : 4
exception class   : EAccessViolation
exception message : Access violation at address 00471919 in module 'cMUD.exe'. Read of address 00000029.

Main ($1a00):
00471919 +049 cMUD.exe     Classes                  TStringList.Destroy
00404da4 +008 cMUD.exe     System            38  +0 TObject.Free
0064516c +01c cMUD.exe     dbutil           188  +2 FreeList
00646b2b +07b cMUD.exe     dbutil           674  +5 NumItems
00d51aa7 +1c3 cMUD.exe     PrefDat         6420 +26 PkgData.DefineClass
00d591d3 +1ff cMUD.exe     PrefDat         9540 +26 PkgData.StripClass
00d6d1e1 +191 cMUD.exe     CodeExec        1601 +25 HandleVarRef
00d73275 +4e5 cMUD.exe     CodeExec        3299 +79 TCodeExec.InternalExecute
00d69c6f +08f cMUD.exe     CodeExec         562 +12 TCodeExec.Expression
00d5ebb0 +0a0 cMUD.exe     PrefDat        11607 +12 TCacheNode.GetCaption
00d5ad10 +0b0 cMUD.exe     PrefDat         9999 +16 PrefRec.InternalGetCaption
00d5ae0d +00d cMUD.exe     PrefDat        10038  +1 PrefRec.GetCaption
00d4b0c0 +04c cMUD.exe     PrefDat         2568  +5 StatusRec.Invalidate
00c7157b +10b cMUD.exe     PARENT         12359 +27 TParentForm.WMInvalidatePref
004bb023 +2bb cMUD.exe     Controls                 TControl.WndProc
004bf027 +4fb cMUD.exe     Controls                 TWinControl.WndProc
004a1587 +553 cMUD.exe     Forms                    TCustomForm.WndProc
00beefec +020 cMUD.exe     DXSounds        2128  +9 TCustomDXSound.FormWndProc
00bec790 +00c cMUD.exe     DXClass          635  +1 TControlSubClass.WndProc
004be750 +02c cMUD.exe     Controls                 TWinControl.MainWndProc
0047c400 +014 cMUD.exe     Classes                  StdWndProc
7e42a993 +016 USER32.dll                            CallWindowProcA
006d3e4f +0a7 cMUD.exe     aqDockingUtils  1728  +7 CallDefWndProc
006d3f3d +0dd cMUD.exe     aqDockingUtils  1776 +41 TaqWindowEventFilter.WndProc
0047c400 +014 cMUD.exe     Classes                  StdWndProc
7e4196c2 +00a USER32.dll                            DispatchMessageA
004a96fc +0fc cMUD.exe     Forms                    TApplication.ProcessMessage
004a9736 +00a cMUD.exe     Forms                    TApplication.HandleMessage
004a9a2b +0b3 cMUD.exe     Forms                    TApplication.Run
00df3228 +088 cMUD.exe     CMUD             352 +20 initialization
7c912c01 +069 ntdll.dll                             RtlUnicodeStringToAnsiString
7c812c24 +0b6 kernel32.dll                          GetVersionExA
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Jan 26, 2009 6:13 pm   
 
Looks like there is a problem with one of your Status bar items. You'll need to show us the code for your status bar items for us to help more.
Reply with quote
kjaerhus
Magician


Joined: 18 Dec 2006
Posts: 317
Location: Denmark

PostPosted: Mon Jan 26, 2009 10:12 pm   
 
My statusbar:
Code:
<stat name="Statusbar" priority="1360" id="45">
  <value>Roundtime: @//DragonRealms/Capturing/Roundtime/roundtime     Weapon: @//DragonRealms/Display/Statusbar/weapon     Armor: @//DragonRealms/Display/Statusbar/armor     Tool: @//DragonRealms/Display/Statusbar/tool     Mindstate: @//DragonRealms/Display/Statusbar/mindstate</value>
</stat>


It's probably the tool variable that causes the problem then as it's usually blowing up at times when I choose a tool. The tool choosing alias looks like this (takes parameter $toolkey) (notice I set the variable for the statusbar here):
Code:
$currentToolRef = @getToolsVarRef("currentTool")
$tools = @{@getToolsVarRef("tools")}

$toolName = %db($tools, $toolKey)
#IF ($toolName == "") {
  #SAY "Illegal tool index"
} {
  #IF ($toolName == "-") {
    #SAY "No tool currently assigned"
  } {
    setVar $currentToolRef $toolKey
    //DragonRealms/Display/Statusbar/tool = $toolName 
  }
}


And my get tool alias looks like this:
Code:
$currentTool = @{@getToolsVarRef("currentTool")}
$tools = @{@getToolsVarRef("tools")}
$toolPlacement = @{@getToolsVarRef("toolPlacement")}
$toolBagTypes = @{@getToolsVarRef("toolBagTypes")}
$toolBags = @{@getToolsVarRef("toolBags")}

$toolBag = %db($toolPlacement, $currentTool)
$toolBagType = %db($toolBagTypes, $toolBag)
$toolBagName = %db($toolBags, $toolBag)
$toolName = %db($tools, $currentTool)

#IF ($toolBagType == "CLOSED") {
  fbCommand "open my "$toolBagName "" "hide"
}

fbCommand "get "$toolName" from my "$toolBagName "" "hide"

#IF ($toolBagType == "CLOSED") {
  fbCommand "close my "$toolBagName "" "hide"
}

Theres a lot of references to items I have not included. There are so many. Just tell me if you want me to include something. And thank you very much for your time. I've been stuck on those issues for a long time.
Reply with quote
kjaerhus
Magician


Joined: 18 Dec 2006
Posts: 317
Location: Denmark

PostPosted: Mon Jan 26, 2009 11:25 pm   
 
To add a little more information: I've tried to change the way I access the statusbar variables in order to verify your theory, Mike, and it seems that my script is running much better now - at least I haven't got any exceptions since I made the changes.

There were two variables on the statusbar that I was accessing a lot during the script: tool and mindstate. I removed the place in the script where I touched the mindstate variable and made get/set methods for accessing the tool variable. In both methods the access to the variable is in sections named the same. So setTool alias will look like this:
Code:
<alias name="setSBTool" id="18417">
  <value>#SECTION SBToolSection {
  //DragonRealms/Display/Statusbar/tool = $toolName 
}</value>
  <arglist>$toolName</arglist>
</alias>


...and getTool function looks like this:
Code:
#SECTION SBToolSection {
  #RETURN @tool
}


So far so good. However it seems the statusbar is not very keen on refreshing when I reference a function instead of a variable. When my script is changing the tool with the setTool alias it seems to update the statusbar with the new toolname but if I call the setTool alias from a macro the statusbar will not show the change of tool although the underlying variable has been changed.

Anyway, I'm still looking forward to hear your conclusions on what exactly is going wrong in the script. I just wanted to share my new experiences with you.
Reply with quote
kjaerhus
Magician


Joined: 18 Dec 2006
Posts: 317
Location: Denmark

PostPosted: Wed Feb 04, 2009 5:57 pm   
 
I'm not sure if you forgot about this thread, Zugg, or whether it's on your todo but here's a little update now that I've taken most variable references off the statusbar. I have been running scripts without all those nagging exceptions which leads me to believe that all my problems was related to this. No wonder I couldn't find any pattern in the exceptions as it was not my scripts themselves that blew up.

It seems to me that there must be a problem with this statusbar when multithreading. To get fast updates I need to reference variables directly it seems but then I cannot enclose the access in a section. If I use a function on the other hand the statusbar will not be updated right away when the underlying variable changes.

Seems to me that CMUD lacks a way of enclosing variable references from the statusbar in sections. Is there a solution to this?
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net