Community
Participate
Working Groups
Sometimes the console view just stops updating. Seems like the console view does not flush out the stdout somehow. My application writes a log file, and I can see the log file is still being written continuously. And if I terminate my application, the remaining stdout is then flushed out to the console view. I have tried different version of gdb and/or java. Doesn't look relevant. I can reproduce this bug almost every time on a certain test data, but I can't use it here. Alternatively, it may be reproduced by an infinite loop like this (limit a console buffer size if necessary): for (int i = 0; ; ++i) { printf("%d", i); for (int j = 0; j < 90; ++j) printf("0"); printf("\n"); } On my machine, it stops updating at about 18000000 loops. I guess it will stop eventually if you just let it run and wait for a while. The system is CentOS x64 7.1.1503, glibc 2.17, and GTK 3.22.30. I don't see this bug in 2019-03.
gdb function works as usual after the console view stops updating. I can still do pause, next, step, check call stack, etc.
I have tried running this with eclipse for C/C++ from EPP on Linux with all the defaults (including default 80000 character console limit) but I have show heap status on. I am running on Ubuntu 18.04 with GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git. After 36563765 iterations it is still working. I'll leave it running longer to see what happens - but if you have anymore details on what you did that could be helpful.
I am now at 1498106970 iterations and all is good. I will follow up when I can get some more info.
I also have show heap status on. I tried gdb 7.10, 7.12, and 8.1. And system default java openjdk 1.8.0_191-b12, and OpenJ9 java 11.0.3+7 and 12.0.1+12 with -Xms256m -Xmx2048m -Xquickstart -XX:+IdleTuningGcOnIdle . Same setting on 2019-03. Curiously, when I pause this simple application, the stack seems always here: Thread #1 [helloworld] 14595 [core: 3] (Suspended : Signal : SIGINT:Interrupt) __write_nocancel() at 0x7ffff7268840 _IO_new_file_write() at 0x7ffff71f4fb3 __GI__IO_do_write() at 0x7ffff71f641c __GI__IO_file_overflow() at 0x7ffff71f67f3 putchar() at 0x7ffff71edc6e main() at helloworld.cpp:18 0x400702 I am thinking, is it possible that the console view serves the application as its stdout, and some error happens during high speed IO and then this redirection is stuck? Is there any change on console view from 2019-03 to 2019-06 which may affect this part?
I just have another two runs, one stoped at 18xxxxxx, one stoped at 39096407.
It is not even relevant to gdb. I tried using just Run rather than Debug, it still stopped at 9312359 iterations.
I closed eclipse after the application was stopped updating console. Then I found the java and eclipse processes are still running, and java is even consuming 100% CPU. pstack java shows many threads in this stack: #0 0x00007ff24dee7945 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x00007ff24cdc757b in os::PlatformEvent::park() () at /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.x86_64/jre/lib/amd64/server/libjvm.so #2 0x00007ff24cdace2d in ObjectMonitor::wait(long, bool, Thread*) () at /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.x86_64/jre/lib/amd64/server/libjvm.so #3 0x00007ff24cf38c0e in ObjectSynchronizer::wait(Handle, long, Thread*) () at /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.x86_64/jre/lib/amd64/server/libjvm.so #4 0x00007ff24cbc1d36 in JVM_MonitorWait () at /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.x86_64/jre/lib/amd64/server/libjvm.so
Since you are hitting a problem even when using Run, can you reproduce the problem with a similar Java program. The console is something provided by the Eclipse Platform, and I don't know what changes are in there. If you can reproduce withouth CDT involved that would be great. If the Java is a problem, can you reproduce like this. Build your program, make sure it works past the failure point you are observing fully outside of Eclipse (e.g. in a terminal). And if so, run the program as an External Tool (let me know if you need instructions for any of this).
I just reproduced this with a Java application! It can be reproduced using Run or External Tool. Not sure how often it can be reproduced... The code is like this: for (int i = 0; ; ++i) { System.out.print(i); for (int j = 0; j < 90; ++j) System.out.print('0'); System.out.println(); } I'll change the Product field to Platform.
Thanks for continuing to investigate. I have reset assignees.
I can't reproduce with 4.13 master. How long your endless example should run to break console? Do you have set any limits on the console output?
Sometimes it begins to hang very quickly, while sometimes it takes a long time. The fastest one I got was at only about 40000 loops (the java example). I set console limit to 80000 as default. Not sure if this is necessary. It usually happens when console update getting slow. On my machine, using OpenJ9 java 12 is much easier to reproduce than 11 or system default 1.8, as OpenJ9 12 is somehow slower. I suspect the issue happens when java cannot flush out stdout quickly enough. It probably yields a buffer overflow error or something and then it just stops flushing.
I just tried again and it hanged at loop 79161 in less than 1 minute. Using system default openjdk 1.8.0.191 for both eclipse and the java example.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
