SikuliX

Memory leak crashes scripts running or waiting long

Bug #575585 reported by chimanfu
134
This bug affects 23 people
Affects Status Importance Assigned to Milestone
SikuliX
Fix Released
Undecided
Unassigned

Bug Description

************* Should be solved with Sikuli 0.10.2 ************************

If you have such problems with Sikuli X: pls. go to bug 708191

--------------------------------------------------------------------------

My script keeps crashing when using Sikuli 0.10. It's working perfect fine when using Sikuli 0.099.
Any idea what's going on?
thanks
-joe

[sikuli] click on (50,223), MOD: 0
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (0xe06d7363), pid=1168, tid=5612
#
# JRE version: 6.0_14-b08
# Java VM: Java HotSpot(TM) Client VM (14.0-b16 mixed mode windows-x86 )
# Problematic frame:
# C [kernel32.dll+0x12afb]
#
# An error report file with more information is saved as:
# C:\Program Files\Sikuli.10\hs_err_pid1168.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (0xe06d7363), pid=1168, tid=5612
#
# JRE version: 6.0_14-b08
# Java VM: Java HotSpot(TM) Client VM (14.0-b16 mixed mode windows-x86 )
# Problematic frame:
# C [kernel32.dll+0x12afb]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

--------------- T H R E A D ---------------

Current thread (0x002b7000): JavaThread "MainThread" [_thread_in_native, id=5612, stack(0x00840000,0x00890000)]

siginfo: ExceptionCode=0xe06d7363, ExceptionInformation=0x19930520 0x0087cab8 0x4a5d0298

Registers:
EAX=0x0087ca1c, EBX=0x0088cfb8, ECX=0x00000000, EDX=0x0087cab8
ESP=0x0087ca18, EBP=0x0087ca6c, ESI=0x0087caa4, EDI=0x01db778c
EIP=0x7c812afb, EFLAGS=0x00000206

Top of Stack: (sp=0x0087ca18)
0x0087ca18: 0088cba0 e06d7363 00000001 00000000
0x0087ca28: 7c812afb 00000003 19930520 0087cab8
0x0087ca38: 4a5d0298 0000002d 0000002f 0000002f
0x0087ca48: 0087ca6c 78486396 4b32d530 0087ca6c
0x0087ca58: 784863a1 0000002d 0088cba0 0087cb1c
0x0087ca68: 0088cfb8 0087caa4 7857df56 e06d7363
0x0087ca78: 00000001 00000003 0087ca98 e06d7363
0x0087ca88: 00000001 00000000 00000000 00000003

Instructions: (pc=0x7c812afb)
0x7c812aeb: 8d 7d c4 f3 a5 5f 8d 45 b0 50 ff 15 10 15 80 7c
0x7c812afb: 5e c9 c2 10 00 85 ff 0f 8e 36 93 ff ff 8b 55 fc

