Community
Participate
Working Groups
Build ID: I Steps To Reproduce: 1. Create a new project 2. Create a new class 3. See how long it takes for the editor to open on that new class (sort of 30 seconds to 120 seconds). More information: The tested system: 1. 2GB RAM, dual core CPU 2. java -version = Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) 3. Tested with Window Managers: Gnome, KDE, Beryl.
What filesystem are you using, and against which backend device?
(In reply to comment #1) > What filesystem are you using, and against which backend device? > Filesystem: specifically on the partition where my data and eclipse are: EXT3 Backend Devide: im not sure what do u mean.
Please try with a fresh Eclipse SDK R3.3: http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.3-200706251500/eclipse-SDK-3.3-win32.zip and start with a fresh workspace. If you then still see the problem use the tips in the following link to produce stack traces while the editor is opening. Also read the other hints in that link. http://www.eclipse.org/eclipse/platform-text/development/bug-incomplete.htm
(In reply to comment #3) > Please try with a fresh Eclipse SDK R3.3: > http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.3-200706251500/eclipse-SDK-3.3-win32.zip > and start with a fresh workspace. If you then still see the problem use the > tips in the following link to produce stack traces while the editor is opening. > Also read the other hints in that link. > > http://www.eclipse.org/eclipse/platform-text/development/bug-incomplete.htm > The link you supplied is of a Windows Eclipse, while the problem occurs only on Linux
Not really. Read all of it. And don't reopen without stack trace.
(In reply to comment #5) > Not really. Read all of it. And don't reopen without stack trace. > i made some checks. There was no crash, so stack trace is irrelevant. i tried the log in debug mode but i didn't find any information that looked useful...HOWEVER... i run it with strace and found very interesting things which i compared with Eclipse 3.2.2. Here are my findings: 1. Eclipse 3.3 keeps calling gettimeofday() relentlessly while 3.2.2 doesn't. It's strange, however it doesn't look as something that has to do with the problem. 2. HOWEVER, something else does: 3.3 tries and retries to open a socket to an address in my internal network which doesn't exists (10.0.0.1) and it looks like this is the source of the problem. i have no idea why it tries to access that address and how it gets to the address. i "grep-ed" the workspace and the ".eclipse" directories but didn't find any mentioning of the inet address. If it stopped looking for that address (why does it even try?) i think the problem will be solved. Note that i experienced the exact problem with eclipse 3.3 starting from milestone 6 and i kept checking to see if it was gone until now.
Did you try the fresh install without any other plug-ins? As said. I need the stack dump while it waits. You can create stack dumps without having a crash. Read the links. I doubt that the pure Eclipse SDK connects to 10.0.0.1.
1. Use the "ps" command to find out the process id (pid) of the Java VM 2. Invoke "kill -3 <pid>" where <pid> is the process id of the Java VM
Created attachment 73270 [details] the output of kill -3 on eclipse, per your request here's the output of kill -3 on eclipse, per your request. Note about the other points you mentioned: it is clean installation, clean workspace, clean ".eclipse" directory.
Actually, I've found that Eclipse 3.3 repeatedly tries to hit DNS lookups during startup. It's a serious pain whenever I'm disconnected from a network. I'm betting that your /etc/resolv.conf is configured to look at 10.0.0.1 for a DNS server, and that you'll find the lookup is being done inadvertently with the construction of a java.net.URL. I didn't get that kind of problem with 3.2 either, but 3.3 is majorly annoying in that regard. Note that my symptoms existed on Mac OS X, but I'm betting any unix-based system disconnected from a network (or with an active network but unreachable DNS server) will suffer the same problems. Can you try 'host www.eclipse.org' (or nslookup) in a shell and see if it says anything, and whether it's using 10.0.0.1 as a name server? And I don't think WORKSFORME is a great resolution to this bug, since I'm betting Daniel hasn't tried it with an unoperational DNS server.
(In reply to comment #10) > Actually, I've found that Eclipse 3.3 repeatedly tries to hit DNS lookups > during startup. It's a serious pain whenever I'm disconnected from a network. > I'm betting that your /etc/resolv.conf is configured to look at 10.0.0.1 for a > DNS server, and that you'll find the lookup is being done inadvertently with > the construction of a java.net.URL. I didn't get that kind of problem with 3.2 > either, but 3.3 is majorly annoying in that regard. > > Note that my symptoms existed on Mac OS X, but I'm betting any unix-based > system disconnected from a network (or with an active network but unreachable > DNS server) will suffer the same problems. > > Can you try 'host www.eclipse.org' (or nslookup) in a shell and see if it says > anything, and whether it's using 10.0.0.1 as a name server? And I don't think > WORKSFORME is a great resolution to this bug, since I'm betting Daniel hasn't > tried it with an unoperational DNS server. > Thanks Alex. i suspected exactly the same thing right when i found it was network related, however my dns is set to be 10.0.0.138 not 10.0.0.1. The 10.0.0.1 belong to just another computer on the network (note that when it is on, the eclipse is a lil bit faster, due to much less retries). There's nothing on that computer that have anything to do with eclipse, though. Also i checked "host www.eclipse.org" as u suggested and it points at the eclipse internet site. What alternative do u propose in solving this issue?
>And I don't think >WORKSFORME is a great resolution to this bug, since I'm betting Daniel hasn't >tried it with an unoperational DNS server. No I did not test ever possible configuration on earth and there's no need for doing that when the simplest thing is creating a stack dump and attaching it here as I requested. Now, take a look at the stack dump and you see the problem right away. No need to guess what it might be ;-) The real problem is most likely the same reported in bug 153936 i.e. a bug in your GTK version (see http://bugzilla.gnome.org/show_bug.cgi?id=428665). Please check whether your configuration is affected by that bug. Moving to SWT: bug 153936 claims that a workaround is in place in Eclipse to protect from this hang but it seems like there's still a problem though. Also note new bug 195085 reporting a similar issue.
This is a duplicate of 153936. I've added a jar that has some additional checks and a disable printers system property. Can you give it a try on your system and let me know if it works for you? (Post response in 153936 as I am marking this bug as a DUPLICATE). *** This bug has been marked as a duplicate of bug 153936 ***
i'd like that very much. Where's that jar? (In reply to comment #13) > This is a duplicate of 153936. I've added a jar that has some additional checks > and a disable printers system property. Can you give it a try on your system > and let me know if it works for you? (Post response in 153936 as I am marking > this bug as a DUPLICATE). > > > > *** This bug has been marked as a duplicate of bug 153936 *** >
i just tried it. It didn't solve the problem. Note that there's something else that happens, that might or might not has to do with it: the initial screen, on the first opening of a workspace (not the splash) appears text-only and w/o all the welcome-page graphics. (In reply to comment #13) > This is a duplicate of 153936. I've added a jar that has some additional checks > and a disable printers system property. Can you give it a try on your system > and let me know if it works for you? (Post response in 153936 as I am marking > this bug as a DUPLICATE). > > > > *** This bug has been marked as a duplicate of bug 153936 *** >
Try starting up with ./eclipse -clean
(In reply to comment #16) > Try starting up with ./eclipse -clean > nope. ain't working.
OK - did you try running with ./eclipse -Dorg.eclipse.swt.internal.gtk.disablePrinters
(In reply to comment #18) > OK - did you try running with > > ./eclipse -Dorg.eclipse.swt.internal.gtk.disablePrinters > same result :(
avi - I'm going to upload a new jar in Bug 153936. The new jar will print out to the console "Hacked SWT jar: Disabling printers" whenever a call to enumeratePrinters is made. You must start it up like this: ./eclipse -vmargs -Dorg.eclipse.swt.internal.gtk.disablePrinters Please give it a try and report your findings in Bug 153936. Since this bug is still a duplicate of that one, I am closing it as a DUPLICATE. *** This bug has been marked as a duplicate of bug 153936 ***
