Community
Participate
Working Groups
Programs like this package ru.test1; public class CrushX { final static int SIZE = 100*1000; public static void main(String[] args) { StringBuffer s = new StringBuffer(); for (int i=0; i<SIZE/2; i++) s.append("ab"); System.out.println(s); } } crushed Eclipse and XWindow, while successfully running from command-line and from Eclipse-windows.
First off, I should say that, there obviously could be a lurking bug in our code which we *will* look for. You need to understand though that, if what you are seeing is a limitation of your particular X server, then there may not be anything we can do about it. When the output is written to System.out, each line of text eventually gets converted into a single text painting operation in the operating system, be it X or win32 or whatever. If this exceeds some undocumented internal limitation in the server which causes the application to crash, then it is a bug in the server not in Eclipse. Now, if *all* X servers have the same limitation, we will typically put in a workaround which prevents the crash, but if each one is different and there is no way to easily find out what the limitation is, then we are stuck. We've seen this in the past on win32. Some win32 versions fail to print text properly (or crash) if the string is too long. If it was a simple matter of finding the longest possible string which could be printed, then we would limit the text length to this value in our code. Unfortunately, we found that the length varied based on many interrelated factors (which os version, which common controls DLL, which font, which locale, etc.), and no easy max length value could be computed. Now, we *could* have put in code to artificially break long strings up in to small ones (although it's not clear what size we would pick), but this would have made all printing slower to fix a case which is basically not interesting for effectively *every* user. The short answer: Don't draw strings which are that long. No human is going to look at a 100K long string on a single line anyway. In any case, GG to investigate potential problems in SWT or the eclipse console support.
This was driving me nuts to figure out what was causing this. But yes, the rendering of a particularly long string in either the console, or the editor will cause Eclipse, AND X to crash. I run Eclipse 3.1.2, GTK+ 2.8.11 (2.8.8 same problem), Xorg-X11 6.8.2, Linux kernel 2.6.13, Nvidia display driver version 7676, dual Opteron amd64 My Co-Worker runs Eclipse 3.1.1, GTK+ 2.6.8, Xorg-X11 6.8.2, Linux kernel 2.6.11, Nvidia display driver version 6629, athlon-64 We are both running fully 64 bit mode gentoo distributions. I experience the problem. My Co-Worker does not. I suspect GTK+ (but that is based upon nothing more than primitive superstition, and the reading of leaves in a teacup). I tried copying over my co-workers eclipse distribution but I experienced the same problem, I would downgrade to a previous version of gtk+ but it would break too many things on my system.
*** This bug has been marked as a duplicate of 87299 ***
