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
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Tue Nov 09, 2010 5:55 pm   

[3.31] Cmud doesn't exit gracefully when Windows 7 tries to reboot.
 
If I'm logged into a Mud and Windows 7 tries to shut it down to reboot, Cmud throws up all sorts of errors and fails to close gracefully.

Granted I should log out and close the session before closing Cmud, but this seems to be within the realm of an event Cmud should be able to handle gracefully.
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Nov 09, 2010 7:58 pm   
 
I'd need to see the details of the errors to help more with this. It doesn't happen to be here on Windows 7 at all.

Also, I'm sure you also already know that it's generally a very bad idea to show down windows without closing your apps first. Many apps do not save any changes when shut down in this manner. Windows does not send the proper Windows events to "gracefully" exit the app. Windows tries to just kill the app, which can cause data loss in some cases.

But in any case, I'm not seeing the errors here, so post the crash dumps and provide a procedure for reproducing it in a blank session if you can.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Thu Nov 11, 2010 5:49 am   
 
Here's the report:

date/time : 2010-11-10, 21:46:09, 65ms
registered owner : Microsoft / Microsoft
operating system : Windows 7 x64 build 7600
system language : English
system up time : 13 hours 33 minutes
program up time : 12 hours 59 minutes
processors : 8x Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz
physical memory : 2701/4029 MB (free/total)
free disk space : (C:) 32.09 GB
display mode : 2048x1152, 32 bit
process id : $fa8
allocated memory : 112.28 MB
executable : cMUDPro.exe
exec. date/time : 2010-10-15 12:41
version : 3.31.0.0
compiled with : BCB 2006/07
madExcept version : 3.0k
callstack crc : $f27fcb70, $6559d0f8, $6559d0f8
exception number : 1
exception class : EAccessViolation
exception message : Access violation at address 00F3290B in module 'cMUDPro.exe'. Read of address 00000000.

Main ($1754):
00f3290b +003 cMUDPro.exe MapList3 2251 +0 TMapNode.RemoveView
00ee9548 +028 cMUDPro.exe MapNew3 772 +3 TNewMapF.FormDestroy
004a5999 +031 cMUDPro.exe Forms TCustomForm.DoDestroy
004a57c7 +05f cMUDPro.exe Forms TCustomForm.BeforeDestruction
004052cd +009 cMUDPro.exe System 91 +0 @BeforeDestruction
00b7f1c6 +002 cMUDPro.exe MultiForm 337 +0 TMultForm.Destroy
00404eac +008 cMUDPro.exe System 91 +0 TObject.Free
00757157 +013 cMUDPro.exe zsPanel 312 +4 TzsPanel.DestroyForm
00757099 +00d cMUDPro.exe zsPanel 287 +1 TzsPanel.Destroy
004c212d +08d cMUDPro.exe Controls TWinControl.Destroy
004c9479 +01d cMUDPro.exe Controls TCustomControl.Destroy
007478e4 +0fc cMUDPro.exe aqDockingBase 3021 +31 TaqCustomDockingControl.Destroy
00404eac +008 cMUDPro.exe System 91 +0 TObject.Free
007479f4 +000 cMUDPro.exe aqDockingBase 3067 +0 TaqCustomDockingControl.Release
0073c9df +0cf cMUDPro.exe aqDocking 5186 +25 TaqDockingManager.ParentFormDestroy
0073f3ca +046 cMUDPro.exe aqDocking 6783 +6 TaqDestroyNotifier.ParentDestroy
0071ab50 +010 cMUDPro.exe aqDockingUtils 1714 +2 TaqWindowEventFilter.DoDestroy
0071acc3 +0b3 cMUDPro.exe aqDockingUtils 1768 +33 TaqWindowEventFilter.WndProc
0047d90c +014 cMUDPro.exe Classes StdWndProc
774400e3 +02b ntdll.dll KiUserCallbackDispatcher
75f8ef3b +047 USER32.dll SendMessageA
0071ace5 +0d5 cMUDPro.exe aqDockingUtils 1770 +35 TaqWindowEventFilter.WndProc
0047d90c +014 cMUDPro.exe Classes StdWndProc
774400e3 +02b ntdll.dll KiUserCallbackDispatcher
004a5843 +073 cMUDPro.exe Forms TCustomForm.Destroy
0052576e +012 cMUDPro.exe CustomForm 65 +1 TzCustomForm.Destroy
0075cf41 +019 cMUDPro.exe International 47 +2 TInterForm.Destroy
0075d9de +012 cMUDPro.exe zsForm 93 +1 TzForm.Destroy
00b7f1d6 +012 cMUDPro.exe MultiForm 340 +3 TMultForm.Destroy
0047c4cb +047 cMUDPro.exe Classes TComponent.DestroyComponents
004a36c2 +032 cMUDPro.exe Forms DoneApplication
004523ce +026 cMUDPro.exe SysUtils DoExitProc
00405d55 +021 cMUDPro.exe System 91 +0 @Halt0
004ae44c +3e0 cMUDPro.exe Forms TApplication.WndProc
0047d90c +014 cMUDPro.exe Classes StdWndProc
774400e3 +02b ntdll.dll KiUserCallbackDispatcher
0047d90c +014 cMUDPro.exe Classes StdWndProc
774400e3 +02b ntdll.dll KiUserCallbackDispatcher
76d23675 +010 kernel32.dll BaseThreadInitThunk

