SikuliX

[1.1.4] IntelliJ IDEA: SikuliX shutdown hook is blocking my app from exiting

Asked by Paul Chambre

I'm seeing a problem that started recently, but I'm not sure what change preceded it. When my app exits, or attempts to exit, when I'm running it in IntelliJ, it hangs. This is true whether it's a successful exit, or one due to an uncaught exception.

The relevant part of the thread dump seems to be this:

"main" #1 prio=5 os_prio=0 tid=0x0000000002cb2800 nid=0x23d0 in Object.wait() [0x0000000002b7e000]
   java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 at java.lang.Thread.join(Thread.java:1252)
 - locked <0x00000000e00cc710> (a org.sikuli.script.RunTime$1)
 at java.lang.Thread.join(Thread.java:1326)
 at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:107)
 at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46)
 at java.lang.Shutdown.runHooks(Shutdown.java:123)
 at java.lang.Shutdown.sequence(Shutdown.java:167)
 at java.lang.Shutdown.exit(Shutdown.java:212)
 - locked <0x00000000e0075510> (a java.lang.Class for java.lang.Shutdown)
 at java.lang.Runtime.exit(Runtime.java:109)
 at java.lang.System.exit(System.java:971)
 at com.illumon.guitest.TestIrisGui.main(TestIrisGui.java:586)

This is using the SikuliX 1.1.4 jar under Java 1.8.0_172 from IntelliJ 2018.2.5 on Windows 10.

Edit: After digging in to what's in use at the shutdown hang, I think this maybe started when I started having to use IntelliJ's classpath jar because the command line had, for no apparent reason, become too long to execute directly.

Could C:\Users\[username]\AppData\Local\Temp\classpath212570385.jar maybe cause some sort of issue in conflict with the SikuliX shutdown hook?

Any ideas?

Thanks,
Paul

Question information

Language:
English Edit question
Status:
Answered
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
RaiMan (raimund-hocke) said : 		#1

Yes, SikuliX adds a JVM shutdown hook, where some cleanup actions are done.

The implementation was revised during the last few weeks.

Might be that your usage of SikuliX is another special situation, that has to be seen by the hook implementation in case.

Could you give me some details, how you are using sikulixapi.jar (as Maven dep or project library).

please add -Dsikuli.Debug=3 to the java commandline and paste the relevant debug output.

Revision history for this message
Paul Chambre (pchambredh) said : 		#2

I'm using it as a gradle dependency:

compile group: 'junit', name: 'junit', version: '4.12', 'com.sikulix:sikulixapi:1.1.4-SNAPSHOT'

Details with some username information excised (---)

[debug] RunTimeINIT: starting API
[debug] RunTimeINIT: java version
[debug] RunTimeINIT: user.home
[debug] RunTimeINIT: user.dir
[debug] RunTimeINIT: app data path
[debug] RunTimeINIT: store debug.txt
[debug] Options: loadOptions: check: C:\Users\---
[debug] Options: loadOptions: check: C:\Users\---
[debug] Options: loadOptions: check: C:\Users\---
[debug] RunTimeINIT: version: 1.1.4-SNAPSHOT build: 2019-01-02_16:11
[debug] RunTimeINIT: global init: entering as: API
[debug] RunTimeINIT: Accessing: GraphicsEnvironment.getLocalGraphicsEnvironment()
[debug] RunTimeINIT: Accessing: GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices()
[debug] RunTimeINIT: ScreenDevice 0 has (0,0) --- will be primary Screen(0)
[debug] RunTimeINIT: Monitor 0: (0, 0) 1920 x 1014
[debug] RunTimeINIT: runningAs: JAR (sikulixapi-1.1.4-SNAPSHOT.jar) in: C:\Users\---\.gradle\caches\modules-2\files-2.1\com.sikulix\sikulixapi\1.1.4-SNAPSHOT\191f9b61f8263553a7f9e8490cca633aa26f301c
Options: *** options dump
Options: testing =
Options: Debug.level = 0
Options: *** options dump end
***** show environment for 1.1.4-SNAPSHOT-2019-01-02_16:11 API
user.home: C:\Users\---
user.dir (work dir): C:\Users\---
user.name: ---
java.io.tmpdir: C:\Users\---\AppData\Local\Temp
running 64Bit(amd64) on Windows (10.0) from a jar
java 8 version 1.8 vm 25.172-b11 class 52.0 arch 64
app data folder: C:\Users\---\AppData\Roaming\Sikulix
executing jar: C:\Users\---\.gradle\caches\modules-2\files-2.1\com.sikulix\sikulixapi\1.1.4-SNAPSHOT\191f9b61f8263553a7f9e8490cca633aa26f301c\sikulixapi-1.1.4-SNAPSHOT.jar
*** classpath dump sikulix
*** classpath dump end
***** show environment end
[953 debug] RunTimeAPI: global init: leaving
[953 debug] RunTimeAPI: initAPI: entering
[953 debug] RunTimeAPI: initAPI: leaving
[984 debug] Mouse: init start
[1549 debug] Mouse: init end
[1794 debug] RunTimeAPI: libsExport: folder has wrong content: C:\Users\---\AppData\Roaming\Sikulix\SikulixLibs ( - )
[4210 debug] RunTimeAPI: addToWindowsSystemPath: added to systempath:
C:\Users\paulc\AppData\Roaming\Sikulix\SikulixLibs
[4210 debug] RunTimeAPI: checkJavaUsrPath: added to ClassLoader.usrPaths
[4225 debug] RunTimeAPI: libsExport: folder created: C:\Users\---\AppData\Roaming\Sikulix\SikulixLibs (1.1.4 - 201901021611)
[4997 debug] RunTimeAPI: loadLib: opencv_java342.dll (success)

... whole bunch of stuff while app is running ...

[216963 debug] Finder2: doFind: start (stdDev: 121.8090 mean: 633.881408)
[216963 debug] Finder2: doFind: in original: %8.1201 (?99) 0 msec
[216963 debug] Finder2: doFind: end 0 msec
[216963 debug] Region: checkLastSeen: not there
[216963 debug] Finder2: makeMat: INT_RGB (1920x1014)
[217106 debug] Finder2: makeMat: TYPE_4BYTE_ABGR (77x38)
[217106 debug] Finder2: doFind: start (stdDev: 121.8090 mean: 633.881408)
[217544 debug] Finder2: doFind: in original: %99.9999 (?70) 438 msec
[217544 debug] Finder2: doFind: end 438 msec
[217544 debug] Region: wait: C:/Users/----/NoButton.png appeared (M[921,499 77x38]@S(0) S:1.00 C:959,518 [911 msec])
[218093 debug] CLICK on L[959,518]@S(0) (549 msec)
[218126 debug] RunTimeAPI: ***** final cleanup at System.exit() *****

App hangs on exit here.

Revision history for this message
Launchpad Janitor (janitor) said : 		#3

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
RaiMan (raimund-hocke) said : 		#4

still to be checked

Revision history for this message
Paul Chambre (pchambredh) said : 		#5

The other day, another project I was compositing with my project in IntelliJ got refactored and that caused IntelliJ to somehow reorganize my project. It lost its information about JDK to use, modules for run configurations, the annotations jar,.... and it also started including incorrect and unresolvable dependencies for the class I needed from the composited project.

I ended up uncompositing and using a jar from that other project instead. As part of this chaos, the project now runs from IntelliJ without hanging on the shutdown hook. This may be because uncompositing also shortened the class path. I'm not sure, but this seems a not unlikely explanation.

Can you help with this problem?

Provide an answer of your own, or ask Paul Chambre for more information if necessary.

To post a message you must log in.