AutoHotkey Community

[Lexikos~]

[pekkle]

bug... with the latest exe and bin, ahk2exe /nodecompile not working any more, it would create invalid exe file.

[Sean]

[Chris]

[Guest]

[Lexikos]

[Chris]

[toralf n-l-i]

Hi Chris,

I am unsure where to post it. But since this is closely linke dto this beta, I thought it would be ok to post it here.

In the Manual about the SetFormat it is said:

[Chris]

Thanks; I've clarified it to read:
The fast mode preserves the ability of variables to cache integers and floating point numbers, which can substantially accelerate numerically-intensive operations. (By contrast, the slow mode forces all numeric results to be immediately converted and stored as strings.)

[Chris]

Since backward compatibility is important, the following behaviors have been changed back to the way they were in non-beta versions:

[Laszlo]

I am not sure if it is new to the AHK beta. The following little script keeps on increasing its memory use, until it eventually crashes.

[Chris]

I can see that the memory does increase gradually. When run overnight with the older, non-beta version of AutoHotkey, Task Manager's "mem usage" increased from 3976 to 4320 (I also changed the SetTimer line to use a period of 1 instead of unspecified).

When run in the compiler's debugger, the call stack doesn't appear to be growing larger; so it doesn't appear to be a problem such as unwanted recursion.

Also, the script's VM size doesn't increase, which I think means that the program is not allocating additional memory from the heap as time goes on. This is further supported by the fact that in debug mode, breakpoints on the most likely memory allocations are never reached.

Also, it doesn't appear to be an issue with DllCall's LoadLibrary() because that call is never reached (WinMM.dll is already loaded).

I also tested it with a loop containing "Sleep 1" instead of SetTimer, and the same thing seems to happen. Strangely, removing the Sleep and allowing it to run very fast doesn't seem to increase the rate of memory growth.

The fact that "mem usage" increases but not "VM size", may imply that some kind of shared OS resource is increasing its memory utilization. This is further supported by the fact that Process Explorer reports that the working set "private" is not increasing, but the working set "shareable" and "shared" seem to be increasing. Therefore it's tempting to write this off as some kind of OS bug. However I won't rule out the possibility that it's a bug in the program, perhaps something involving GetKeyState() [though I did review that code and there don't seem to be any untested memory allocations in it].

I'm near the end of what my debugging skills can do; I'm not sure what more should be checked.

Comments or further testing are welcome from anyone.

[tonne]

Sysinternal just released a new memory tool vmmap - maybe it can shed light on the incresed memory usage.
_________________
RegEx Powered Dynamic Hotstrings
COM
AutoHotkey 2

[Laszlo]

Some more info about the joystick monitor's memory use:
- If there is no joystick connected (unplugged), the memory increase stops. Reconnecting the joystick restarts the memory increase.
- In my Vista PC, SetTimer...,1 increased the memory use to 200MB in just 10 minutes. At 330MB the PC slows down, and some disk activity occurs (maybe swapping something to disk?).
- Fixing this issue was important, because joystick using applications need to know if a joystick gets unplugged. GetKeyState alone does not help, because it returns the last valid data, long after the joystick was removed, so the application appears to be frozen. If there is a bug in winmm.dll\joyConfigChanged, another method would be badly needed. Any idea where to look?

[Chris]