8 replies to this topic

[JSLover]

If you use SetTimer to launch a subroutine which uses WinWait, it will cause 100% CPU usage if a msgbox (or a FileSelectFile {& perhaps any common dialog}) is displayed at the time the WinWait starts.

Code to demonstrate issue...

New-style code (won't run on old versions)...

#SingleInstance force
#Persistent

SetTimer, Timer, -3000

msgbox, 64, ,
(LTrim %
	Keep this window open for 3 secs & the WinWait causes 100% CPU

	Close it before 3 secs & the WinWait will use 0% CPU
)
return

Timer:
Tooltip, WinWait running...
WinWait, % "PLEASE USE 100% CPU FOR NO REASON"
msgbox, WinWait done
return

Old-style code (so I could test on older versions)...

#SingleInstance force
#Persistent

SetTimer, Timer, 3000

msgbox, 64, , Keep this window open for 3 secs & the WinWait causes 100`% CPU`n`nClose it before 3 secs & the WinWait will use 0`% CPU
return

Timer:
SetTimer, Timer, Off
Tooltip, WinWait running...
WinWait, PLEASE USE 100`% CPU FOR NO REASON
msgbox, WinWait done
return

This was 1st noticed using a FileSelectFile dialog (Open/Save Common Dialog {GetOpenFileName()}) with AutoHotkey_L 1.1.05.01...but I've done more testing & narrowed the regression range to...
OK - 0% CPU - AutoHotkey 1.0.44.10
BAD - 100% CPU - AutoHotkey 1.0.44.11...I have a diff of the source code between those versions, if that'll help...

The 1.0.44.11 changelog says...
1.0.44.11 - September 9, 2006

[*:254m42ym]Fixed FileSelectFolder and TreeView to respond properly to mouse clicks when timers are running.
[*:254m42ym]Fixed inability of OnMessage() to consistently monitor certain messages such as WM_NOTIFY. [thanks numEric]
[*:254m42ym]Fixed inability of literal/quoted strings to contain `%.
[*:254m42ym]Fixed continuation sections to support #EscapeChar, #DerefChar, and #Delimiter. [thanks Laszlo]
[*:254m42ym]Changed GroupBox to default to "no word-wrapping". This can be overridden via +Wrap.
[*:254m42ym]Changed/improved the ** operator and "Transform Pow" to support negative bases when the exponent isn't fractional. [thanks Laszlo]
[*:254m42ym]Improved GUI responsiveness during UrlDownloadToFile (especially for slow downloads)....I'm guessing that FileSelectFolder fix broke WinWait?

[JSLover]

100+ views, 0 replies?...was my report not complete enough?

There's really nothing more I can add to it...it is a REAL BUG that was introduced with AutoHotkey 1.0.44.11...& STILL EXISTS in AutoHotkey_L 1.1.05.01...& no, since I posted this, I have not tested with AutoHotkey_L 1.1.05.02 or AutoHotkey_L 1.1.05.03...but since there's been no reply, there's no reason to think this was silently fixed.

[jethrow]

100+ views, 0 replies?...

I bumped it up to 131 ...

[fragman]

I suppose this is related to the WM_NOTIFY issue that I started a thread about a few weeks ago. It has also been talked about in the past. It would be nice if a fix for this could be found. Being able to use WM_NOTIFY messages without getting crashes would also be nice.

I can reproduce with the second latest version, so this seems to be a generic problem.

[jethrow]

WIN 7 - 64bit - AHK v1.1.05.01

I'm not getting 100% CPU usage, but it is still high - averaging around 55%. Thank you for reporting it. Personally, I would classify it as a known issue, but fixing it wouldn't be top priority if I were the developer.

Of course I'm sure you realize this, but for the sake of anyone else reading this thread, a simple workaround would be:

while Not WinExist("PLEASE USE 100% CPU FOR NO REASON")
   Sleep, 10

[JSLover]

I'm not getting 100% CPU usage, but it is still high - averaging around 55%.

...I was going to mention this before, but I'm on a single core/CPU...if you have a computer with multiple cores/CPUs it will probably only max out one core/CPU, giving the appearance of less than 100% usage.

Personally, I would classify it as a known issue...

...I would kinda classify it as a completely unknown issue, this behavior was introduced MANY versions ago & never noticed, until now.

...but fixing it wouldn't be top priority if I were the developer.

...maybe not "top priority", but finding the problem should be semi-easy, since it was introduced in one version change, there's only one diff to review.

[Lexikos]

Fixed in v1.1.05.04. It wasn't limited to WinWait; it probably affected any part of the code which waits for something, except for Sleep. For instance, I was able to reproduce it with the Input command or by pausing the script (while the timer subroutine is running).

[nimda]

I find it interesting that the bug was able to go so long unnoticed - I've certainly never seen a script max out my CPU before.

If it lasted for over 5 years, using a dialog while a timer with a "wait" type command must be really uncommon.

[fragman]

I've seen my script maxing out CPU usage, but I'm not sure if it was due to this bug. It's possible since I use both timers and wait commands at various places. Anyway, nice to see it fixed.