How to avoid Eclipse leaks on XServer when editing Android XML files?
Asked Answered
S

3

8

When I'm editing XML files in Eclipse (mainly, Android layouts and so), it causes leaks on XServer and it ends eating all my RAM (4GB), so I have to Ctrl+Alt+Backspace to continue.

Do you know any remedy for that?

Snip answered 1/4, 2010 at 14:39 Comment(10)
How do you know Eclipse leak memory? Does the memory get free if killing Eclipse?Stutsman
I filed a bug here: code.google.com/p/android/issues/detail?id=26473Switch
@haibison Seeing as this is a known bug, what result did you expect by placing a bounty on Stack Overflow? :)Japan
@Marvin, I'm hoping... Android team does not yet confirm this is a bug. And I hope there is someone knowing how to solve this. If I had 10k reputation, I'd be ready and be happy to give it to someone, honestly. I can work with xml but the visual controls are better. I'm really worrying about my projects and deadlines... :-(Switch
@haibison Fair enough, I was more curious than anything :) Could what you are experiencing just be the result of a large-ish Android project loaded in Eclipse? What I mean by that is, when you install the Google Eclipse plugin which comes with all the fancy UI editing and what not, could what you're experiencing just be the result of all that loaded in memory, and not necessarily a memory leak?Japan
@Marvin, No it's just a small project. Even if I create new sample project with an activity. I just right click on the control, then, for example select "Edit Text"/ "Edit ID"... Then close it. Then open it again... And, xserver is eating my RAM :-)... If you are confused and want to try, I am using TeamViewer, you are welcome. I can give you my email if you want to?Switch
@haibison That does sound like a valid issue. Good luck, I hope you get this resolved.Japan
@Marvin, I'm sorry for my English and if my words were bad... Thank you for discussion :-)Switch
@hai: Does Kane's advice to kill Eclipse return the memory? If not, please also file a bug against Xorg with your distribution vendor. (When the client dies, X should return nearly all the server-memory that the client forced the server to allocate.) Furthermore, the Mem column of a system monitor utility is nearly useless on its own. The top(1) utility reports VIRT, RES, SHR -- what do they say? How much swap do you have and how much is used?Heavenward
@Heavenward Hi, I have raised the bug again, and saved all memory information into several files. You can find them here. I have 4 GB swap. After I killed java, the xserver's memory seemed returned to a half...Switch
S
1

Eclipse Juno and ADT v20 seem to be working well.

Switch answered 28/6, 2012 at 7:37 Comment(0)
H
1

It might help if you start eclipse off your java interpreter with a garbage collector enabled via the command line. Something like this could work:

java /path/to/eclipse -XX:+UseParallelGC

You could also add some swap space to your computer as a final option, but of course that's one step above asking you to go out and buy more ram.

For more information on garbage collection in java, look here

Hepato answered 9/3, 2012 at 2:57 Comment(2)
Thanks. I added param -XX:+UseParallelGC as you said. But it didn't help. Do I need to specify a number instead of -XX?Switch
I think xserver will eat all my RAM :-), even if I had 32 GB. As gskbyte said: it ends eating all my RAM (4GB)... And as in my case: xserver keep eating the RAM, second by second. But thank you for your help.Switch
S
1

Eclipse Juno and ADT v20 seem to be working well.

Switch answered 28/6, 2012 at 7:37 Comment(0)
P
0

I've seen this issue using eclipse in Linux and Windows, and it sucks!

Try reverting your ADT installation to a previous version.

go to: help --> install new software at the lower right-hand corner click what is "ALREADY INSTALLED"?

click the Installation History tab

you'll see a list of time stamps and hopefully you'll have a older version of ADT to revert to

Hopefully that fixes all of "our" problems until a update is released!

Pastime answered 1/4, 2012 at 19:55 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.