error details:
Windows tried to auto-shutdown programs to reboot while Cmud was up.
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Nov 11, 2010 5:32 pm   
 
As I suspected, it's causing components in CMUD to be killed in the wrong order. The window docking system is responding to the Halt message before the rest of CMUD, so it's trying to destroy the docking windows (the mapper in this case) before they are ready to be killed. Not sure there is much I can do about this.

What's interesting is that when I tried it on my Windows 7 machine here, I didn't have any error or problem with it. I have the mapper open and docked to the right of the session window. Maybe there is something specific to your docked layout or mapper setup.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Thu Nov 11, 2010 5:41 pm   
 
I could probably work up a method to reproduce this, but if as you say, it can't be helped, then I'll forebear and save myself the effort.

I wonder what other programs do to avoid similar issues. Cmud is the only program I use that throws errors when Windows forces them closed.
Reply with quote
Zugg
MASTER


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

PostPosted: Fri Nov 12, 2010 9:22 pm   
 
A couple of things:

1) Most programs don't have a complex window docking system like CMUD. The Windows OS does not support docked windows natively and makes lots of assumptions (like a single menu per window, etc) that mess with docking systems. So except for simple "toolbar docking", programs with real nested window docking are very complex and very sensitive to the exact Windows events being sent and the order in which they are sent.

2) Most programs don't display crash dumps to the user like CMUD. To improve stability, I made the choice to trap *every* crash in CMUD and give people the chance to use the "Send bug report" to send it to me. Most production software traps and ignores crashes because they don't want users to see these popup errors. They do the equivalent of "Continue Application" in CMUD. Works with most errors, but not all.

3) When you close a Windows program, *any* problems with bad data pointers caused during the program running can cause crashes as the application attempts to "clean up" itself. Again, most production apps ignore crashes during closing, and this kind of issue is more of a problem with an application like CMUD that runs over a very long period of time and uses lots of memory caches in creative ways to improve performance. What makes CMUD even more susceptible is the scripting language itself which allows CMUD to do lots of things that it might not have been designed for. You can't script most apps.

In any case, it's #2 that is the most common difference between CMUD and other software. As an example within Windows itself, have you ever run the Windows File Explorer and clicked on a directory and seen the long green progress bar? This isn't really a "progress bar" in the sense that Windows is loading the directory. When this progress bar stays on the screen for a while it really means that Windows Explorer has crashed and is restarting itself (Google the "green bar of death"). Windows suppresses the error message and just gives a progress bar while it reloads itself. So just because other programs don't show the error messages doesn't necessarily mean they are more stable or bug free...they are just hiding the truth in many cases.

The complexity of the window docking system is also an issue. For example, Windows has several event messages that deal with closing windows. It first asks each window if it "can close?" (which many programs trap to ask if you want to save your changes before exiting). If a window "can close", then it gets the actual WM_CLOSE message. The Reboot is sending the WM_QUIT to the application, which bypasses the "can close" event handling. The WM_QUIT message causes the main application window to close, which contains the main docking site for other windows. So CMUD has to try and close each docked window and needs to decide whether to send the "can close" and "wm_close" messages manually or see if those messages were already sent. If the window docking component gets the WM_CLOSE message before CMUD itself has cleanly handled the windows, then it tries to remove the docked windows itself and it doesn't have any real knowledge of what kind of window is docked and what cleanup order is needed. Some windows depend upon each other...for example, when closing a session window, CMUD needs to notify the mapper window that the session window is gone. If this isn't done, then when the mapper window tries to close, it tries to tell the session window it is closing but the session window pointer is now corrupted because the session window is already gone.

Probably *way* more information than you wanted. Obviously if it was easy and simple then CMUD wouldn't have these problems after so many years.
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