Debugging: Any way to monitor all changes to a specific variable?

[Mbee]

I've been struggling with a bug wherein a particular variable (to keep this description simple) is being set to an improper value. I've tried several techniques, but I can't find the offender. One thing I've tried is to create a very brief "idle" loop (like a Message loop) to check the value every interval, but although I see the improper change, I can't figure out which function or handler performed the change.

So what I'd like is some way to monitor a specific variable's value and trigger some kind of notification or log entry to indicate which function or handler made the improper change. I read the description of @mLipok 's ErrorLog.au3 UDF (ErrorLog.au3 UDF - A logging Library) and specifically the _Log_Change() function, but I can't understand the description or how to use it, so I can't determine if it can do what I need.

What other UDFs or techniques do you think might allow me to accomplish what I need?

I've only recently learned of the macro @ScriptLineNumber, which looks promising. If there were some way of monitoring the variable in question that wouldn't require a variable test to be inserted between virtually every single line of code -- i.e., some sort of global monitoring tool -- I might be able to determine the  @ScriptLineNumber value and report it, which would solve my problem.

Does anyone know of such a tool / technique? Or just some ideas as to how such a tool could be designed?

Thank you all!

[Earthshine]

Don’t use global variables

[Mbee]

54 minutes ago, Earthshine said:

Don’t use global variables

I've always held, and surely I'm far from alone in this, that one can take picayune evangelism too far. Such as in this instance, when no mention was made of global variables. And in fact, the variable in question is NOT a global.

Please post back if you can find anything of value to say.

[TheDcoder]

I am afriad it isn't directly possible to monitor a specific variable for changes from within the script itself. Seeing how AutoIt lacks a native debugger, it may also not be possible for the several 3rd party debuggers to accomplish this task, however I recommend trying out some of them, see if they are of help. Good luck

[Mbee]

2 hours ago, TheDcoder said:

I am afriad it isn't directly possible to monitor a specific variable for changes from within the script itself. Seeing how AutoIt lacks a native debugger, it may also not be possible for the several 3rd party debuggers to accomplish this task, however I recommend trying out some of them, see if they are of help. Good luck

Thank you for your knowledgeable reply, even though it didn't solve my problem. It's good to know that it is very doubtful that a directly useful solution exists.

While I was awaiting an answer, I coded up something that I would have expected to be more valuable, but hasn't been after all.  I would greatly appreciate it, kind @TheDcoder, if you would kindly comment on your analysis of the puzzling results...

For years I've been using a modified version of Kobashi's "StatusMsgs" UDF, which is a logging UDF that permits output to a real-time log window, a log file, or both. I created a custom-modified version that will test the specific variable (actually, an array cell) under the imprecise conditions under which that variable gets clobbered, then add a message giving that status and append it to the normal log message the function was designed to handle.

Next, I wrote a very crude lexer/parser that reads all my .au3 source code files for this project, and scans for all function definitions, return statements, and "EndFunc" statements (in case there are no explicit return statements the function under analysis), inserts calls to the custom log UDF, and writes a new copy of the .au3 file including those logging calls. The resulting .au3 files will then look as follows:

 

Func Gi_GetListDropped( $arg_WinHdl, $arg_MsgID, $arg_wParam )
    _UpdStatusMsg("+++ Entering Function [ Gi_GetListDropped ] +++")



    Local $Lf_Blah = 47
    
    
    
    _UpdStatusMsg("<<< Returning from Function [ Gi_GetListDropped ] >>>")
    Return $GUI_RUNDEFMSG
    
    _UpdStatusMsg("--- EndFunc [ [ Gi_GetListDropped ] +++")
    
EndFunc

 

Then I would compile and run the resulting .au3 file and view the log file.  At the point in the log corresponding to where the variable gets set to an incorrect value, I was expecting to see something like a log message reading "<<< Returning from Function [ whatever ] >>>  -- WARNING: WATCHED VARIABLE HAS BEEN SET TO IMPROPER VALUE!" Then I would at least know the last function called before the clobberin'

But I do NOT see anything so sensible. Instead, I see the WARNING message upon leaving a function that does not and can not modify or even examine the watched variable!

And if I trace back the 10 previously called functions, the watched variable has not been, and cannot have been, modified there!  It's like the clobbering is coming from an entirely separate process or execution sequence!  It's true that most of the time I'm running in On Event mode, but none of my event handlers interacts with the watched variable whatsoever.  It's like some strange incarnation of Maxwell's Demon is fucking with me just for the hell of it.

Oh, well. Insanity beckons and her call seems ever more irresistible...

Edited September 8, 2019 by Mbee
typo

[Earthshine]

Write a function that takes parameters. Send it the variable name as first parameter and the data you want to assign it to. That function should log everything. Then you should see what’s happening 

[TheDcoder]

36 minutes ago, Mbee said:

But I do NOT see anything so sensible. Instead, I see the WARNING message upon leaving a function that does not and can not modify or even examine the watched variable!

Aside from the ghost in the machine or gremlins, there is only one logical explanation... somewhere in that function, is a statement which updates the "critical data", it doesn't have to be the variable directly, sometimes other factors may influence it in ways that may have been forgotten.

I suggest you do a full review of the code, especially the function which gives you the warning message. You will certainly find the culprit sooner or later.