Unable to process incoming event ‘ProgressComplete ’ (ProgressCompleteEvent) on Windows #882
Comments
|
@wpfeiffe This looks to be related to changes made in Gradle 2.13. A few questions:
|
|
We upgraded gradle from 2.11 to 3.2. The problem did not exist with 2.11. We do have other developers running under different shells where this does Our devops group runs the build under linux from jenkins without issue. Is there a way for me to set the --console plain setting within the Let me know if you have other questions on this. Bill Pfeiffer On Fri, Nov 18, 2016 at 11:36 AM, Eric Wendelin notifications@github.com
|
|
Seeing the same behavior in a windows console running jhipster generated application using gradle. I ran "gradlew build" and this was the output: FAILURE: Build failed with an exception.
Reran with --console plain and the task ran to completion with no errors. |
|
As I mentioned in https://issues.gradle.org/browse/GRADLE-3527, I've started getting this after I upgraded gradle version from 2.6 to 3.2 |
|
I'm running Gradle 3.2.1 and Windows 10, and just started getting this message with a relatively new example. It does seem to work OK with the To reproduce, clone: Then run: When it breaks (it usually does) it happens on But if you run If you run with Although parallel is turned on by default, this doesn't seem to make a difference one way or another. Neither does turning off the daemon. I have the Windows console buffer set to the largest size. The CI builds on both Appveyor and Travis-CI seem to work fine. |
|
I am seeing this with Gradle 3.2.1 in Windows 10 + Git Bash when using gradle-node-plugin@1.0.1 on task Node plugin config: Not sure, maybe it prints some control characters that break Gradle. |
|
Here is my result regarding the additional debugging:
A possible explanation regarding changing-the-cmd-buffer-size fix is that Windows seems to be flushing some internal state which prevents the crash from happening. If the grooming scenario doesn't present itself again, the trigger won't cause the crash. Restarting the console may have the same behavior. There is a chance the issue is outside of Gradle's control, however, we should at least fail gracefully. |
|
A warning: I've been updating that particular example in the past week,
quite significantly, so I'm not sure if the one you are working with is the
same.
…-- Bruce Eckel
www.MindviewInc.com <http://www.mindviewinc.com/>
Blog: BruceEckel.github.io
www.WinterTechForum.com
www.AtomicScala.com
www.Reinventing-Business.com
http://www.TrustOrganizations.com <http://www.ScalaSummit.com>
On Fri, Dec 30, 2016 at 12:02 PM, Daniel Lacasse ***@***.***> wrote:
Here is my result regarding the additional debugging:
- The issue is reproducible with sample lacasseio/issue-882
<https://github.com/lacasseio/issue-882> extracted from
BruceEckel/OnJava8-Examples
<https://github.com/BruceEckel/OnJava8-Examples>. You first need to
execute gradlew groom, Ctrl-C when Shutdown appears in the console and
then gradlew crash. The command gradlew groom represent gradlew
:concurrent:DiningPhilosophers from BruceEckel/OnJava8-Examples
<https://github.com/BruceEckel/OnJava8-Examples> and gradlew crash
represent gradlew :concurrent:run -x :concurrent:DiningPhilosophers
from BruceEckel/OnJava8-Examples
<https://github.com/BruceEckel/OnJava8-Examples>. For some reason the
task :concurrent:DiningPhilosophers would hang on my machine (hence
the Ctrl-C) but seems to be triggering the crash.
- The issue is only reproducible inside cmd.exe (couldn't reproduce
under cygwin)
- Starting a new cmd.exe prompt and running gradlew crash will not
cause the crash. The grooming process need to be executed in order to cause
the crash.
- The crash worked on both the new Windows 10 console feature and the
legacy pre-Windows 10 console.
- The issue wouldn't reproduce under an integTest in Intellij
- It seems somehow related to JavaExec task/implementation as most
people seems to have reported that specific use case
- Although the output says to use --stacktrace, --info or --debug for
more information, --stacktrace will be ignored and --info/--debug will
cause the failure to disappeared.
- The sample was only tested under Windows 10 fully patched
- More debugging is required to find out why the grooming is needed in
order to cause the crash.
A possible explanation regarding changing-the-cmd-buffer-size fix is that
Windows seems to be flushing some internal state which cause prevent the
crash from happening. If the grooming scenario doesn't present itself
again, the trigger won't cause the crash. Restarting the console may have
the same behavior. There is a chance the issue is outside of Gradle's
control, however, we should at least fail gracefully.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#882 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA9JrKOcAL0CyFFm_8yx2E3njEkcfWyIks5rNWNMgaJpZM4K1wLB>
.
|
|
I encountered similar issue with gradle node plugin. After adding to problematic tasks the problem was gone. |
|
@BruceEckel The important thing is we are able to reproduce with BruceEckel/OnJava8-Examples@920d169. I will keep looking at it to see why this is happening. @kaidohallik and @wpfeiffe Could you tell me which version of Windows both of you are using? |
|
As a follow up on the debugging, here is the stacktrace of the exception that happen: |
|
@lacasseio My Windows version: Windows 7 Ultimate, Service Pack 1. I encounter this problem while working with project generated with jhipster.
with
Error occurs in 2 different form:
I can reproduce this problem always if I set Windows command line window Screen Buffer Size Height to 99. Other information I gained. Error never occurs if executing:
Sometimes that action can prevent error:
Error never occurs in gulp tasks after putting this to Error never occurs in NodeTask (includes GulpTask) and NpmInstallTask (it means in this sample app error never occurs) after putting this to |
|
After more debugging on this issue, it doesn't seem to be needing the grooming part to cause the crash. The same code may succeed a couple time before failing. It is possible to see that the When the event is deserialized on the launcher, it is done at the following location: As it was mentioned previously, the event is dispatched twice on the launcher but only created once. It seems to never happen on a cold daemon which raises suspicion on a possible resource leak regarding registered listener. |
|
Further information was found on this issue. Something happen causing this code to not been reached (a runtime exception is thrown) causing the code to unwind and execute the Some work was done to intercept the exception causing this issue: Note the output seems to be in Unicode with lots of null characters. |
reverts jhipster#4683 and replaces with better solution for gulp resolves error/hanging on executing npmInstall and yarn_install my comment in open gradle issue: gradle/gradle#882 (comment)
|
The issue seems to be related to Jansi hence explains why using plain console is a valid workaround. Jansi tries to call The next debugging step would be to try and reproduce this failure using native code only and inspect the context in which is happen. |
|
It is important to note the issue is related to Jansi but doesn't mean the issue is inside Jansi. Gradle does its fair share of console cursor manipulation. |
|
Windows 7 Pro latest updates applied
…On Mon, Jan 2, 2017 at 9:19 AM, Daniel Lacasse ***@***.***> wrote:
@BruceEckel <https://github.com/BruceEckel> The important thing is we are
able to reproduce with ***@***.***
<BruceEckel/OnJava8-Examples@920d169>.
I will keep looking at it to see why this is happening.
@kaidohallik <https://github.com/kaidohallik> and @wpfeiffe
<https://github.com/wpfeiffe> Could you tell me which version of Windows
both of you are using?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#882 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAI6rRNzhQI85yGTyIcY251f4i5nIjX9ks5rOQdvgaJpZM4K1wLB>
.
|
|
I think got to the bottom of this issue. Brace yourself as there are 2 sneaky issues in this scenario. Let's start with the simple one. Although it's a neat idea to map all Win32 API in Java with a JNI generator and use that in the native implementation of the Jansi, not all Win32 API are created equal. The best example is
The Jansi code does try to grab the last error message immediately. However, what is neglected here is the overhead happening through JNI call. There is at least a heap allocation happening or another Win32 API call which causes the
This brings us to the second issue related to how Jansi process escapes code on Windows. The crash happens while processing a cursor down movement which is handled by
Let's manually execute the next line of
This means The solution (not yet tested) to this last issue would be to replace |
|
It is worth mentioning that for both discovered issues, there isn't any test written in the source project that could have helped avoid those issues. |
This fix issue gradle/gradle#882.
|
Since the exception happens when JAnsi process the ANSI Console string (at |
|
In order to avoid waiting for fusesouce, a fix was pushed in Gradle code base to workaround the issue. See PR #1155. |
|
I had this issue with gradle 3.3. on windows + git bash. This will be resolved in 3.4? |
|
@stealthrabbi As indicated by the milestone the issue has been fixed with 3.4-RC1. You can either try out a RC build or wait for the final release of 3.4. |
|
Can confirm that 3.4 fixed the issue for us. Thank you! |
|
Dear All, Just close your shell window(cmd.exe or powershell.exe) and reopen a new one, I found it works for me. |
|
Damn!! Wouldn't have guessed it in a million years. |
|
Thanks @lengerrong worked for me on windows 10 + powershell after 5 failed compilation |
|
Thanks, lengerrong, it worked! |
|
Copy all your image files into projectFolder\android\app\src\main\assets here and try to build |
Expected Behavior
When performing a largish build, a well formed build with no errors, will complete without erroring out
Current Behavior
On a large build, under windows 7, using Gradle 3.2, if the build is invoked from a command line, and the output is sufficiently long to scroll beyond the window buffer as specified in the Command properties in windows, Gradle will throw the following error when attempting to update the output:
“Unable to process incoming event ‘ProgressComplete ’ (ProgressCompleteEvent)”
Context
Using gradle 3.2, largish build output (we do an npm install as part of the script!), at a windows command prompt (in my case windows 7). Build fails to complete even through that are no actual build problems
Steps to Reproduce (for bugs)
See above
Your Environment
See above
The text was updated successfully, but these errors were encountered: