Transpiler hangs on generating tests; if i add a comment(!) - tests get successfully transpiled

[orielmaute]

I have the situation that one of my projects hang during j2cl transpilation of tests from java to js. The transpilation process never stops, after calling mvn clean install. When i add a java comment (//) to one of my source files (a specific one) the transpilation does not hang any more. When i remove the comment again, the transpilation hangs again...i can reproduce the bug. It's seems very strange - maybe the plugin takes an hash/md5 of the file and adding the comment forces another hash value..

I took a thread dump (see attachments) while hanging. The thread dump belongs to the hang_again.txt console output. It seems that the test mojo is waiting for another thread:

`"main" #1 prio=5 os_prio=0 cpu=11558.23ms elapsed=126.90s tid=0x00007f3c54028800 nid=0xfaebe waiting on condition [0x00007f3c58405000] java.lang.Thread.State: WAITING (parking) at jdk.internal.misc.Unsafe.park(java.base@11.0.15/Native Method)

• parking to wait for <0x0000000430c339e0> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(java.base@11.0.15/LockSupport.java:194) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.15/AbstractQueuedSynchronizer.java:885) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.15/AbstractQueuedSynchronizer.java:1039) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.15/AbstractQueuedSynchronizer.java:1345) at java.util.concurrent.CountDownLatch.await(java.base@11.0.15/CountDownLatch.java:232) at com.vertispan.j2cl.build.BlockingBuildListener.blockUntilFinished(BlockingBuildListener.java:30) at com.vertispan.j2cl.mojo.TestMojo.execute(TestMojo.java:402)`

But the only relevant other thread running is:

`"DiskCacheThread" #52 prio=5 os_prio=0 cpu=0.25ms elapsed=120.40s tid=0x00007f3c57717000 nid=0xfaf69 waiting on condition [0x00007f3b355fa000] java.lang.Thread.State: WAITING (parking) at jdk.internal.misc.Unsafe.park(java.base@11.0.15/Native Method)

• parking to wait for <0x0000000430c9af10> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(java.base@11.0.15/LockSupport.java:194) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.15/AbstractQueuedSynchronizer.java:2081) at java.util.concurrent.LinkedBlockingDeque.takeFirst(java.base@11.0.15/LinkedBlockingDeque.java:483) at java.util.concurrent.LinkedBlockingDeque.take(java.base@11.0.15/LinkedBlockingDeque.java:671) at sun.nio.fs.AbstractWatchService.take(java.base@11.0.15/AbstractWatchService.java:118) at com.vertispan.j2cl.build.DiskCache.checkForWork(DiskCache.java:96) at com.vertispan.j2cl.build.DiskCache$$Lambda$302/0x0000000840545840.run(Unknown Source) at java.lang.Thread.run(java.base@11.0.15/Thread.java:829)`

I use the j2cl-plugin version from my pull request (i can't use another one, because of the problem with the annotation processor test files).

hang.txt hang_again.txt not_hang.txt threaddump_form_hang.again.txt

[niloc132]

Is it possible that this bug goes away after you clean your project? If so, this is likely caused by https://github.com/Vertispan/j2clmavenplugin/issues/121, where an old build never finished, but didn't clean up after itself either. If that is the case, practically any change at all will cause your build to complete, as well as cleaning the project.

[orielmaute]

The bug does not go away if i call "mvn j2cl:clean clean install".

[niloc132]

Thanks for checking - lets get your other PR merged and I'll take a closer look.

[orielmaute]

debug.txt

Console output with enabled debug.

[DEBUG] Remaining work: 17 tasks [DEBUG] Remaining work: 15 tasks [DEBUG] Remaining work: 16 tasks [DEBUG] Remaining work: 14 tasks [DEBUG] Remaining work: 13 tasks [DEBUG] Remaining work: 12 tasks [DEBUG] Remaining work: 11 tasks [DEBUG] Remaining work: 10 tasks [DEBUG] Remaining work: 9 tasks [DEBUG] Remaining work: 8 tasks

I think the workers have stops (in thread dump is no active worker thread) - but debug output says, that there are 8 remaining tasks.

[orielmaute]

I was moving to fast - it seems that you are right and this issue is a duplicate caused by #121

The success-file marker for the job "stripped_bytecode_headers" of one of my artifacts has never been created (the marker has only be created when i added a java comment to one of the artifacts sources - because then the file hash changed)

mvn -Dartifact=* j2cl:clean helped

[orielmaute]

Can you please mark the issue as duplicate or shall i close it?