[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Miniwindows
. . -> [Subject]  Miniwindow goes black
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Miniwindow goes black
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1  2  3 

Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Fri 09 Sep 2011 10:04 PM (UTC)  [ quote  ]
Message
Bear in mind that miniwindows are not directly locked to plugins, except the convention of using the plugin ID in their name. Thus unloading the plugin could still leave the window around.

As a work-around, try putting into the OnPluginClose function a call to delete the miniwindow(s) you use.

Then when the problem occurs, reload the plugin. This should force the miniwindow to be deleted, effectively simulating using a different plugin ID.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Bast   (76 posts)  [Biography] bio
Date Fri 09 Sep 2011 07:20 PM (UTC)  [ quote  ]

Amended on Fri 09 Sep 2011 08:07 PM (UTC) by Bast

Message
Ok,something like this has now happened on my MUSHclient install with the miniwin_events window. I don't get a fully black window, I got a half drawn window. The hotspots in the window still worked whether or not that part of the window was drawn correctly. It happened within 30 minutes of me starting the client, I requested a campaign, killed a mob, and then the window got drawn incorrectly. If I reloaded the plugin, the problem happened immediately when I did "cp check". If I unload the plugin, change the id, then load the plugin again, the window was drawn correctly, but after a couple of cp mob kills, it did the same thing. If I repeated the process and converted back to the original id, the problem was still there.

Bad Image: http://i.imgur.com/9uIvi.png
Good Image: http://i.imgur.com/X5CwM.png

Here is what top showed:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5263 endavis 20 0 2686m 97m 14m S 11 2.5 3:19.39 MUSHclient.exe

I also had over a gig of RAM free.
Wine: 1.3.27.20110909-1.1
Opensuse 11.4

Here is my plugins command, which shows how much memory my plugins are using according to collectgarbage('count')


PluginFunctions v6.1 Plugins List
-----------------------------------------------
Name                          Vers  Cmd/Short Debug   Enabled   Mem Usage (KB)
-----------------------------------------------------------------------
Aardwolf_BigMap_Graphical     3.00                    true                
Aardwolf_Chat_Capture_Miniwindow2.00                    true                
Aardwolf_Chat_Echo            1.00                    true                
Aardwolf_GMCP_Mapper          2.00                    true                
Aardwolf_Group_Monitor        2.00                    true                
Aardwolf_Health_Bars          2.00                    true                
Aardwolf_Helper_Aliases       1.00                    true                
Aardwolf_Main_Layout          1.00                    true                
Aardwolf_New_Connection       1.00                    true                
Aardwolf_Package_Update_Checker1.00                    true                
Aardwolf_Planes_Mobs          1461  pl        false   true      597       
Aardwolf_Regen                1461  regen     false   true      882       
Aardwolf_Tick_Timer           1.00                    true                
Aardwolf_WeaponSwitch         1.10                    true                
Consider_info                 2.00                    true                
Copy_Colour_Output            1.10                    true                
GMCP_handler                  1.00                    true                
Miniwindow_Z_Order_Monitor    2.00                    true                
MobLookup                     1461  lm        false   true      679       
PluginFunctions               1461  plugins   false   true      827       
PotionQuafferv2               1.30                    true                
Repaint_Buffer                1.00                    true                
StatDB                        1461  statdb    false   true      1203      
StatMonitor                   1461  statmn    false   true      795       
Summary                       1.00                    true                
bast_hunt                     1461  bh        false   true      995       
bast_spellup                  1461  bsp       false   true      2313      
fix                           1461  fix       false   true      563       
miniwin_double                1461  mdbl      false   true      583       
miniwin_events                1461  mev       false   true      1145      
miniwin_help                  1461  mnhelp    false   true      1319      
miniwin_map                   1461  mmap      false   true      1665      
miniwin_moonbot               1461  mb        false   true      905       
miniwin_noexp                 1461  mnoexp    false   true      591       
miniwin_settings              1461  mnset     false   true      1346      
miniwin_spellup               1461  mspell    false   true      5841      
miniwin_stats                 1461  mstat     false   true      1397      
miniwin_tabwin                1461  mtab      false   true      1026      
miniwin_vote                  1461  mvote     false   true      663       
smoothTick                    1.00                    true                
xBastmush_Update_Checker      1461  bup       false   true      1283      
xBroadcast_Area               1461  barea     false   true      1322      
xBroadcast_CP                 1461  bcp       false   true      770       
xBroadcast_Double             1461  bdbl      false   true      552       
xBroadcast_GQ                 1461  bgq       false   true      1224      
xBroadcast_Inventory          1461  binv      false   true      745       
xBroadcast_Kills              1461  bkill     false   true      1172      
xBroadcast_Level              1461  blev      true    true      1034      
xBroadcast_Noexp              1461  bnoexp    false   true      1056      
xBroadcast_Quest              1461  bqu       false   true      549       
xBroadcast_Runto              1461  brunto    false   true      805       
xBroadcast_SpellSkills        1461  bsst      false   true      1231      
xBroadcast_Whois              1461  bwhois    false   true      563


Link to Debug Summary: http://pastebin.com/YfqJVVZG

Bast
Bast

Scripts: http://bastmush.googlecode.com
[Go to top] top
Posted by Fiendish   USA  (849 posts)  [Biography] bio   Global Moderator
Date Thu 01 Sep 2011 01:59 AM (UTC)  [ quote  ]
Message
Nick Gammon said:
It is starting to sound like some sort of Windows 7 problem.
Can't be. The summary I posted says XP.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Thu 01 Sep 2011 01:49 AM (UTC)  [ quote  ]
Message
Rooklion said:

Update: it seems resources might be to blame. I hadn't restarted my machine in quite a long time and it seemed like I was able to get the blackout in a very short period of time. I've just restarted and have been through a few CPs so far and no blackout.


It is starting to sound like some sort of Windows 7 problem. Perhaps when a process ends it doesn't free all the resources it uses?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Rooklion   (9 posts)  [Biography] bio
Date Wed 31 Aug 2011 11:30 PM (UTC)  [ quote  ]
Message
I'm not sure if a larger test set is needed, but I just installed Linux as a 2nd OS and have MUSHClient running under Wine. I have so far not had a single problem with miniwindows turning black. It might be important to note that I was otherwise running Windows 7 64-bit as my other OS.
[Go to top] top
Posted by Fiendish   USA  (849 posts)  [Biography] bio   Global Moderator
Date Wed 31 Aug 2011 07:37 AM (UTC)  [ quote  ]

Amended on Wed 31 Aug 2011 07:54 AM (UTC) by Fiendish

Message
Quote:
Before I look into this in a great deal of detail, what I can't get my head around is why the plugin order affects it.
I don't think order causes it to happen. I think a certain plugin order may just cause it to happen sooner. Remember that for this particular user the problem manifests right away, whereas most other players require some random combination of events during gameplay before the problem occurs. I had the same user enable tracing before any plugins loaded and the problem didn't happen, which would indicate a race condition and that the output from trace changes the timing enough that the problem goes away.

Quote:
If someone can make a minimal example that reproduces this, that would help track it down.
I can't even get it to happen at all on my machine. I doubt we'll be able to produce any sort of example. :\
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Wed 31 Aug 2011 07:11 AM (UTC)  [ quote  ]
Message
Before I look into this in a great deal of detail, what I can't get my head around is why the plugin order affects it.

Say there is a bug in miniwindows, and after 1000 WindowCreate calls it no longer works properly. OK, but why does the plugin order affect that? Whatever order things are done in, the same things will be done, right?

If someone can make a minimal example that reproduces this, that would help track it down.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Tue 30 Aug 2011 07:01 AM (UTC)  [ quote  ]
Message
This suggests to me a bit that the internal bitmap has gone wrong. Since miniwindow operations draw to the bitmap, and then the bitmap is copied to the main window if (for some reason) it was corrupted then attempts to modify it might fail.

I'll look into it tomorrow.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Fiendish   USA  (849 posts)  [Biography] bio   Global Moderator
Date Tue 30 Aug 2011 02:44 AM (UTC)  [ quote  ]

Amended on Tue 30 Aug 2011 02:45 AM (UTC) by Fiendish

Message
Nick Gammon said:
The fact that it has blitted in a black box tends to suggest that the miniwindow contents are wrong, for some reason. A reason along the lines of, someone did a WindowCreate, and then relied upon the window filling up with data, and it didn't.

Given the evidence I've seen, I'm leaning more toward the miniwindow contents are wrong because they're getting put in the wrong place in memory or getting pulled from the wrong place. Here's why:

Going back to my user who can consistently reproduce the problem, I had him add the following function, activated by an alias, to the miniwin_tabbar.xml plugin.

function testFunction()
   local win = "eee96e233d11e6910f1d9e8e-tabwin"
   print(WindowRectOp (win, 2, 0, 0, 0, 0, ColourNameToRGB("green")))
   Repaint()
end


That *should* immediately make the tabbar window green. But for him it stays black. Though the print does display "0" as expected.

I had him then throw in

WindowShow(win, false)

at the end, and sure enough the black section goes away, which means that MUSHclient is drawing...SOMETHING...just not what it's supposed to be. And then when the mud sent some information and a plugin updated state, it came back. Still black.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Mon 29 Aug 2011 04:05 AM (UTC)  [ quote  ]
Message
Checking the code for drawing the output window, it seems to me that the window is being drawn, in a sense. The output area is initially cleared to the background colour/image, and then the miniwindows and text drawn.

Now the miniwindows are basicallly "blitted" from the bitmap which is stored as the miniwindow contents. That is, from whatever it was when you last drew stuff.

So if, for some reason, it wasn't drawing certain windows you would see nothing, not a black box. That is, you would see whatever was underneath.

The fact that it has blitted in a black box tends to suggest that the miniwindow contents are wrong, for some reason. A reason along the lines of, someone did a WindowCreate, and then relied upon the window filling up with data, and it didn't.

That's why I was asking about the assert, perhaps if the drawing code hits some condition, it just stops drawing.

Now as far as I can tell, this problem isn't happening to "simple" windows (like status bars) where the window is cleared and then redrawn in easy-to-follow logic.

You could confirm this a bit by clearing the window to some sort of colour, or pattern (like a grid) initially, and then overwriting. Now if we see this colour/grid but not what is supposed to be on top of it, that supports the idea of some logic problem in the plugin.

I also wonder if in one of the libraries, some button or something is getting much larger than it should be? Maybe something that is quite small becomes negative, and that negative value is taken as "from the RH side" and then wipes out everything under it?

What you could do to narrow this down is to remove all instances of black when drawing with some other unique colours (at least for testing). So if the window becomes purple (say) and you only draw that shade of purple in one place, then you have your culprit (this includes the initial colour you clear the window to).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Fiendish   USA  (849 posts)  [Biography] bio   Global Moderator
Date Mon 29 Aug 2011 03:22 AM (UTC)  [ quote  ]
Message
Fiendish said:

Hmm. I've got another user here who can get it to happen pretty reliably just by starting MUSHclient with no other intervention. I asked him to switch to 4.75 and it still happens.
Quote:
...debug summary...


It looks now like whether this happens for this user is entirely dependent on plugin load order. Moving bast_spellup to the very end of the load list made the problem stop. Putting it back made the problem happen again. We're now trying to narrow it down a bit more.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Rooklion   (9 posts)  [Biography] bio
Date Mon 29 Aug 2011 02:01 AM (UTC)  [ quote  ]
Message
Update: it seems resources might be to blame. I hadn't restarted my machine in quite a long time and it seemed like I was able to get the blackout in a very short period of time. I've just restarted and have been through a few CPs so far and no blackout.
[Go to top] top
Posted by Fiendish   USA  (849 posts)  [Biography] bio   Global Moderator
Date Mon 29 Aug 2011 12:42 AM (UTC)  [ quote  ]
Message
Nick Gammon said:

Can you get them to put the suggested "assert" in, in the two places which have a loadstring, and report what happens?

No improvement.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Rooklion   (9 posts)  [Biography] bio
Date Sun 28 Aug 2011 10:07 PM (UTC)  [ quote  ]
Message
And 5 more mobs later, same miniwindow, restarted MUSHClient.

http://pastebin.com/dnLcNGFF
[Go to top] top
Posted by Rooklion   (9 posts)  [Biography] bio
Date Sun 28 Aug 2011 10:01 PM (UTC)  [ quote  ]

Amended on Sun 28 Aug 2011 10:03 PM (UTC) by Rooklion

Message
Ok, my database (called Aardwolf_Database.xml) went black during a CP. I would be happy to send a private email of the file if it will help track this down. Debug("summary") is below.

http://pastebin.com/6Q4tsxy6

I only use one loadstring() in the file and it uses an assert() already.
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

5,611 views.

This is page 3, subject is 3 pages long:  [Previous page]  1  2  3 

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]