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

code stability regression between 4.75 and 4.77

Posted by Fiendish on Fri 26 Aug 2011 09:28 AM — 4 posts, 11,950 views.

Fiendish USA Global Moderator #0
I suspect this is related to the major mouse event instability caused in 4.76 not being properly undone.

I've discovered a new problem in 4.77 where lines of code are randomly aborting execution and/or re-executing in ways that don't make sense.

As with everything, I'm using the Aardwolf MUSHclient Package for testing. I've looked at both Windows and Linux, Luajit and standard Lua, and have determined that the problem started in either 4.76 (which I can't run anyway because of constant stack overflows) or 4.77. 4.75 works fine.

If I approach the group monitor plugin in the aardwolf client package:
https://aardwolfclientpackage.googlecode.com/svn/trunk/MUSHclient/worlds/plugins/aard_group_monitor_gmcp.xml

and apply the traces indicated in this diff to the plugin file
http://pastebin.com/Pydcm0JU

What I *SHOULD* see, and what I see with 4.75, after creating a group with just me in it (group create <group_name>) and then resizing the group monitor window is the following output (the numbers themselves are not important, only the order and completeness of execution from a to d):

----
a 128 41
in
in2
b 20 54
c 20 67
d 20 81
----
a 128 41
in
in2
b 20 54
c 20 67
d 20 81
----
a 128 41
in
in2
b 20 54
c 20 67
d 20 81

etc.


What I instead see in 4.77, and which is causing visual glitches in this plugin and who knows what chaos in other plugins is the following (notice now that execution is completely bonkers while resizing):

----
a 128 41
in
in2
b 20 54
c 20 67
d 20 81
d 20 95
----
a 128 41
in
----
a 128 41
in
in2
b 20 54
c 20 67
d 20 81
in2
b 20 94
----
a 128 41
in
in2
b 20 54
c 20 67
d 20 81
c 20 94


Again, I suspect this is because of the (inapt) change in 4.76/4.77 to generate new mouse-move events when they shouldn't be getting generated, but I haven't inspected the code to see what other changes might have influenced this behavior.
Amended on Fri 26 Aug 2011 06:04 PM by Fiendish
Nick Gammon Australia Forum Administrator #1
My preliminary tests, which on the face of it confirm that something strange is happening, appear to suggest you are re-entering the code. For example:


group create Yirald
Group Yirald has been created.
----
a 128 41
in
in2
b 20 54
c 20 67
d 20 81
----
a 128 41
in
<--- in2 missing here
----
a 128 41
in
in2
b 20 54
c 20 67
d 20 81
<--- here it is!
in2
b 20 94
----


Why, I have yet to establish.
Nick Gammon Australia Forum Administrator #2
My preliminary thought is that a race condition is being generated. From the relnotes for 4.76:



10. If the mouse is over a hotspot after it was created then a mouse-move event is generated. Previously a newly-created hotspot was only noticed when you moved the mouse.



Now potentially creating a hotspot will generate a mouse-move event.

Your problem code is, in part, here:


            print("in")
               gauge(win, v["name"].."'s HP", tonumber(v["info"]["hp"]), tonumber(v["info"]["mhp"]), 
               x, y, bar_width, line_height, hpColor1, 0x000000, 0, 0x000000, hpColor2, nil, flat_gauges==1)
            print("in2")


Although you expect to see "in2" after "in", you don't (sometimes). And what does gauge do? It creates hotspots.

So I think this is happening:

  • You resize the window.
  • ResizeMoveCallback gets called.
  • That calls SetUpHotspotsAndDraw
  • That calls DisplayGroupPage
  • That calls gauge
  • That creates a hotspot
  • That generates a mouse move
  • We re-enter the above at some point


Now this is complex enough that I can't say for sure what the fix really is, apart from reverting the change you requested a little while back to generate the mouse-move in the first place.
Fiendish USA Global Moderator #3
Quote:
Now this is complex enough that I can't say for sure what the fix really is, apart from reverting the change you requested a little while back to generate the mouse-move in the first place.

I actually didn't want a whole mouse-move to be generated because there would be many trigger cases where the mouse is not actually moving at all. I wanted specifically the onmouseover callbacks to fire for a hotspot that was created underneath the mouse.

Quote:
That creates a hotspot
That generates a mouse move

Right, and this shouldn't have been done, because the creation of hotspots has nothing to do with moving the mouse.