Stack: [0x00840000,0x00890000], sp=0x0087ca18, free space=242k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [kernel32.dll+0x12afb]
C [MSVCR90.dll+0x5df56]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j edu.mit.csail.uid.Finder.find(JLjava/lang/String;D)V+0
j edu.mit.csail.uid.Finder.find(Ljava/lang/String;D)V+59
j edu.mit.csail.uid.Finder.find(Ljava/lang/Object;)V+52
j edu.mit.csail.uid.Region.findAllNow(Ljava/lang/Object;)Ljava/util/Iterator;+36
j edu.mit.csail.uid.Region.waitAll(Ljava/lang/Object;D)Ljava/util/Iterator;+37
j edu.mit.csail.uid.Region.wait(Ljava/lang/Object;D)Ledu/mit/csail/uid/Match;+3
j org.python.proxies.sikuli.Region$Region$1.super__wait(Ljava/lang/Object;D)Ledu/mit/csail/uid/Match;+3
j sun.reflect.GeneratedMethodAccessor9.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+179
J sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
J org.python.core.PyReflectedFunction.__call__(Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
j org.python.core.PyReflectedFunction.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;+6
j org.python.core.PyObject.__call__(Lorg/python/core/PyObject;Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+20
j org.python.core.PyObject.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+5
j sikuli.Region$py.wait$7(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+252
j sikuli.Region$py.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+192
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyFunction.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
j org.python.core.PyObject.__call__([Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+5
j org.python.core.PyObject._jcallexc([Ljava/lang/Object;)Lorg/python/core/PyObject;+5
j org.python.proxies.sikuli.Region$Region$1.wait(Ljava/lang/Object;D)Ledu/mit/csail/uid/Match;+47
j edu.mit.csail.uid.Region.find(Ljava/lang/Object;)Ledu/mit/csail/uid/Match;+15
j org.python.proxies.sikuli.Region$Region$1.super__find(Ljava/lang/Object;)Ledu/mit/csail/uid/Match;+2
j sun.reflect.GeneratedMethodAccessor8.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+40
J sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
J org.python.core.PyReflectedFunction.__call__(Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
j org.python.core.PyReflectedFunction.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;+6
j org.python.core.PyObject.__call__(Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+16
j org.python.core.PyObject.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+3
j sikuli.Region$py.find$5(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+28
j sikuli.Region$py.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+184
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyFunction.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
j org.python.core.PyObject.__call__([Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+5
j org.python.core.PyObject._jcallexc([Ljava/lang/Object;)Lorg/python/core/PyObject;+5
j org.python.proxies.sikuli.Region$Region$1.find(Ljava/lang/Object;)Ledu/mit/csail/uid/Match;+33
j edu.mit.csail.uid.Region.getLocationFromPSRML(Ljava/lang/Object;)Ledu/mit/csail/uid/Location;+16
j edu.mit.csail.uid.Region.click(Ljava/lang/Object;I)I+2
j org.python.proxies.sikuli.Region$Region$1.super__click(Ljava/lang/Object;I)I+3
j sun.reflect.GeneratedMethodAccessor14.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+126
J sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
J org.python.core.PyReflectedFunction.__call__(Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
j org.python.core.PyReflectedFunction.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;+6
j org.python.core.PyObject.__call__(Lorg/python/core/PyObject;Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+20
j org.python.core.PyObject.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+5
j sikuli.Region$py.click$10(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+34
j sikuli.Region$py.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+204
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyFunction.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyObject.__call__(Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyObject.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
j org.python.pycode._pyx63.test_resumeLDB$73(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+208
j org.python.pycode._pyx63.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+636
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyFunction.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyObject.__call__()Lorg/python/core/PyObject;
J org.python.core.PyObject.__call__(Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;
j unittest$py.run$26(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+332
j unittest$py.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+488
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyFunction.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
j org.python.core.PyObject._callextra([Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+581
j unittest$py.__call__$27(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+43
j unittest$py.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+492
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyFunction.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
j org.python.core.PyObjectDerived.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;+63
J org.python.core.PyObject.__call__(Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyObject.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
j unittest$py.run$45(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+79
j unittest$py.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+564
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyFunction.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
j org.python.core.PyObject._callextra([Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+581
j unittest$py.__call__$46(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+43
j unittest$py.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+568
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyFunction.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
j org.python.core.PyObjectDerived.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;+63
J org.python.core.PyObject.__call__(Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyObject.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
j unittest$py.run$84(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+91
j unittest$py.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+720
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyBaseCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyFunction.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__(Lorg/python/core/ThreadState;[Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyMethod.__call__([Lorg/python/core/PyObject;[Ljava/lang/String;)Lorg/python/core/PyObject;
J org.python.core.PyObject.__call__(Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
J org.python.core.PyObject.__call__(Lorg/python/core/ThreadState;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
j org.python.pycode._pyx63.f$0(Lorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+14702
j org.python.pycode._pyx63.call_function(ILorg/python/core/PyFrame;Lorg/python/core/ThreadState;)Lorg/python/core/PyObject;+344
J org.python.core.PyTableCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
j org.python.core.PyCode.call(Lorg/python/core/ThreadState;Lorg/python/core/PyFrame;)Lorg/python/core/PyObject;+4
j org.python.core.Py.runCode(Lorg/python/core/PyCode;Lorg/python/core/PyObject;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;+97
j org.python.core.__builtin__.execfile_flags(Ljava/lang/String;Lorg/python/core/PyObject;Lorg/python/core/PyObject;Lorg/python/core/CompilerFlags;)V+87
j org.python.util.PythonInterpreter.execfile(Ljava/lang/String;)V+17
j edu.mit.csail.uid.ScriptRunner.runPython(Ljava/lang/String;Ljava/io/File;)V+123
j edu.mit.csail.uid.ScriptRunner.runPython(Ljava/lang/String;)V+9
j edu.mit.csail.uid.SikuliIDE.runSkl(Ljava/lang/String;[Ljava/lang/String;)V+103
j edu.mit.csail.uid.SikuliIDE.main([Ljava/lang/String;)V+29
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
  0x495a9400 JavaThread "weakref reaper" daemon [_thread_blocked, id=992, stack(0x498a0000,0x498f0000)]
  0x48ac7800 JavaThread "AWT-Windows" daemon [_thread_in_native, id=4396, stack(0x49090000,0x490e0000)]
  0x48dd3400 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=6012, stack(0x48ff0000,0x49040000)]
  0x48a71400 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=2120, stack(0x48cc0000,0x48d10000)]
  0x48a6bc00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=4292, stack(0x48c70000,0x48cc0000)]
  0x48a69400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2256, stack(0x48c20000,0x48c70000)]
  0x48a68400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=4444, stack(0x48bd0000,0x48c20000)]
  0x48a59000 JavaThread "Finalizer" daemon [_thread_blocked, id=1440, stack(0x48b80000,0x48bd0000)]
  0x48a54800 JavaThread "Reference Handler" daemon [_thread_blocked, id=5992, stack(0x48b30000,0x48b80000)]
=>0x002b7000 JavaThread "MainThread" [_thread_in_native, id=5612, stack(0x00840000,0x00890000)]

Other Threads:
  0x48a50800 VMThread [stack: 0x48ae0000,0x48b30000] [id=4596]
  0x48a73000 WatcherThread [stack: 0x48d10000,0x48d60000] [id=1592]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 def new generation total 18240K, used 13574K [0x029d0000, 0x03d90000, 0x07890000)
  eden space 16256K, 83% used [0x029d0000, 0x03711448, 0x039b0000)
  from space 1984K, 0% used [0x039b0000, 0x039b0708, 0x03ba0000)
  to space 1984K, 0% used [0x03ba0000, 0x03ba0000, 0x03d90000)
 tenured generation total 241984K, used 207169K [0x07890000, 0x164e0000, 0x429d0000)
   the space 241984K, 85% used [0x07890000, 0x142e0668, 0x142e0800, 0x164e0000)
 compacting perm gen total 19968K, used 19747K [0x429d0000, 0x43d50000, 0x469d0000)
   the space 19968K, 98% used [0x429d0000, 0x43d18cb0, 0x43d18e00, 0x43d50000)
No shared spaces configured.

Dynamic libraries:
0x00400000 - 0x00424000 C:\Program Files\Java\jdk1.6.0_14\bin\java.exe
0x7c900000 - 0x7c9b2000 C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c8f6000 C:\WINDOWS\system32\kernel32.dll
0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000 - 0x77f02000 C:\WINDOWS\system32\RPCRT4.dll
0x77fe0000 - 0x77ff1000 C:\WINDOWS\system32\Secur32.dll
0x7c340000 - 0x7c396000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\msvcr71.dll
0x6d8b0000 - 0x6db3b000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\client\jvm.dll
0x7e410000 - 0x7e4a1000 C:\WINDOWS\system32\USER32.dll
0x77f10000 - 0x77f59000 C:\WINDOWS\system32\GDI32.dll
0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll
0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL
0x629c0000 - 0x629c9000 C:\WINDOWS\system32\LPK.DLL
0x74d90000 - 0x74dfb000 C:\WINDOWS\system32\USP10.dll
0x6d860000 - 0x6d86c000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\verify.dll
0x6d3e0000 - 0x6d3ff000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\java.dll
0x6d340000 - 0x6d348000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\hpi.dll
0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL
0x6d8a0000 - 0x6d8af000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\zip.dll
0x6d0b0000 - 0x6d1fa000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\awt.dll
0x73000000 - 0x73026000 C:\WINDOWS\system32\WINSPOOL.DRV
0x77c10000 - 0x77c68000 C:\WINDOWS\system32\msvcrt.dll
0x774e0000 - 0x7761d000 C:\WINDOWS\system32\ole32.dll
0x773d0000 - 0x774d3000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll
0x77f60000 - 0x77fd6000 C:\WINDOWS\system32\SHLWAPI.dll
0x5ad70000 - 0x5ada8000 C:\WINDOWS\system32\uxtheme.dll
0x74720000 - 0x7476c000 C:\WINDOWS\system32\MSCTF.dll
0x634b0000 - 0x634cd000 C:\Documents and Settings\All Users\Application Data\Real\RealPlayer\BrowserRecordPlugin\Chrome\Hook\rpchromebrowserrecordhelper.dll
0x7c9c0000 - 0x7d1d7000 C:\WINDOWS\system32\SHELL32.dll
0x4ec50000 - 0x4edfb000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.6001.22319_x-ww_f0b4c2df\gdiplus.dll
0x7c3a0000 - 0x7c41b000 C:\WINDOWS\system32\MSVCP71.dll
0x49120000 - 0x49144000 C:\WINDOWS\system32\igfxdo.dll
0x77120000 - 0x771ab000 C:\WINDOWS\system32\OLEAUT32.dll
0x755c0000 - 0x755ee000 C:\WINDOWS\system32\msctfime.ime
0x6d2e0000 - 0x6d334000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\fontmanager.dll
0x68000000 - 0x68036000 C:\WINDOWS\system32\rsaenh.dll
0x769c0000 - 0x76a74000 C:\WINDOWS\system32\USERENV.dll
0x5b860000 - 0x5b8b5000 C:\WINDOWS\system32\netapi32.dll
0x6d6c0000 - 0x6d6d3000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\net.dll
0x71ab0000 - 0x71ac7000 C:\WINDOWS\system32\WS2_32.dll
0x71aa0000 - 0x71aa8000 C:\WINDOWS\system32\WS2HELP.dll
0x71a50000 - 0x71a8f000 C:\WINDOWS\System32\mswsock.dll
0x76f20000 - 0x76f47000 C:\WINDOWS\system32\DNSAPI.dll
0x76fb0000 - 0x76fb8000 C:\WINDOWS\System32\winrnr.dll
0x76f60000 - 0x76f8c000 C:\WINDOWS\system32\WLDAP32.dll
0x49620000 - 0x49645000 C:\Program Files\Bonjour\mdnsNSP.dll
0x76d60000 - 0x76d79000 C:\WINDOWS\system32\Iphlpapi.dll
0x76fc0000 - 0x76fc6000 C:\WINDOWS\system32\rasadhlp.dll
0x49680000 - 0x496d2000 C:\Documents and Settings\jfu\Local Settings\Temp\jna5869218640340399613.tmp
0x496e0000 - 0x49713000 C:\Program Files\Sikuli.10\tmplib\ScreenMatchProxy.dll
0x4a150000 - 0x4a3d8000 C:\Program Files\Sikuli.10\tmplib\cv210.dll
0x4a3e0000 - 0x4a5fe000 C:\Program Files\Sikuli.10\tmplib\cxcore210.dll
0x78480000 - 0x7850e000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_d495ac4e\MSVCP90.dll
0x78520000 - 0x785c3000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_d495ac4e\MSVCR90.dll
0x49740000 - 0x4980a000 C:\Program Files\Sikuli.10\tmplib\highgui210.dll
0x73b50000 - 0x73b67000 C:\WINDOWS\system32\AVIFIL32.dll
0x77be0000 - 0x77bf5000 C:\WINDOWS\system32\MSACM32.dll
0x75a70000 - 0x75a91000 C:\WINDOWS\system32\MSVFW32.dll
0x73b80000 - 0x73b92000 C:\WINDOWS\system32\AVICAP32.dll
0x77c00000 - 0x77c08000 C:\WINDOWS\system32\VERSION.dll
0x5edd0000 - 0x5ede7000 C:\WINDOWS\system32\OLEPRO32.DLL
0x49840000 - 0x49864000 C:\Program Files\Sikuli.10\tmplib\VDictProxy.dll
0x49880000 - 0x4988f000 C:\Program Files\Sikuli.10\tmplib\Win32Util.dll
0x77b40000 - 0x77b62000 C:\WINDOWS\system32\Apphelp.dll
0x6d6e0000 - 0x6d6e9000 C:\Program Files\Java\jdk1.6.0_14\jre\bin\nio.dll

VM Arguments:
jvm_args: -Xms256M -Xmx1024M -Dfile.encoding=UTF-8 -Dpython.path=C:\Program Files\Sikuli.10\sikuli-script.jar/
java_command: edu.mit.csail.uid.SikuliIDE C:\delphix_main\automation\regression\GUI\sikuli\MainAppTestSuite1_new.skl
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14
CLASSPATH=.;C:\Program Files\Java\jre6\lib\ext\QTJava.zip
PATH=C:\ant\bin;C:\Program Files\Java\jdk1.6.0_14\bin;C:\ant\bin;C:\STAF\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Intel\DMIX;C:\Program Files\NTRU Cryptosystems\NTRU TCG Software Stack\bin\;C:\Program Files\Wave Systems Corp\Gemalto\Access Client\v5\;C:\Program Files\Common Files\Roxio Shared\DLLShared\;C:\Program Files\Common Files\Roxio Shared\9.0\DLLShared\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Adobe\Flex Builder 3\sdks\3.2.0\bin\;C:\strawberry\c\bin;C:\strawberry\perl\bin;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\jEdit;C:\Program Files\OpenVPN\bin;C:\Program Files\Sikuli.10\tmplib;C:\Program Files\Sikuli.10\tmplib
USERNAME=jfu
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 6 Model 23 Stepping 10, GenuineIntel

--------------- S Y S T E M ---------------

OS: Windows XP Build 2600 Service Pack 3

CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 23 stepping 10, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1

Memory: 4k page, physical 2097151k(705356k free), swap 4194303k(2372112k free)

vm_info: Java HotSpot(TM) Client VM (14.0-b16) for windows-x86 JRE (1.6.0_14-b08), built on May 21 2009 08:03:56 by "java_re" with MS VC++ 7.1

time: Tue May 04 22:10:53 2010
elapsed time: 616 seconds

See original description
Revision history for this message
chimanfu (jfu) wrote :

the reason of the crash is due to taking huge memory usage when running Sikuli-IDE.exe (more than 700M)
any clue? any solution?

Again, my script is working perfectly fine in the previous sikuli version. Never have crash.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

Can you paste you script too?

Revision history for this message
chimanfu (jfu) wrote :

I can send you the script to your email address if you want.

I think there is a memory leak in the Sikuli-IDE.exe. It consumes the memory very rapidly and crashes in 2 or 3 mins when running my script. I also tried to use Sikuli-IDE.bat to launch the script and has the same problem.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

Sure. Please send to my email.
You can find it in my launchpad page.

Revision history for this message
Shobha (shobha-thimmaiah) wrote :

It happened to me too..As I run my old scripts, Siukil crashes after 2-3 minutes run..
Pls provide the fix as early as possible. Thanks.

Revision history for this message
chimanfu (jfu) wrote :

Hi Tsung-Hsiang, I just sent you the script to <email address hidden>. Please take a look. Thanks for your help.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

@chimafu,

I quickly went through your script. A potential problem that consumes memory is findAll(). In 0.10, findAll returns an iterator instead of a list. You may want to try releasing the memory of the iterator by yourself. See http://sikuli.org/trac/wiki/reference-0.10#IteratingMatches for more information. (Also, you can't use len(iterator). You need len(list(iterator)).)

Revision history for this message
Shobha (shobha-thimmaiah) wrote :

I did try destroying the memory after every use of findAll, as specified in example. But still Sikuli crash :(

Revision history for this message
RaiMan (raimund-hocke) wrote :

I confirm, that it has nothing to do with not destroying the iterator object after a findAll().

If you monitor a long running script, you can see, that memory consumption increases with every find operation. It seems that it is more when using findAll than with a simple find.

When working without any variables or additional private resources, there is no chance with the normal means of Sikuli script, to release any memory (besides lastMatch, lastMatches which definitely has no effect).

Mac 10.6:
Test 1: find()
the following test on a screen 1280x800 with a find(<sikuli symbol on launchpad>) without setting ROI:
after performing about 2850 find operations, all memory values reported by the activity monitor had increased by about 200 MB
(ending real: 770, virtual: 2.52 GB).

Test 2: findAll()
same screen, ROI set to (0,0,400,800), pattern to search for: question mark symbols on the launchpad answer page (14 matches).
After 1000 findAll() with directly destroying the iterator, the increase was about 350 MB (real) and 1GB (virtual).
(ending 1.14 GB real, 3.48 GB virtual)

This shows, that the effect is much more dramatic with findAll().

When Sikuli IDE starts, the values are: 110 MB real and 2.12 GB virtual

Revision history for this message
Shobha (shobha-thimmaiah) wrote :

Sp wold this mean assigning find to a variable would release memory?
pls let me know if any other way to to release memory after usuage, inturn make scripts to run without sikuli crash

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

@Shobha,
Can you post your script here or mail it to me? (and what is your OS?)

Revision history for this message
RaiMan (raimund-hocke) wrote :

Sorry, for may be misleading you:

Using variables means, that you store references to objects (which are the ones, that consume the memory). As long, as you have a reference stored in a variable, the memory of the referenced object will not be released by the automatic garbage collection.

So what I mean is, if you do not use something like myMatch = find() or myImg = capture(), .... you are never responsible for releasing any memory. But on the other hand you can not do anything.

But since using destroy() does not have any effect, there are no means for us to prevent this increase of memory.

btw: even if you store all your matches in different variables, this could never have the effect we are seeing: a match is an object, that contains 7 numbers (max 50 Bytes).

With this internal memory consumption we are talking about 80 - 100 KBytes with every find operation, that is left behind (findAll() abaut 3 - 5 times more per operation).

So still we have to wait for the developers.

Revision history for this message
Shobha (shobha-thimmaiah) wrote :

@Tsung-Hsiang Chang

I have mailed the code.
I use Windows XP, SP2 32 bit

Eric Lammertsma (e-lammertsma)
summary: - Sikuli 0.10 crashes every time on my script
+ Memory leak in Sikuli 0.10 crashes long scripts
Revision history for this message
Eric Lammertsma (e-lammertsma) wrote : Re: Memory leak in Sikuli 0.10 crashes long scripts

I absolutely love Sikuli, but I have this problem as well and Sikuli 0.10 is crashing within about 3 minutes on my never-ending script. I have tried many workarounds and managed to extend the running time of the script a little, by avoiding all finds and findAlls, decreasing the ROI, and limiting unnecessary matching, but it still crashes very quickly.

For shorter, run-once scripts, this isn't a problem. I use Sikuli for automatic generation of help files for an application in our company as well as testing its stability, which works fine. At home I have used Sikuli to fully automate playing the Facebook game Social City, (not because I like the game, but because I love Sikuli and a challenge!) and this requires the script to run constantly. There, it crashes after hitting 700-800MB of memory use, which tends to happen after a few minutes.

I will happily post the code if it helps!

RaiMan (raimund-hocke)
tags: added: 0.10 longrun memoryleak
Revision history for this message
chimanfu (jfu) wrote :

any ETA for this bug fix please? It seems to me Sikuli 0.10 is pretty useless without this fix.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

I can't confirm this problem is caused by memory leak yet.
In fact, we are working on a new vision engine, so the current code will be obsoleted soon.
I am not sure if using the new engine can resolve this issue. We will see.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

I just found a few places that cause memory leak, but I am not sure if the leak was the cause of the crashes.
I can pack a test version with this fix. Anyone here can help me to test it?

Changed in sikuli:
status: New → Fix Committed
Revision history for this message
Shobha (shobha-thimmaiah) wrote :

Yes, I can test it

Revision history for this message
RaiMan (raimund-hocke) wrote :

Hi Sean, I could repeat my long running tests and see if something changed. RaiMan

Revision history for this message
chimanfu (jfu) wrote :

how can I get the test version with your fix?
I'd like to try it out.

Revision history for this message
Eric Lammertsma (e-lammertsma) wrote :

I would love to help out by testing your fix and providing feedback on crashes and memory use. I'm pretty sure my current long scripts will illuminate whether the problem has been fixed but, just to be sure, are there any functions in particular you would like tested?

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

Hi guys,

Here is a package with my fix: http://people.csail.mit.edu/vgod/sikuli/Sikuli-IDE-win32-0.10.1-rc1.zip.
Please give it a shot and let me know if it still crashes.
Thanks!

Revision history for this message
chimanfu (jfu) wrote :

Hi Tsung-Hsiang

Thanks for fixing the issue.
I think it's getting a little bit better with your fix, but eventually it'll still crash as the memory keeps increasing.
It seems the find() is still an issue.

if you just do this, it'll crash in 10-15 mins.

while True:
    find(something)

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

I have tested the simple loop with find(). It has been running for an hour, and still alive.
Its memory usage was floating between 160M ~ 200M. I haven't seen a memory leak till now.
chimanfu, can you paste the crash log?

Revision history for this message
Shobha (shobha-thimmaiah) wrote :

@Tsung-Hsiang Chang

Sikuli still crashes on running my scripts.
I tried simple While, Find, even that crashes after a while..I have attached the crash log of the same.

Revision history for this message
Eric Lammertsma (e-lammertsma) wrote :

Thanks for the quick fix Tsung-Hsiang! My script also seems to be running longer but unfortunately still ends up crashing after ten to fifteen minutes, stalling at around 900MB of memory after starting at 400MB.

I would gladly send an crash log, but I'm not sure where to find it. I searched my User directory for modified .log files but found nothing related to Sikuli or Java. Where could I find it? (I'm on Windows 7 x64)

Revision history for this message
RaiMan (raimund-hocke) wrote :

Same goes for me, just running the simple find() loop for about 100 minutes.

The increase of memory is much slower than before, but it still exists.

at start of IDE: 120MB

Memory consumption increases very fast after starting the loop up to about 320 MB (after about 15 seconds).
After that the increase is steady but slow.
When stopping the script, it was about 780 MB.

The pattern I used was 2 icons on the desktop (about 250 x 100).

No crashes until now.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

Hi guys,

Thanks for the reports. I have identified another memory leak issue, which probably is the most critical cause of your crashes.
Here is the RC2 with its fix. http://people.csail.mit.edu/vgod/sikuli/Sikuli-IDE-win32-0.10.1-rc2.zip

Can you give it a try and let me know if it works? Thanks!

Revision history for this message
Eric Lammertsma (e-lammertsma) wrote :

Thanks for jumping on the problem again!

It seems like you're certainly narrowing down the problem and plugging leaks. My script is running even longer now but unfortunately it still crashes. I estimate that the running time has doubled to around 25 - 30 minutes before crashing at around 900MB.

I won't be able to work with Sikuli again until Tuesday, but I'm attaching my script in case it helps you find the problem. For testing you would need to use the Facebook game "Social City" and place a few houses and a factory. The script should take care of the rest. I'm afraid I don't have anything more useful to test with as none of my other scripts run on an endless loop and therefore all work perfectly without crashes.

Revision history for this message
RaiMan (raimund-hocke) wrote :

1. the rc2's bat file contains:
%JAVA_EXE% -Xms64M -Xmx512M -Dfile.encoding=UTF-8 -Dpython.path="%~d0%~p0sikuli-script.jar/" -jar %~d0%~p0sikuli-ide.jar %*
which does not work (seems to be an old version, when everything was packed in 1 jar)

2. after getting it working, I don't see any general change in memory consumption behavior. may be, that the increase is a little bit slower, which corresponds to Eric's results, since his script contains tons of different finds and clicks.

@Eric
could be an interesting example for using the new observer feature (seems you already thought about that ;-)

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

@Raiman,
The bat is new. Can't you run it on your machine? All necessary JARs are linked using the MANIFEST file in sikuli-ide.jar, so we don't need to specify a long classpath argument here.

I am still trying to identify possible leaks. However, it's really painful to do this on Windows. :(

Revision history for this message
RaiMan (raimund-hocke) wrote :

@Sean
class path: my method to get it working, was to take the respective line from the 0.10 version. Now I realized, that there may be apostrophes missing with the -jar parm:
I changed to: -jar "%~d0%~p0sikuli-ide.jar" and it works.

... and however it comes, its different:
- the raise to 320 MB is away - it starts around 125 MB
- but it still shows increasing memory consumption, but rising very very slow

btw: a shortcut to the .bat on the desktop only every 2nd or 3rd try reacts positive on a drop of a .sikuli. In the other cases, the bat starts, but the IDE does not come up and the bat ends.

Concerning Windows: I really feel with you. Working with Windows sometimes feels like punishment ;-)
But if it motivates you: I think still most people are using it and I have been told that some of them even love it ;-)
Happy Mac.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

@Raiman,

Thanks, I will fix the .bat. :)

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

I have tried some tools to find the leaks, but it seems JVM itself has leaks.
Does anyone be able to try running a simple find() script in 0.9.9 on the same machine to see if it crashes after a long run?

Revision history for this message
Shobha (shobha-thimmaiah) wrote :

@Tsung

I tried find() script on 0.9.9. It did run for more than 2 hours without any crash.

Revision history for this message
chimanfu (jfu) wrote :

Hi Tsung-Hsiang,

As Eric mentioned before, the rc2 did improve in postponing memory leaks. But the issue still exists. I still can't use the Sikuli 0.10 with my script that is working fine in 0.9.9. I'd be appreciated if you can continue to work on the memory leak issue as the status of the bug has been marked as Fix Committed.

Revision history for this message
David G. (dgay) wrote :

Hi, I have the same problem with 0.10.1. Is the fix inside the 0.10.1 ?

Revision history for this message
Eric Lammertsma (e-lammertsma) wrote :

Thanks for keeping up the work on this Sean!

I apologize for my absence in keeping you posted on the status of the fixes. An update to the game I was automating rendered most of my script out-dated, but I've updated it over the weekend and can tell you that it runs MUCH longer in 0.10.1! However, it still crashes after less than an hour. I noticed that it passes the 800MB mark now, easily hitting 2GB before crashing, so I have a feeling the leaks aren't plugged but that it just takes much longer to hit the higher limit.

If it's useful, I can pack and upload the script. Just let me know.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

Reopen this bug.
Memory leaking still exists in 0.10.1.

Changed in sikuli:
status: Fix Committed → In Progress
Revision history for this message
Timothy Arceri (t-fridey) wrote :

>>while True:
>> find(something)

>>Tsung-Hsiang Chang wrote on 2010-05-20: #24

>>I have tested the simple loop with find(). It has been running for an hour, and still alive.
>>Its memory usage was floating between 160M ~ 200M. I haven't seen a memory leak till now.
>>chimanfu, can you paste the crash log?

Hi Sean,
             If you are using a large screenshot with this simple loop everything seems to work fine. My memory usage was similar to yours. However if you take a small screenshot e.g. a couple of characters on a web page the the memory steady starts to head upwards. On my machine got up to around 1.3G before crashing.

An interesting thing to note too when running from IDE is that if you cause the script the throw a FindFailed exception (by minimising the web page) the memory stays at the current high level before the exception was thrown (memory still held onto) and when starting the script again it continues to climb from the same spot.

I hope this helps with replicating the problem.

Cheers,
Tim

OS: WinXP 32-bit
Sikuli 0.10.1

Revision history for this message
Timothy Arceri (t-fridey) wrote :

>> Tsung-Hsiang Chang wrote on 2010-05-22:

>> I am still trying to identify possible leaks. However, it's really painful to do this on Windows. :(

I have just tested the simple find() loop on Linux (Ubuntu 10.04) again with only a small area for a screenshot I used the magnifying glass in the Nautilus file browser. And the memory use climbed steadily all the way up to 3.5GB at that point my systems memory use was around 97% and Sikuli started to chew into the swap space. As it didnt look like it was going to crash I ended the process at this point.

Again I tested with a larger screenshot and the memory usage appeared to behave as it should.

I'd assume using a small screenshot in mac would produce the same results. Hopefully you can replicate there and have an easier time finding the cause of the leak.

Revision history for this message
RaiMan (raimund-hocke) wrote :

On Mac 10.6.4 I confirm both observations:

1. steady grow of memory consumption with a small pattern containing only text:
import time
while True:
 m = exists(--- image of the text RaiMan ---, 0)
 if not m:
    break
 print time.strftime("%S"), m
switchApp("Sikuli-IDE")

on my MacBook Air 1,86GHz, 2GB there where 2 find()'s per second on average

the image: the text "RaiMan" in the upper right corner of Launchpad bugs giving:
Match[990,122 57x21] score=1,00

After 70 seconds the memory consumption increased by about 100+ MB (about 150 find()'s)

2. after forcing a FindFailed the memory usage starts on rerun with the value at the exception before.

Revision history for this message
SMercier (smercier) wrote :

On Win XP 32bits SP2 I reproduice the same problem with the script :
import time
while True:
 m = exists(--- small picture ---, 0)
 if not m:
    break
 print time.strftime("%S"), m
switchApp("Sikuli-IDE")

On my machine I have a core 2 duo with 4Go of memory. My screen size is 1680 * 1050 pixels. When I launch this script from the sikuli IDE, the memory of the java process grows more and more from 230mo until 1.4Go where the jvm crashes. The script runs during around 5 minutes before to crash.

Note : Is it scheduled to fix this memory leak in 0.10.1 or maybe in 0.10.2 ?

I can do some tests for Sikuli if you have some problems to test it on windows.

Regards,
Stephane

Revision history for this message
Allan Douglas R. de Oliveira (allandouglas) wrote :

I'm getting a similar problem:
OpenCV Error: Insufficient memory (Failed to allocate 31512620 bytes) in unknown
 function, file ..\..\..\..\ocv\opencv\src\cxcore\cxalloc.cpp, line 52

And my script is a loop consisting of a exists, wait and click statement (in that order)

Revision history for this message
Barry Janzen (barry-janzen) wrote :

Same here with Snow Leopard 10.6.4 and 0.10.1. I have a lot of files to test, and I can only get 20 minutes and about 20 files tested before crashing. I've gotten really good at finding 15 minute activities this week-end.

JavaApplicationStub(11749,0xb0905000) malloc: *** mmap(size=31162368) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
OpenCV Error: Insufficient memory (Failed to allocate 31160204 bytes) in OutOfMemoryError, file cxcore/cxalloc.cpp, line 52
terminate called after throwing an instance of 'cv::Exception'
Abort trap

Revision history for this message
niknah (hankin0) wrote :

I think I have a fix, but haven't tested it much. Can someone tell me if changing the function below in sikuli-script/src/main/native/template-matcher.cc works, it's ok for me...

DownsampleTemplateMatcher::~DownsampleTemplateMatcher(){
   dout << "~DownsampleTemplateMatcher" << endl;
  if (img_){
    cvReleaseImage(&img_);
  }
  if (tpl_){
    cvReleaseImage(&tpl_);
  }
}

DownsampleTemplateMatcher() creates an image via cvresize but never releases it, in other classes img_, tpl_ are passed in from other functions so they don't need to be released? Maybe a clearer fix would be to put these away in extra class members to be freed later.

Revision history for this message
Matthew Balvanz (mkbalvanz) wrote :

niknah I compiled your fix in Ubuntu 10.04 locally and created this simple script to compare:

x = 0
while x < 200:
 if exists(image):
  print "Found!"
 else:
  print "Not found!"
 x = x + 1

After the 200 exists() calls the 10.1 version of sikuli had climbed to about 320MB of memory used while the version with you patch applied started at and stayed very close to 140MB.

I'm trying to setup a development platform in Windows as well to test it as ultimately that is the platform I need to run it one but it seems I'm hitting compiler errors that may be setup issues on my part. If I do get a chance to test it in windows I will run it through my suite of unit tests I wrote.

Revision history for this message
P (pcd) wrote :

Is bug 596546 (https://bugs.launchpad.net/sikuli/+bug/596546) a duplicate of this bug?

Revision history for this message
RaiMan (raimund-hocke) wrote :

yes I think we should link them together.

Revision history for this message
P (pcd) wrote :

@niknah

I think you might have found it. Unfortunately I'm on Windows and bzr won't let me check out projects with symlinks (and I'm unfamiliar with bzr).

But looking at the online repository here http://bazaar.launchpad.net/~sikuli-dev/sikuli/0.10/annotate/head:/sikuli-script/src/main/native/template-matcher.cc on lines 188 and 192 downsampled_img and downsampled_tpl are created but never released.

There are also comments on lines 241-242 for another destructor that state "img_ should be released by its creator" and "tpl_ should be released by its creator"

Therefore, I hypothesize (although I am by no means knowledgeable about the source for this project), that the DownsampleTemplateMatcher destructor (~DownsampleTemplateMatcher) should release both img_ and tpl_.

Furthermore, on lines 189 and 193 there is a comment which states "// released in DownsampleTempalteMatcher's desctrutor" [sic].

Are any developers monitoring this bug report? If so, would it be possible for you verify this?

Revision history for this message
RaiMan (raimund-hocke) wrote :

@ Matthew Balwanz
You have proved, that the simple fix from niknah works on Ubuntu 10.4.
You are trying to test the fix on windows too, but ran into make problems
(question https://answers.launchpad.net/sikuli/+question/118540)

@ niknah
It is not clear, on which system you ran your test.

@ P
I think the developers are monitoring what we are talking and and I know that Sean Tsung-Hsiang Chang) sometimes comes in and comments. If we succeed in proving the fix at least on windows and mac, he will incorporate it in the trunk (as already done before with another fix).

I will try the next days, to test on my Mac 10.6 - but don't know when.

Revision history for this message
Matthew Balvanz (mkbalvanz) wrote :

Got my windows compile problems figured out and ran the same test with a slightly different image in Windows 7.

The memory usage with Sikuli 0.10.1:
At start: ~85MB
After 200 exists() calls: ~180MB

Memory usage after niknah's patch:
At start: ~85MB
After 200 exists() calls: ~130MB

On subsequent runs of the same script without closing the app the patched version remains very close the the 130MB mark for memory usage after the test completes and usage during the test is only marginally higher. Using 0.10.1 however will result in approximately 50MB being added each time it is run.

Overall I think this addresses most of the memory leak issue.

Revision history for this message
niknah (hankin0) wrote :

I'm using ubuntu x64.

I still had a small memory leak, but it's more a problem with the documentation.
In the documentation under the class Finder, the examples don't use a destroy() or with:, if you run the examples of "Finder" in a loop eventually it'll run out of memory.

Revision history for this message
RaiMan (raimund-hocke) wrote :

@ niknah
thanks for the tip. I changed/added the doc.

RaiMan (raimund-hocke)
tags: added: 0.10.1 crash longwait
removed: 0.10
summary: - Memory leak in Sikuli 0.10 crashes long scripts
+ Memory leak crashes scripts running or waiting long
Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

Thanks niknah for providing the patch. I will test it and let you guys know the result.
If everything goes well, I will put this into the official trunk and release a small update soon.

Revision history for this message
P (pcd) wrote :

@niknah & @RaiMan

Are you sure about the old Finder examples? Python and Java (and hopefully therefore Jython) support garbage collection.

So if you did something like:

while True:
        f = Finder("path-to-an-imagefile") # create a Finder with your saved screenshot
        img= "path-to-an-imagefile" # the image you are searching
        f.find(img) # find all matches
        while f.hasNext(): # loop as long there is a first and more matches
                print "found: ", f.next() # access the next match in the row
        print f.hasNext() # is False, because f is empty now

Then yes, more Finder objects would be created, and more memory would be used, but since nothing is referencing them, then when the garbage collector is automatically activated, it will deallocate the memory reserved for the unused Finder objects. The program should not crash at all. Python (or Jython or Java) should realize that memory is getting tight and activate the garbage collector.

The only way to cause a "memory leak" in Python and Java (and hopefully therefore Jython) would be to continually have a reference to each of the new Finder objects that are created (perhaps by appending each one to a list). I put "memory leak" in quotes here, because it's not actually a memory leak if you still have a reference to the reserved portion of memory. If a programmer had a reference to each object he created, then it is his own fault if his program runs out of memory, and the Sikuli developers are not responsible for that at all.

Memory leaks only happen in programming languages that have dynamic memory allocation without a garbage collector, such as C and C++.

For more information about garbage collection, check out the WikiPedia article: http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

Revision history for this message
P (pcd) wrote :

The source code and the link got messed up after I posted. Hopefully these will be more readable:

while True:
        f = Finder("path-to-an-imagefile")
        img= "path-to-an-imagefile"
        f.find(img)
        while f.hasNext():
                print "found: ", f.next()
        print f.hasNext()

And the link: http://bit.ly/qaOHl

Revision history for this message
niknah (hankin0) wrote :

Your example would take a long time for the memory leak to happen because you're using find() which waits a while, this was my test...

 cap=capture(SCREEN)
                while True:
                        f=Finder(cap)

There is still another slow memory leak somewhere, when I run my script overnight eventually it'll use up gigs of memory, but this is hard to find cause I have to run it overnight before it happens.

Java has memory leaks, it's more uncommon than C. When you do things like open up a database connection in java you have to close it or else it'll leak memory, and someone who wrote the doc knew this cause there is a .destory() in the findAll() example but not the Finder() example. They're hard to find in java because of the random way the garbage collector works, you notice in java apps that the memory usage goes up and down often so you never know if it's leaking memory or being normal.

Also, I find that if I don't call Runtime.getRuntime().gc() once in a while, it doesn't free certain things like the Screen object which results in lots of Screen + OverlayWindow,JPanel objects after a few hours.

Revision history for this message
P (pcd) wrote :

Ah, I think you might be right.

You mentioned how database connections don't get garbage collected. I would assume that's because there might be an active thread within each database connection, and that active thread holds references. If this is the same for the Finder class, then you're right and Finder wouldn't get garbage collected as well. I believe those .destroy() methods are in place to tell the active thread to terminate, which would then release the references, which would then make the object available for garbage collection. (But I haven't looked at the code, so don't hold me to that).

GUI objects would behave the same way, since they have active threads managing the appearance of the GUI.

Another possibility would be if the Finder class linked up with some C code that had a memory leak, because you can't hold Java (or Python or Jython) accountable for what happens in C.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

I have tested niknah's patch on my Mac. It worked very well.
My test script has been running for 12+ hours, and the memory consumption is still very stable.
Thanks, niknah!

I am also fixing some trivial bugs. I think we can release 0.10.2 next week.

Revision history for this message
niknah (hankin0) wrote :

This was my problem with overnight memory leaks...

To duplicate, run this for an hour or more(note the memory usage cause it's a slow leak)...

while True:
 with findAll('xxx.png') as f:
  pass

Make sure you don't have a file called xxx.png

Fix: In Region.java, findAllNow needs a f.destroy() if it can't find anything...

   public <PSC> Iterator<Match> findAllNow(PSC ptn)
                                             throws FindFailed{
      ScreenImage simg = _scr.capture(x, y, w, h);
      Finder f = new Finder(simg, this);
      f.find(ptn);
      if(f.hasNext()){
         return f;
      }
      f.destroy();
      return null;
   }

Also found out something about java's Garbage collection...

* Memory leak...

cap=capture(SCREEN)
while True:
 f=Finder(cap)

* No memory leak...

from java.lang import Runtime
cap=capture(SCREEN)
while True:
 Runtime.getRuntime().gc()
 f=Finder(cap)

* No memory leak...

cap=capture(SCREEN)
SCREEN.setROI(0,0,1,1)
while True:
 f=Finder(cap)

It maybe because java is counting it's own memory usage before calling the garbage collector and not counting the memory usage of the things allocated in C. So when we don't allocate much in C (by setting the screen's ROI to a small value), it eventually calls the garbage collector. This maybe why normal java garbage collection doesn't work here.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

This's great! Thanks, niknah!

Btw, how did you know there was a memory leak in the first example?

Revision history for this message
niknah (hankin0) wrote :

I had a script that was running overnight, and whenever I woke up it was using up 1+ gig of memory. And I started to remove things out of the script to find out which bit was causing it. Took a while to find the cause I had to wait several hours before I could see if there was a memory usage increase.

Revision history for this message
Tsung-Hsiang Chang (vgod) wrote :

niknah's patch has been released in 0.10.2. Thank you, niknah!
I hope all critical memory leaks are all fixed.
If anyone finds new leaks, please open a new bug.

Changed in sikuli:
status: In Progress → Fix Released
Revision history for this message
P (pcd) wrote :

This is working perfectly now. Thank you all!

Revision history for this message
Jaewon Jung (jung) wrote :

It's still happeing with Sikuli X 1.0rc1.

Anybody having this problem with Sikuli X 1.0rc1?

Revision history for this message
RaiMan (raimund-hocke) wrote :

@ Jaewon Jung
No other reports until now.

System environment?

Symptoms?

Error messages?

Revision history for this message
Jaewon Jung (jung) wrote :

Basically same as above.

After a long running of the script, java.exe with massive memory usage suddenly dies with the exception code of 0xe06d7363.

Revision history for this message
RaiMan (raimund-hocke) wrote :

@ Jaewon Jung

Ok, if you think it is a bug, then report a new one.

Again: do not expect to get any qualified answer, if you do not give more information about your situation.
System? Features used? memory used at time of crash? already worked with 10.2?

This bug is outdated, since these kind of memory leak were definitely fixed latest with version 10.2.

Revision history for this message
Jaewon Jung (jung) wrote :

@RailMan

Ok, I'll do.

By the way, what does the version number 10.2 exactly mean? It's the same thing as X-1.0rc1 or you mean a previous version?

Revision history for this message
Eric Lammertsma (e-lammertsma) wrote :

I can second that it was solved for me on Windows 7 x64 in Sikuli 10.2, so Jaewon's problem is probably something new. However, I haven't yet tried Sikuli X, with 10.2 working practically flawlessly for me.

I hadn't had much time to play with Sikuli since my last report in this thread, but with 10.2 I tested this by making a small script to automate a portion of a game (the Zen Garden in Plants vs. Zombies, of which for the life of me I can't understand why someone would do this by hand.) I ran this once overnight and saw no notable (<1%) increase in memory consumption, despite a constant loop of findAll's over 20 or more images.

For me, this makes Sikuli viable for more robust, unattended automation, which is exactly what I was hoping for! My apologies for not testing & mentioning that the bug had been resolved earlier.

Revision history for this message
Eric Lammertsma (e-lammertsma) wrote :

0.10.2 is an older release from August which contains the fix for this particular bug, reported in earlier 0.10 versions. You can download it at https://launchpad.net/sikuli/+download and see if you can get your script working there without problems.

Revision history for this message
RaiMan (raimund-hocke) wrote :

@ Jaewon Jung (and Eric)
If you want to try out 10.2 like Eric suggested:
-- be sure not to use any features that are not supported by 10.2 (like e.g. class App, import sikuli's, image path, ...)
-- Download the zipped version of 10.2 (no installation, the .bat has to be used) and uninstall Sikuli X properly using system uninstall
-- be aware, that 10.2 is much slower than X (new vision engine)

RaiMan (raimund-hocke)
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.